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

[Carsten Bormann <[e-mail]>]

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