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

[Andrew Weiss <[e-mail]>]

Hey Carsten,

As a follow up to my previous message, I recently released v0.8.4 of my
CDDL tool which supports CBOR sequences. Feel free to give it a whirl and
report back any issues ...
https://github.com/anweiss/cddl/releases/tag/0.8.4

Cheers!

*Andrew*

On Thu, Nov 5, 2020 at 12:17 PM Andrew Weiss <[e-mail]> wrote:

> 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
>>
>>