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
