I haven’t looked at that part of the draft in a while, but in CDDL we have
types and groups.
To model sequences, we can use a group or (if a top level type is required)
wrap those groups into an array.
C509Certificate = (…)
Is a group. You can repeat such a group using
+C509Certificate
But that means you have to count to eleven.
So you want to wrap that group into an array to then repeat it:
COSE_C5 = [ + [ C509Certificate ] ]
which is what the current editor’s draft says:
https://github.com/cose-wg/CBOR-certificates/blob/master/draft-ietf-cose-cbor-encoded-cert.md
(Can someone please fix the README? “Editor copy” link from HTML is 404, still
says EricssonResearch.)
Grüße, Carsten
> On 14. May 2021, at 10:22, John Mattsson
> <[email protected]> wrote:
>
> > 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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
