Hi Esko, My expectation would be that the vendor includes the certificate chain up to the trust anchor he would also provide externally for IDevID validation. This would then be the trust anchor configured at the MASA and also the one provided to the Registrar and can be the root CA certificate or some intermediate. So the only point I would see is to rely on the availability of the trust anchor provided by the manufacturer for IDevID certificate validation.
Best regards Steffen > -----Original Message----- > From: Esko Dijk <[email protected]> > Sent: Wednesday, January 15, 2025 10:53 AM > To: Fries, Steffen (FT RPD CST) <[email protected]>; Michael > Richardson <[email protected]>; [email protected]; Werner, Thomas (FT RPD > CST SEA-DE) <[email protected]> > Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on > signing the PVR > > Ok for me. > > We have to keep in mind though, that while a MUST requirement sounds clear > (it's > included - as opposed to a SHOULD), this requirement itself does not > necessarily > lead to predictable behavior of what the Pledge will include! > For example, > * one Pledge from vendor A may include its IDevID EE cert plus one sub-CA cert > (2 certs), as it considers the sub-CA cert to be the "trust anchor" it shares > with > MASA (as the intended receiver of the PVR). > * one Pledge from vendor B may includes its entire chain up to the root CA > (e.g. 3 > or 4 certs), as it considers the root-CA cert to be "trust anchor". > > Effectively the device vendor decides what the "trust anchor" is. > > In this sense, there's still some variation and optionality as to what the > Pledge will > include. (I think we discussed this in the call and it seemed ok to have > that.) > > Esko > > -----Original Message----- > From: Fries, Steffen <[email protected]> > Sent: woensdag 15 januari 2025 10:46 > To: Esko Dijk <[email protected]>; Michael Richardson > <[email protected]>; [email protected]; Werner, Thomas <thomas- > [email protected]> > Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on > signing the PVR > > Hi Esko, hi Michael, > > In PRM the Registrar-Agent adds the agent-signed-data when it triggers the > pledge > to create the PVR. It is a signed object to proof specifically to the > registrar, with > which registrar-Agent the pledge was in contact. It could convey the > certificate > chain of the Registrar-Agent certificate, but we described that the Registrar > is > configured with the information to validate the Registrar-Agent, so there is > no need > to include the certificate chain for the Registrar-Agent certificate. > > Other than that, the change to a MUST in JWS-Voucher for including the > certificate > chain in the voucher and following also in the voucher request, also > simplifies the > corresponding sections in BRSKI-PRM for PVR and RVR. Up to now, as the > inclusion of the certificate chain was handled as SHOULD in JWS-Voucher and > PRM contained the handling for both cases, if the certificate chain is > included and > if not. The latter required additional information to be available at the > registrar, as > in PRM it also verifies the PVR. This essentially means that wen can simplify > the > two subsections for the JWS-Header handling for the Pledge Voucher- Request > (PVR, section 7.1.2.2) and Registrar Voucher-request (RPR, section 7.3.4.2) as > JWS-Voucher is requiring inclusion of the certificate chain. > I will do that change and submit an updated version by tomorrow. > > Best regards > Steffen > > > -----Original Message----- > > From: Esko Dijk <[email protected]> > > Sent: Tuesday, January 14, 2025 11:53 PM > > To: Michael Richardson <[email protected]>; [email protected]; > > Werner, Thomas (FT RPD CST SEA-DE) <[email protected]>; Fries, > > Steffen (FT RPD CST) <[email protected]> > > Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements > > on signing the PVR > > > > > 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]
