Re: [Cbor] Using cddl-control to dissect byte strings

Carsten Bormann <cabo@tzi.org> Fri, 30 July 2021 11:55 UTC

Return-Path: <cabo@tzi.org>
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 D582B3A27B9; Fri, 30 Jul 2021 04:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hSO1HesBtLm; Fri, 30 Jul 2021 04:55:39 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB753A27B7; Fri, 30 Jul 2021 04:55:39 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Gbm7F1t8Xz2xM8; Fri, 30 Jul 2021 13:55:37 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <YQPkJEnTlT1ndXEf@hephaistos.amsuess.com>
Date: Fri, 30 Jul 2021 13:55:36 +0200
Cc: cbor@ietf.org, draft-ietf-lake-edhoc@ietf.org
X-Mao-Original-Outgoing-Id: 649338936.863789-d7146c7e2082085fec6e0c5408fb23c9
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1CB86D0-20DA-40DB-899E-23A10BD56B71@tzi.org>
References: <YQPkJEnTlT1ndXEf@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/VQ1lv_c-NWr_Ale88z64JXDzONY>
Subject: Re: [Cbor] Using cddl-control to dissect byte strings
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: Fri, 30 Jul 2021 11:55:44 -0000

I think the subject of this message should be 

## Using cddl-control to make CBOR even less schema-less

But indeed, what you propose is one way to compose your byte strings, if you *have* to do it.

I’d probably use .abnfb for many of these; at least if (like in this example) you don't need to go back to CDDL names (which is a shortcoming I have a plan for, but that will happen later this year).

You mentioned the cddl tool generator — does the validator choke on this?

(I don’t want to think about .det here.)

(BTW: I would like to fix one bug in the generics implementation before we aggressively market the use of generics to the CDDL user crowd.)

(BTW^2: Why the [()]?  It does look very important, but maybe not necessary?)

Grüße, Carsten


> On 2021-07-30, at 13:36, Christian Amsüss <christian@amsuess.com> wrote:
> 
> Signed PGP part
> Hi,
> 
> continuing my theme of creatively abusing CDDL constructs, I may have
> found a practical use case for .cat that is not just about constants
> handling.
> 
> (The usual caveats for these tricks apply: While CDDL has the
> expressitivity to do it, common tools WILL PROBABLY NOT implement the
> full genericness).
> 
> In EDHOC, a byte shaving step may require moving two semantically
> separate byte strings, one of which has known length, into a single byte
> string; in a minimal similar example:
> 
>    message = [(number: uint, key: bstr, data: bstr)]
> 
> becomes
> 
>    message = [(number: uint, key_and_data: bstr)]
> 
> Unfortunately, this means parsers built from the CDDL will need an
> additional manual step in which the implementer writes down the prose
> description of key_and_hash into code that splits key from hash.
> 
> With cat, this can be expressed in a way that the CDDL parser generator
> has a chance to do the right thing again:
> 
>    message = [(number: uint, key .cat data)]
>    key = bstr .size 16
>    data = bstr
> 
> As the length depends on earlier exchanged messages, one might use
> generics to pull out the constant of 16 -- probably breaking the tool's
> neck in the process: (Carsten's Ruby generator tool is still with me on
> this)
> 
>    message_alg42 = message<4>
>    message<L> = [(number: uint, key<L> .cat data)]
>    key<L> = bstr .size L
>    data = bstr
> 
> 
> I don't know at this point whether any form of this should be suggested
> for use with EDHOC if and when the byte shaving change is performed.
> 
> Opinions from CBOR?
> 
> Thanks
> Christian
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom
> 
>