Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

["Fries, Steffen" <[e-mail]>]

Hi Michael, 

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Saturday, March 16, 2024 1:35 AM
> To: Esko Dijk <[e-mail]>; Fries, Steffen (T CST)
> <[e-mail]>; [e-mail]
> Subject: Re: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain
> provisioning
> 
> 
> Esko Dijk <[e-mail]> 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  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>