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

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

Hi Esko,

Thank you for your thoughts. I agree to your statements. I was merely thinking about the flexibility that is provided by BRSKI for the pledge/MASA interface.
After rethinking my comments based on your answer, this flexibility is something which relates only to the relation between the pledge and the MASA. With that the potential interoperability question can directly be addressed by the manufacturer to ensure interworking between his MASA and his produced pledges.

Thanks also for the pointer to section 11.6. The paragraph you cited is exactly the one I was looking for. The inclusion of the certificate chain in the CMS container is mentioned there. I was looking in 9.1.1 for this statement, but missed to check the security considerations.

Regards
Steffen


From: Anima <[e-mail]> On Behalf Of Esko Dijk
Sent: Friday, March 8, 2024 12:41 PM

> it would mean to provide the MASA certificate chain also in the pledge firmware

This is one way to do it. The simplest solution is only include the public key of the signer (MASA), also allowed by the 9.1.1 text. In this case, it's less flexible: the MASA service can't go sign with another identity/private-key: it MUST sign with the private key associated with the public key that's already baked into the Pledge.
In case a whole chain is included in the Pledge firmware as you propose, the validation can be a bit more flexible I think.

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.

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

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.

Regards
Esko


From: Anima <[e-mail]<mailto:[e-mail]>> On Behalf Of Fries, Steffen
Sent: Wednesday, March 6, 2024 16:41
To: [e-mail]<mailto:[e-mail]>
Subject: [Anima] RFC 8995, Voucher Signing, MASA Certificate Chain provisioning

Hi Michael,

I've got a question regarding the MASA voucher signing or better the certificate chain provisioning for the MASA certificate to the pledge.

RFC 8995 states in section 91.1. (https://www.rfc-editor.org/rfc/rfc8995.html#section-9.1.1)
"The online service MUST have access to a private key with which to sign voucher artifacts [RFC8366<https://www.rfc-editor.org/rfc/rfc8995.html#RFC8366>]. The public key, certificate, or certificate chain MUST be built into the device as part of the firmware."

I had the assumption that the pledge only knows its IDevID and with that his own certificate, public/private key pair and the certificate chain from the issuing CA to the trust anchor.
In operational environments the issuing CA for the IDevID may not be the same as the issuing CA for the MASA signing certificate. From the requirement above, it would mean to provide the MASA certificate chain also in the pledge firmware, if it is different than the IDevID issuing CA. As the voucher is a CMS container that allows to convey the certificate chain of the signer in the SignedData, I would have expected it is contained there. This would be similar to the voucher request, in which the registrar-voucher-request also contains the certificate chain according to section 5.5.2 (https://www.rfc-editor.org/rfc/rfc8995.html#section-5.5.2), which states:
"A certificate chain is extracted from the registrar's signed CMS container. "

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.
Any thoughts?

Best regards
Steffen
--
Steffen Fries