Hi Esko
What irritates me is the statement in the YANG definition of RFC 8366bis:
"Indicates that the voucher has been issued after
minimal verification of ownership or control. The
issuance has been logged for detection of
potential security issues (e.g., recipients of
vouchers might verify for themselves that unexpected
vouchers are not in the log). This is similar to
unsecured trust-on-first-use principles but with the
logging providing a basis for detecting unexpected
events.";"
This reads for me that there is no supply chain integration due to the "
trust-on-first-use" approach. This would mean the MASA would provide the
assertion if the manufacturer produced the device based on the serial number
and the IDevID signature in the PVR. This describes the ownership handling on
the MASA side, while "proximity" or "agent-proximity" describes the
communication side in the domain.
Therefore the question for me is not quite answered, if the MASA gets a PVR
with a nonce and is able to verify proximity, but does not know the customer
domain, he could provide both values, "proximity" as he could verify that the
pledge was in direct contact with the registrar and "logged" because he does
not know the customer domain (maybe I'm relating to much in the
"trust-on-first-use" statement in the YANG description, which I understand as
trust-on-first-use for the MASA when seeing a PVR from an unknown domain.
Best regards
Steffen
> -----Original Message-----
> From: Esko Dijk <[email protected]>
> Sent: Tuesday, September 3, 2024 3:29 PM
> To: Fries, Steffen (T CST) <[email protected]>; Michael Richardson
> <[email protected]>
> Cc: [email protected]
> Subject: RE: [Anima] Re: Question regarding use of assertions in vouchers in
> RFC8366bis
>
> I think RFC 8366 explains the relation between 'logged' and 'proximity' -
> saying that
> 'logged' is the weakest of checks that the MASA can do, which is the fallback
> used if no live proximity can be verified by MASA, but still it wants to
> issue a
> voucher.
> If proximity can be verified then 'proximity' is used, the stronger (more
> secure)
> assertion.
>
> Details about 'proximity' validation are in RFC 8995 Section 5.5.5 / 5.5.6 ;
> roughly it
> includes checking the nonce in both PVR/RVR, and inspecting the prior-signed-
> voucher-request (PVR) inside the RVR, and ensuring the PVR has a proximity-
> registrar-cert that "is consistent with" the signing entity of the RVR.
> (This allows some interpretation freedom - "consistent" could mean the same
> entity, or it could mean another RA entity located under the same Domain CA.
> In
> the simplest Registrar implementation it would just be the exact same (RA)
> entity.)
>
> It's up to the vendor to device whether their Pledge would accept "logged"
> vouchers or not. @Steffen is there anything that still needs to be clarified
> in RFC
> 8995 5.5.x for your use case?
>
> Esko
>
> -----Original Message-----
> From: Fries, Steffen <[email protected]>
> Sent: Monday, September 2, 2024 14:53
> To: Michael Richardson <[email protected]>
> Cc: [email protected]
> Subject: [Anima] Re: Question regarding use of assertions in vouchers in
> RFC8366bis
>
> > -----Original Message-----
> > From: Michael Richardson <[email protected]>
> > Sent: Monday, September 2, 2024 2:40 PM Fries, Steffen
> > <[email protected]> wrote:
> > > For the specific issue, we may think about having distinct statements
> > > that relate to a supply chain integration (verified, logged) and some
> > > other distinct statements, which relate to the interaction in the
> > > customer domain (proximity, agent-proximity).
> >
> > Do you have a specific situation/need which is not covered yet?
> [stf] The scenario we were talking about is a product, which is provided via a
> distributor. The manufacturer has no direct sales channel to the end customer.
> The end customer does the onboarding based on BRSKI and the MASA would
> have the option to signal "logged" or "proximity".
> Do we have a recommendation how the MASA would behave? The decision of the
> MASA may also have effects on the pledge, if the pledge only takes "proximity"
> vouchers.
>
> Best regards
> Steffen
> _______________________________________________
> Anima mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
