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

Carsten Bormann <> Thu, 05 November 2020 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA3A53A181F for <>; Thu, 5 Nov 2020 09:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CtGGNqMwaEjL for <>; Thu, 5 Nov 2020 09:02:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2937E3A1815 for <>; Thu, 5 Nov 2020 09:02:45 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4CRqZp5jvfzyWV; Thu, 5 Nov 2020 18:02:42 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 05 Nov 2020 18:02:42 +0100
Cc: Henk Birkholz <>, "" <>, Andrew Weiss <>
X-Mao-Original-Outgoing-Id: 626288562.324324-04eb3f9cc35f9ad70cd6411fc7d90188
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: John Mattsson <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2020 17:02:49 -0000

On 2020-11-05, at 17:25, John Mattsson <> 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