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 <steffen.fr...@siemens.com> Sent: woensdag 15 januari 2025 10:46 To: Esko Dijk <esko.d...@iotconsultancy.nl>; Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org; Werner, Thomas <thomas-wer...@siemens.com> 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 <esko.d...@iotconsultancy.nl> > Sent: Tuesday, January 14, 2025 11:53 PM > To: Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org; Werner, > Thomas (FT RPD CST SEA-DE) <thomas-wer...@siemens.com>; Fries, Steffen > (FT RPD CST) <steffen.fr...@siemens.com> > 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 <mcr+i...@sandelman.ca> > Sent: dinsdag 14 januari 2025 21:00 > To: Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org; Werner, Thomas > <thomas-wer...@siemens.com>; Fries, Steffen <steffen.fr...@siemens.com> > Subject: Re: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on > signing the PVR > > > Esko Dijk <esko.d...@iotconsultancy.nl> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
