If I’m thinking right, the one-byte saving from using a sequence rather than
array for CBORCertificate only happens when using CBORCertificate in a non-CBOR
protocol. When you put CBORCertificate in a CBOR protocol, it has to be an
array (or a bstr-wrapped sequence) so it can be distinguished from the
surrounding CBOR. In non-CBOR protocols, the surrounding protocol (e.g., the
DER, or the TLS records) provides the framing for what is the cert, so the
array is not needed.
I’d like to see CBORCertificate an array in the main definition. Then when
CBORCertificate is put in a non-CBOR protocol, it can be “unwrapped" to save
the byte. The CDDL notation for that would be ~CBORCertificate. (I’ve been
reading up on CDDL unwrapping lately, so hopefully I got that right).
This also aligns CBORCertificate with the other CBOR protocols I’ve seen so
far. They use an array or map to hold the top-level messages together.
Also, I’m pretty sure the CDDL for COSE_C5 is wrong in the -08 draft. It says:
COSE_C5 = [ + CBORCertificate ]
With CBORCertificate defined as a CDDL group, no framing structure to
distinguish the individual CBORCertificates is generated. The array defined by
this is not of individual certs, but of an aggregation of all the certificate
data items. It would not be possible to decode correctly. Making
CBORCertificate an array solves this problem.
We should expect CBORCertificate to be incorporated into lots and lots of other
CBOR-based protocols. If we are making a mistake like this because of
CBORCertificate being a sequence and not an array, it seems others may as well.
So another reason for the main definition of CBORCertificate to be an array.
LL
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
