Hi Michael, > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Saturday, March 16, 2024 1:35 AM > To: Esko Dijk <[email protected]>; Fries, Steffen (T CST) > <[email protected]>; [email protected] > Subject: Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain > provisioning > > > Esko Dijk <[email protected]> wrote: > > The requirement for the Pledge in RFC 8995 is (5.6.1): The pledge MUST > > verify the voucher signature using the manufacturer-installed trust > > anchor(s) associated with the manufacturer's MASA > > > This leaves quite some vendor flexibility I think on how exactly to > > verify: against 1 public key, against multiple public keys, against a > > chain baked into the device, against a single root CA cert, against a > > single root CA cert taken from the chain baked into the device, etc > > etc. > > Thank you for expounding on the variations. > We have the advantage that pledges are controlled by manufacturers and they > can decide how simple or complex they want to make their process. > > The gotcha is registrars that want to verify the resulting voucher. > It's not entirely required by RFC8995, but maybe enouraged. > So I'd love to collect more of this kind of consideration in the > masa-considerations > or the registrar-considerations. [stf] In BRSKI-PRM, we also recommended (SHOULD) the registrar to verify the received voucher before signing it in https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-12.html#section-7.3.4. This emphasizes the statement in RFC 8995.
Best regards Steffen > > >> I would propose to also allow the submission of the certificate chain > >> of the MASA signing certificate in the SignedData part of the CMS > >> container of the voucher. > > > I expect this is already allowed by RFC 8995, given the text in 11.6: > > Yes, it's not just allowed, but I would say, encouraged. > The question is how do we do it on a constrained voucher. > The cbrski document says some things already about this. > > > There are good cryptographic hygiene reasons why a manufacturer would > > not want to maintain access to a private key for many decades. A > > manufacturer in that situation can leverage a long-term CA anchor, > > built-in to the pledge, and then a certificate chain may be > > incorporated using the normal CMS certificate set. This may increase > > the size of the voucher artifacts, but that is not a significant issue > > in non-constrained > > > environments.ΒΆ<https://datatracker.ietf.org/doc/html/rfc8995#section-11.6- > 3> > > So this effectively says a vendor may want to not use the "simplest > > solution" for security reasons, and include a cert chain of the signer. > > I think that we have not done enough interoperability testing lately. > Particularly between Registrar and MASA. > I'd like to change this, and I'm thinking that the Paris hackathon might be a > good > target date. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
