Open tommychiu-github opened 2 months ago
Thanks @tommychiu-github, support for CBOR encoded DICE certs is something we considered adding support for in the past. Given the way our tooling works, this should be fairly straightforward to add support for. Specifically, adding support would require the following (@pamaury, let me know if I am missing anything here):
opentitantool certificate codegen
subcommandgenerate_cert()
function of the ot_certs
Codegen structot_certs
Rust lib, similar to the ASN.1/X.509 cert builder; parse_certificate()
function in the ot_certs
Rust lib to be able to parse an X.509 or CBOR certificate (for test/verification purposes during personalization)Regarding your proposal however, would a device need both an X.509 AND a CWT DICE cert chain in flash info? or would a device need either a X.509 OR CWT DICE chain in flash info?
Your description is correct @timothytrippel . I admit I don't know the details of CBOR enough to estimate how much work this would require. If CBOR certificates are sufficiently close to X509 in structure then potentially a lot of code can be shared between the two generators and the biggest part of the work would be the certificate parser and the device encoding library.
My proposal is to have both X.509 AND CWT DICE chain on device concurrently. The reason is that different skus may need different format of the DICE chain. Since this implementation is in the common repository it might be good to have both of them at the same time. Does this assumption make sense?
To document here: after some discussion, I believe we want to support several DICE certificate profiles, or different combinations of base certificates and custom extensions to support
Additionally we want to support both X.509 and CWT certificate formats, where applicable, for all profiles.
I put together an RFC to describe what we are looking for: https://docs.google.com/document/d/1zBudM3YyasCoYhchRDLJUKKDEtlCQ4Yc5dx9HEE45HU/edit?usp=sharing
The current on-device certificate generation mechanism during personalization (and during ROM_EXT execution) generates DICE certificate chain in the X.509 ASN.1 DER format, which is one of the supported standards of the Open Profile for DICE.
However, the Android RKP specification "generateCertificateRequestV2.cddl" requires all layers of the certificate chain from UDSpub to CDI* to be CBOR encoded.
To support such use cases, we would like to enable generating either X.509 (ASN.1 DER) or CWT (CBOR) formatted DICE certificates during personalization and in the ROM_EXT.