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

John Mattsson <john.mattsson@ericsson.com> Thu, 05 November 2020 16:25 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606B83A17F2 for <cbor@ietfa.amsl.com>; Thu, 5 Nov 2020 08:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9NQRYCuLj3O for <cbor@ietfa.amsl.com>; Thu, 5 Nov 2020 08:25:17 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2074.outbound.protection.outlook.com [40.107.21.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217D53A17F1 for <cbor@ietf.org>; Thu, 5 Nov 2020 08:25:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e76/LEFicbvt6woYOxxx3zhLum1RWeEsYsFb9ZkHDfYMWXqXT0d+s55zAU6mUIkD7sQtiODnPAPGErhyHIXGZa30Zx7vkAuM6LJk+Br51Gk/67RWb8w/jEArkJrqEC7ztzOae/vu4kQYSECOmMZAvOQB7NXPExOckIeTHgUNTiULgm+x2xZlFy4XD9mPDrXITa5pDRlOrSLcdB74+WJ85+qPR0nJOl+Uak6gD2f5HngWZD3e4kDb3elWSjLdCTlKC0GVt3GbAGExMdCKzvJGblws9QqNaDkAZFpobNABBiHBGmIblp0CoPRb6Uno5iXzqQoNRlD2YsnRuQ+JXfZzCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TJS6ARiqxXKKKkLxCfuioyT/Gkrxo5FNbZlO9dF10Hw=; b=NJRe9sJD24CZeOuiXt2fAt4d/88tmL8zxRCo7nzJtRmK8L7BF+lilfObPWDV7dfW7STBwFOAMUIfcymZnqtC6HKwUWEuZkibjh5mejN9LUZqqlif19URDuVwvbwdLF7xMyz4UbhgBmS6N8Y4L1IxIcE0F+PqREccQqOEIgEdWPZ5WVUTWIln1SC7WVVRGzoB9SFVMOro3goh+Y0qomJ0HLIDCj6g+VnfDKIPs6t67aUzqg0rPk1QBW2cKGyimw5L7iHOM0zMbr/PEtn9K3mGSjmgwYArrd0/KsBtlcWK8IcwtG4miLu7iMMVbqmqmq3LzGcUZDpf1K1BW+jX4cJKFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TJS6ARiqxXKKKkLxCfuioyT/Gkrxo5FNbZlO9dF10Hw=; b=Ux5VHUQQ5CS5G1d5ZoWMg+3n/FnYMb0qISGGsjKtG7WDFiNrF8aa1kQEpTTdpBRfhLprnakewrK7Rv+ChahFAKGGpiel+pvHgOfGRipL+GrjOMyLcBlKXQasx0I09qhmKmWghvYbA/wJkHoCfPySO/gnUJZsFoGOvOe3VuZghPg=
Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (2603:10a6:20b:17::24) by AM6PR07MB4932.eurprd07.prod.outlook.com (2603:10a6:20b:32::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Thu, 5 Nov 2020 16:25:12 +0000
Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::951:a4c3:7f39:e39c]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::951:a4c3:7f39:e39c%5]) with mapi id 15.20.3541.019; Thu, 5 Nov 2020 16:25:12 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "cbor@ietf.org" <cbor@ietf.org>
Thread-Topic: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences
Thread-Index: AQHWs3IlKka0ymeJ+0erUQMYOdAYWam5mQIAgAAX5gD///F2AIAAEyCA///72gCAABj/AA==
Date: Thu, 05 Nov 2020 16:25:12 +0000
Message-ID: <5CB44449-A1EB-465A-8A51-14FE14155B68@ericsson.com>
References: <317AB3AB-B1E9-4AD9-911E-559D166E2788@ericsson.com> <d45672c4-b42c-fb0f-3ab5-0fcd7712f29b@sit.fraunhofer.de> <FCE40691-EC98-4A0C-9C3E-59F9018A15C8@ericsson.com> <3f63613d-9571-f739-d517-042b4ca9398d@sit.fraunhofer.de> <B63CB2BF-1F68-4ECB-851B-CD794D1203D9@ericsson.com> <a89f603a-8cc9-21c0-4d75-a78c49efc0e7@sit.fraunhofer.de>
In-Reply-To: <a89f603a-8cc9-21c0-4d75-a78c49efc0e7@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
authentication-results: sit.fraunhofer.de; dkim=none (message not signed) header.d=none;sit.fraunhofer.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [81.225.97.222]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8bb01987-1f90-47e8-6f00-08d881a75f2a
x-ms-traffictypediagnostic: AM6PR07MB4932:
x-microsoft-antispam-prvs: <AM6PR07MB4932DCC51CCDB2B5D94E15F689EE0@AM6PR07MB4932.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aeV65SnnydnvqAgYAFMZXfxIVeaJr2c1lSW2k/Blhyaal62L1QUpXvoZXkuA0WMem9TX8BrIwLlsxifoaCHiKqQRSS4wb7yIkf9pj68hyiFDMEeH8+PPseYpPBtSDoYvW0NC9+3ylxC0qPYhRpqLalTohwgAe3MoOxI6XklbRMee+DV2833XmzDB+d1E0K16LwrPpN3OmXzIjb/Yi350H8RhESHdCp48tKwaSJg9goEChnfb3OKt6El/C2S6cjC+dccmQdH8Zwy3VRmQK6o3t9tlaebPRhKo/Ts7QClrOsU2pPusVyoEIzT0v3M5yKxwYrNs59hSta/t4+JTSL971pA7juymbBcMmjsXf5R+n13bvvdgez1JShCuvb9fs+9J5LwPErI6UHtGVrTXNheGWw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(136003)(39860400002)(376002)(64756008)(6506007)(91956017)(53546011)(6486002)(66476007)(66556008)(76116006)(83380400001)(86362001)(8676002)(66446008)(66946007)(8936002)(44832011)(36756003)(316002)(26005)(110136005)(71200400001)(478600001)(6512007)(5660300002)(2616005)(186003)(33656002)(2906002)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LQWm3fn0Bm6y2tuD2sSF4bBJ9XBUzBygYojlh5ufovIU9UOR2vtLGEs/tLRa/50lscj80C5URspLJK6S34Efo3ZJH8ZEIyD1hGh6b5ANa1TKI/FvF8hJLUB2CVLO/ngh/elEWR8Pxgx6JPC0hK5NUZj/uG/k0bqBK+xprXoZ9XWy5aalGrEroHrOWSN4FuO0JyVJFUblFnuyWUgc3GaqvQAr8xB8en8wAaNVJkj6CaB7GE0ei5+iU4YiyBmH/TZQTFfsz8+S1LWaPXEO6hQvhhgvAjZatPbmTxC7bfttUoBxoQUqPB2llClnCowCei+vzqZ+r5Di16WzQrMbkekkAP0AivMoSpk5q662/DrGlib8/0c9g//VPtsopvMoRs3DtIq4SyMLrZT7ahpVBLJcBtKxHFNMuk4hl68eLM7dxad11f7vE34KcnjvGpd6B6BNVcjsFXIG8/uB3QQ8po6BGPm/hZbcqEl4ndSwXhM3Zm7Jojxs4A1xtMMkp/08g2Sx+FSJekLuIHGUdYmOfGTkUyeUGnG8jm9aotMc2SeWStRO8azIrQ5rmhhe9wQ0Jpvp6wAbkMHo/aFkVs5JY5/YnfpVRmQVC51mn0QPZDYmlHsSyHrPgG0jIIEgkBJeqwcHCMikvpYXl9rl/No50cBMqg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <010360F94B581F47A9B4D0CCF9EE5AB6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB4584.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8bb01987-1f90-47e8-6f00-08d881a75f2a
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 16:25:12.7873 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rOVrrOw1sBXTsRzX5DhP7OjKFmkiTokLd0tAHRwnpNJWMTU4AFu0wVM7D2/xN1JMBQ2UsRvE1BDY5Uwke8T/cKSSU8kXwmC/zkV822iU9L4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4932
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/SZOK_KcuMHPv4-jJGBHbeoGULRo>
Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2020 16:25:19 -0000

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

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

John

-----Original Message-----
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Date: Thursday, 5 November 2020 at 16:56
To: John Mattsson <john.mattsson@ericsson.com>, "cbor@ietf.org" <cbor@ietf.org>
Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences

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



On 05.11.20 16:10, John Mattsson wrote:
> Hi Henk,
> 
> The CDDL
> 
> my-embedded-cbor-seq = bytes .cborseq my-array
> 
> 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 <henk.birkholz@sit.fraunhofer.de>
> Date: Thursday, 5 November 2020 at 16:02
> To: John Mattsson <john.mattsson@ericsson.com>, "cbor@ietf.org" <cbor@ietf.org>
> Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences
> 
> 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
> 
> 
> On 05.11.20 15:54, John Mattsson wrote:
>> 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 <henk.birkholz@sit.fraunhofer.de>
>> Date: Thursday, 5 November 2020 at 15:29
>> To: John Mattsson <john.mattsson@ericsson.com>, "cbor@ietf.org" <cbor@ietf.org>
>> Subject: Re: [Cbor] draft-ietf-cbor-cddl-control-00 should add CDDL notation for CBOR Sequences
>>
>> 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:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
>>>
>>
>