> This is what is in the draft now, I'm I'm pretty sure it is incorrect CDDL > > COSE_C5 = [ + CBORCertificate ]
This is not in the current version. It has already been changed in the GitHub version based on the discussions during the previous interim. There seemed to be agreement to use arrays. We did not want to make technical changes is -00 so the change will come in -01. The current version is COSE_C5 = [ [ + C509Certificate ] ] It should be discussed if the inner array should be moved to C509Certificate. The idea to unwrap ~C509Certificate when the array is not needed is a good idea. > I'm I'm pretty sure it is incorrect CDDL I don't know why you think this was incorrect CDDL. RFC 8610 even has the following example [+(left: uint, right: uint)] (but this does not matter as I think we have already taken the decision to use arrays). > It would not be possible to decode correctly. I don’t think that was true. That would only be true if you cannot determine the number of elements from c509CertificateType (but this does not matter as I think we have already taken the decision to use arrays). Cheers, John From: COSE <[email protected]> on behalf of Laurence Lundblade <[email protected]> Date: Friday, 14 May 2021 at 06:05 To: cose <[email protected]> Subject: [COSE] The one-byte saving from use of a sequence 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
