Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences

[Andrew Weiss <[e-mail]>]

Hey Carsten,

I haven't yet implemented RFC 8742 CBOR sequences (per
https://github.com/anweiss/cddl#validating-cbor), but it is next on my list.

*Andrew*


On Thu, Nov 5, 2020 at 12:02 PM Carsten Bormann <[e-mail]> wrote:

> On 2020-11-05, at 17:25, John Mattsson <john.mattsson=
> [e-mail]> wrote:
> >
> > Hi,
> >
> > Henk wrote:
> >> Circling back to my initial reply, I am still under the impression that
> >> you are asking for a CDDL notation that can express CBOR Sequences as a
> >> top-level item in a CDDL spec, right? (RFC8764 is hinting at that.)
> >
> > Carsten wrote:
> >> Are you talking about the “future versions” part of that?
> >
> > Yes, I am asking for a future update to CDDL that allows expression of
> CBOR Sequences as a top-level item. I want that "future version" of CDDL as
> soon as possible.
>
> I see.  (I don’t see why.)
>
> The reason that this is under “future” is that there is no urgency to
> re-spin CDDL at this point — we can handle all current issues within the
> extension points (at least until we do the module structure — but that will
> take another year or two).
>
> > The reason I want that updated version is because I want to use CDDL.
>
> Yes, and RFC 8742 tells you how to do this for CBOR sequences with today’s
> CDDL.
>
> > The
> > alternative is to not use CDDL, or as suggested by RFC 8742 and use CDDL
> together with human readable text. The human readable text cannot be used
> for automatic verification unless you have a very smart AI.
>
> You already need something (“English” or in your implementation glue) that
> links the specific CDDL spec to the incoming data.
> That something could as well tell you that the incoming data is a CBOR
> sequence and not a single CBOR data item, and use the CDDL accordingly.
> Can you explain the difficulties you find with that?
>
> >> So the solution here is to concatenate four separate CBOR data items
> >> (key_id, key_usage, key_value, key_addinfo) in order to safe the bytes
> >> that would wrap them in an array and would result in a single CBOR data
> >> item.
> >
> > Yes, all the specs I referred to do something similar. My understanding
> is that the result is a CBOR sequence (not a single CBOR data item). In
> EDHOC we have taken every possible measure to shave of bytes so that the
> message can fit in 5-hop 6TiSCH and LoRaWAN. The resulting CBOR sequence
> for message_2 is 46 bytes which is still one (1) byte too much. In EDHOC we
> will need concatenate byte strings of known length to make the CBOR
> sequence fit inside a single frame. There is absolutely no possibility to
> take the cost of even a single extra byte.
>
> I’m not arguing for converting the CBOR sequence into a single CBOR data
> item.
> I’m just arguing that you can use the way of using CDDL for CBOR sequences
> that is specified today in RFC 8742.
>
> Henk has pointed out to me in separate conversation that my CDDL tool is
> not yet sequence-friendly; I’ll take that as an action point now.
>
> Andrew — where is your tool with respect to handling RFC 8742 CBOR
> sequences?
>
> Grüße, Carsten
>
>