> The *Registrar*, however, might not have them all. In cBRSKI the Registrar does get them all from the DTLS handshake. But agree that for PRM this doesn't work in the same way. I didn't read PRM recently - does the Agent add a signed object stating the IDevID cert chain that it has seen from the Pledge...?
If not: then either the cert chain needs to be in the signed PVR, or we need extra requirements on the Registrar to get these chains beforehand which may not always be practical. We have some discussion (to be continued) whether the Registrar can be expected to be preloaded with all CAs in the chains, or a subset of only the highest sub-CAs, or only the root CA ? The more the Registrar already knows, the less the Pledge has to send in its PVR, given that the MASA would know all its own CAs for sure. Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: dinsdag 14 januari 2025 21:00 To: Esko Dijk <[email protected]>; [email protected]; Werner, Thomas <[email protected]>; Fries, Steffen <[email protected]> Subject: Re: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on signing the PVR Esko Dijk <[email protected]> wrote: > Now the target recipient of the PVR is the MASA. (Again for PRM this > may be different and include Registrar as well...? But not in BRSKI I > think.) So the requirement on the Pledge is it SHOULD include in the > PVR all the certificates needed for the MASA to build the complete > chain. Since the manufacturer created the IDevID for the pledge, I would think it (the MASA) has all the required subordinate certificates. The *Registrar*, however, might not have them all. It's a tussle. > The MASA is this solution needs to store all the cert-chains for all > the Pledges it supports – including their IDevID EE certificates -- an > extra burden on MASA, compared with BRSKI, but one which helps us > achieve the smaller size of PVR. So cBRSKI changes the “SHOULD” > requirement from 8995 to a SHOULD NOT in Section 9.2.2. I don't think it's a burden :-) > A registrar accepts or declines a request to join the domain, based > on the authenticated identity presented > It doesn’t say where the IDevID identity should come from – PVR or the > (D)TLS handshake supplied certificates. Having only one source should > be fine ... ? Yes. I prefer getting it from the PVR. That's much easier in a PRM situation. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
