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

[Michael Richardson <[e-mail]>]

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.

    >> 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    [