From nobody Thu Nov 5 09:18:03 2020 Return-Path: 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 2D93B3A1933 for ; Thu, 5 Nov 2020 09:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=github.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 P0ogzEOJdTE1 for ; Thu, 5 Nov 2020 09:18:00 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FCD3A1324 for ; Thu, 5 Nov 2020 09:18:00 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id n11so2129790ota.2 for ; Thu, 05 Nov 2020 09:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BXw5h7MpsZFynM0xvF0yzYfZXful/mh4IlzZBwThLL8=; b=Q955X4z4WXtyK6JAbo7bLe8YxS7vjSw2FfqJ9vA1fKZurPKaC9LuQ9IjnuKNsZPVVo SYjgkYj2XSAekzRRFCkw1s+WAlNJYvVsQhMfcj29RMX6F/mRHQy3YAEHLldc0KE1U/FH zkS2Zm3PCrL4BcEm1RWJE0O9n6AioOuvl2JdaJn7RTLdFn7RKg1Oq7MaUWMvsGxM1UJT I3T/B62FlJFU9puEgD/FNW3oH4xM5tW5kZilVbqOXtL+UMjzUTF6QvfnROFLLd+SJ60s n5XzCVe9yoaYM1zmGXu7PaeDUeB6nZysWe6u1QtuxU276atO4SPHtGf11uELNyenNfht iedA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BXw5h7MpsZFynM0xvF0yzYfZXful/mh4IlzZBwThLL8=; b=fuTwJbmtdHv+1aOhI/0ulQH6fGM/LcfF0nv1OiBy/zyEUjDaToeTHxyfBKbLLAXTJs cTqoQnmkY6P5McFJrQxiogfoVb2wwBYG6sM4A/3x96JvbI9Xa7J6cWa2K5lB3Noji53Y gN3bSi0TWncMQ38OhW1goGy32NnEDYqi7zLtXwcVhkMoouTJQ9WUf0ZXxhyU7K11qtiy 2Zm+4vmjLJr3xrcpJOM5MbSejAZGe1+N+jrqm80nlMAjICQxF1Y/GLty8dVB+mfl432h qQxWiLdL2A4Bi/+55HkuPibFIz77U6B+7Z85ldzeaI3podE2bV/ZSJoNVuw/PmvwXzwJ 9Skw== X-Gm-Message-State: AOAM531Jifsx+7jzYaU/PlNaqJasMm24z7sjsMzlRVxs+LVqA7yqnRgj CAeHvsfAHHpFK72FmQpem9r3ZPRjkuJudr0Dx7z4Hg== X-Google-Smtp-Source: ABdhPJwcxAGVvXtMop1bDNVg0LS6RRJP9obbUClms0TEz/lAkf99xIrX6Q6Egy5BCxWW+ZqZ/6/pA9uyuE9od3koMzo= X-Received: by 2002:a9d:bec:: with SMTP id 99mr2501048oth.103.1604596679500; Thu, 05 Nov 2020 09:17:59 -0800 (PST) MIME-Version: 1.0 References: <317AB3AB-B1E9-4AD9-911E-559D166E2788@ericsson.com> <3f63613d-9571-f739-d517-042b4ca9398d@sit.fraunhofer.de> <5CB44449-A1EB-465A-8A51-14FE14155B68@ericsson.com> <4CBAFAE0-EB02-4E02-9CAD-D7E0AB546F06@tzi.org> In-Reply-To: <4CBAFAE0-EB02-4E02-9CAD-D7E0AB546F06@tzi.org> From: Andrew Weiss Date: Thu, 5 Nov 2020 12:17:48 -0500 Message-ID: To: Carsten Bormann Cc: John Mattsson , Henk Birkholz , "cbor@ietf.org" Content-Type: multipart/alternative; boundary="000000000000170d3705b35f4767" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:18:02 -0000 --000000000000170d3705b35f4767 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > On 2020-11-05, at 17:25, John Mattsson 40ericsson.com@dmarc.ietf.org> wrote: > > > > Hi, > > > > Henk wrote: > >> Circling back to my initial reply, I am still under the impression tha= t > >> 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 =E2=80=9Cfuture versions=E2=80=9D part of th= at? > > > > 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=E2=80=99t see why.) > > The reason that this is under =E2=80=9Cfuture=E2=80=9D is that there is n= o urgency to > re-spin CDDL at this point =E2=80=94 we can handle all current issues wit= hin the > extension points (at least until we do the module structure =E2=80=94 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= =E2=80=99s > CDDL. > > > The > > alternative is to not use CDDL, or as suggested by RFC 8742 and use CDD= L > 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 (=E2=80=9CEnglish=E2=80=9D or in your implemen= tation 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 dat= a > >> 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=E2=80=99m not arguing for converting the CBOR sequence into a single CB= OR data > item. > I=E2=80=99m 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=E2=80=99ll take that as an action point now. > > Andrew =E2=80=94 where is your tool with respect to handling RFC 8742 CBO= R > sequences? > > Gr=C3=BC=C3=9Fe, Carsten > > --000000000000170d3705b35f4767 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Carsten,

I haven't yet implemen= ted 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 <cabo@tzi.org> wrote:
On 2020-11-05, at 17:25, John Matt= sson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> 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 =E2=80=9Cfuture versions=E2=80=9D part o= f 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.=C2=A0 (I don=E2=80=99t see why.)

The reason that this is under =E2=80=9Cfuture=E2=80=9D is that there is no = urgency to re-spin CDDL at this point =E2=80=94 we can handle all current i= ssues within the extension points (at least until we do the module structur= e =E2=80=94 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=E2= =80=99s CDDL.

> The
> alternative is to not use CDDL, or as suggested by RFC 8742 and use CD= DL together with human readable text. The human readable text cannot be use= d for automatic verification unless you have a very smart AI.

You already need something (=E2=80=9CEnglish=E2=80=9D or in your implementa= tion 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 sequ= ence 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 ite= ms
>> (key_id, key_usage, key_value, key_addinfo) in order to safe the b= ytes
>> 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 understandin= g is that the result is a CBOR sequence (not a single CBOR data item). In E= DHOC we have taken every possible measure to shave of bytes so that the mes= sage can fit in 5-hop 6TiSCH and LoRaWAN. The resulting CBOR sequence for m= essage_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 fi= t inside a single frame. There is absolutely no possibility to take the cos= t of even a single extra byte.

I=E2=80=99m not arguing for converting the CBOR sequence into a single CBOR= data item.
I=E2=80=99m just arguing that you can use the way of using CDDL for CBOR se= quences that is specified today in RFC 8742.

Henk has pointed out to me in separate conversation that my CDDL tool is no= t yet sequence-friendly; I=E2=80=99ll take that as an action point now.=C2= =A0

Andrew =E2=80=94 where is your tool with respect to handling RFC 8742 CBOR = sequences?

Gr=C3=BC=C3=9Fe, Carsten

--000000000000170d3705b35f4767--