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

From: John Mattsson <[email-masked]>
Date: Thu, 5 Nov 2020 12:49:48 +0000

Hi,

I the most important missing piece in RFC 8610 is the lack of CDDL for CBOR Sequences (RFC 8742) and I think draft-ietf-cbor-cddl-control would be a good place to add CDDL for that.

CBOR sequences has already been standardized in RFC 8742. CBOR sequences are used quite heavily in IETF documents such as RFC 8769, draft-ietf-6tisch-minimal-security, draft-ietf-lake-edhoc, draft-palombini-core-oscore-edhoc, draft-mattsson-cose-cbor-cert-compress, etc.

I don't understand all the complexities of CDDL formalism, but this seems like a quite easy thing to solve. I do not care exactly which notation is used, but could we please just agree on something and put in a draft.

The notation could be something like:

- reuse the CDDL notation for group ( ... )
- reuse the Diagnostic Notation for CBOR sequences << ... >>
- Some modification of the CDDL array notation ] ... [
- Something looking like symbol swearing #$%@#$% ... #$%@#$%
...

Cheers,
John

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 5 Nov 2020 15:28:38 +0100

Hi John,

as the control for cborseq is introduced in:

> https://tools.ietf.org/html/rfc8610#section-3.8.4

and RFC8742 states that:

>    Currently, CDDL does not provide for unadorned CBOR Sequences as a
>    top-level subject of a specification.  For now, the suggestion is to
>    use an array for the top-level rule, as is used for the ".cborseq"
>    control operator, and add English text that explains that the
>    specification is really about a CBOR Sequence with the elements of
>    the array

it seems to me that you are asking for a specific CDDL notation that can 
represent a cborseq as a top-level subject. Why is using an array here 
not good enough in your case?

Viele Grüße,

Henk

On 05.11.20 13:49, John Mattsson wrote:
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Nov 2020 14:54:11 +0000

Hi Henk,

To quote RFC 8764

1) "CBOR Sequences are already supported as contents of byte strings using the ".cborseq" control operator"
2) "CDDL does not provide for unadorned CBOR Sequences as a top-level subject of a specification"
 
All the document I cited do 2) not 1) .cborseq as currently specified is not a solution.

Cheers,
John

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Date: Thursday, 5 November 2020 at 15:29
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences

Hi John,

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 5 Nov 2020 16:02:08 +0100

Hi John,

I might be totally missing something obvious here - it's just that I am 
having a hard time visualizing your problem at the moment.

Maybe asking the obvious can help (me getting a grasp of the issue). Why 
does the following recommendation from RFC8764 not help you?

>    my-embedded-cbor-seq = bytes .cborseq my-array
>    my-array = [* my-element]
>    my-element = my-foo / my-bar

Viele Grüße,

Henk

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Nov 2020 15:10:35 +0000

Hi Henk,

The CDDL

mathches a CBOR sequence wrapped in a byte string. I.e. "bytes .cborseq [ 1, 2 ]" would match the CBOR encoding 0x420102

All the document I cited use unadorned CBOR Sequences (i.e. not wrapped in a byte string). As far as I know there is no way to write CDDL that matches the unadorned CBOR Sequence 0x0102 ( 1, 2 ). I think this needs to be fixed.

John

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Date: Thursday, 5 November 2020 at 16:02
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences

Hi John,

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Nov 2020 16:46:39 +0100

> All the document I cited use unadorned CBOR Sequences (i.e. not wrapped in a byte string). As far as I know there is no way to write CDDL that matches the unadorned CBOR Sequence 0x0102 ( 1, 2 ). I…

Citing RFC 8742 Section 4.1:

   the array:

   ; This defines an array, the elements of which are to be used
   ; in a CBOR Sequence:
   my-sequence = [* my-element]
   my-element = my-foo / my-bar

   (Future versions of CDDL may provide a notation for top-level CBOR
   Sequences, e.g., by using a group as the top-level rule in a CDDL
   specification.)

Are you talking about the “future versions” part of that?

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 5 Nov 2020 16:55:44 +0100

Hi John,

picking the first of the documents you cited, 
I-D.ietf-6tisch-minimal-security states:

>    For encoding compactness, the Link_Layer_Key object is not enclosed
>    in a top-level CBOR object.  Rather, it is transported as a sequence
>    of CBOR elements [I-D.ietf-cbor-sequence], some being optional.

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.

While I cannot assess, if the bytes saved here warrant the use of a 
cborseq, this seems like a solid spec to me and I wonder why this is not 
a solution therefore needs to be fixed.

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

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 5 Nov 2020 17:05:44 +0100

Or what Carsten said :-) Sry for just sending before checking!

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Nov 2020 16:25:12 +0000

Hi,

>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. The reason I want that updated version is because I want to use 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.

>that would wrap them in an array and would result in a single CBOR data 

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.

John

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Date: Thursday, 5 November 2020 at 16:56
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences

Hi John,

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Nov 2020 18:02:42 +0100

On 2020-11-05, at 17:25, John Mattsson <john.mattsson=[email-masked]> wrote:
> 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?

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

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

---

From: Andrew Weiss <[email-masked]>
Date: Thu, 5 Nov 2020 12:17:48 -0500

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 <[email-masked]> wrote:

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

---

From: Andrew Weiss <[email-masked]>
Date: Tue, 17 Nov 2020 10:43:32 -0500

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 <[email-masked]> wrote:

>> > 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.
>> I’m just arguing that you can use the way of using CDDL for CBOR
>> sequences that is specified today in RFC 8742.
>>