Parsing and generating CBOR certificates?

Hubert Kario hkario at redhat.com
Fri Jan 22 19:38:42 UTC 2021


On Thursday, 21 January 2021 13:05:21 CET, David von Oheimb wrote:
> I'd welcome support for CBOR(-encoded) certificates since they can save
> a lot of space
> for both the data itself and the code handling it, which may be vital
> for IoT scenarios, for instance.
> It looks like the standardization of their definition got pretty far
> already.
>
> Although it is certainly possible to convert between DER-encoded ASN.1
> (or at least its subset needed for X.509 certs) and CBOR,
> this is not strictly needed since there is a definition of natively
> signed CBOR certs.
> Thus all the ASN.1 fuzz, which is bulky and error-prone to implement and
> use, can be avoided then.
>
> https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress writes:
>
>    The use of natively signed CBOR certificates removes the need for
>    ASN.1 encoding, which is a rich source of security vulnerabilities.

that's a huge and rather crucial difference

as X.509 certificate signatures are specified over byte strings that are 
the DER
encoding of the tbsCertificate structure

you can send that certificate however you want, including by translating it 
into
XML variant of ASN.1

but for verification you still need to turn that XML into DER so that you
can verify that the signature that the CA created is correct

if the signature is expected to be made over CBOR serialising of 
tbsCertificate,
then that's a completely different certificate and it's the CA that needs
to produce it, it's not something that openssl could do (convert from DER 
to
CBOR)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic



More information about the openssl-users mailing list