[Anima] Re: Question regarding use of assertions in vouchers in RFC8366bis

[Esko Dijk <[e-mail]>]

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 <steffen.fries=[e-mail]> 
Sent: Monday, September 2, 2024 14:53
To: Michael Richardson <[e-mail]>
Cc: [e-mail]
Subject: [Anima] Re: Question regarding use of assertions in vouchers in RFC8366bis

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Monday, September 2, 2024 2:40 PM
> Fries, Steffen <[e-mail]> 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 -- [e-mail]
To unsubscribe send an email to [e-mail]