[Cbor] Using cddl-control to dissect byte strings

Christian Amsüss <christian@amsuess.com> Fri, 30 July 2021 11:36 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 17FDB3A272F; Fri, 30 Jul 2021 04:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Vc9v7QY1e_JW; Fri, 30 Jul 2021 04:36:13 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A267F3A272E; Fri, 30 Jul 2021 04:36:10 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net []) by prometheus.amsuess.com (Postfix) with ESMTPS id EA40D4013C; Fri, 30 Jul 2021 13:36:07 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0F2FBD0; Fri, 30 Jul 2021 13:36:07 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown []) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A01CE101; Fri, 30 Jul 2021 13:36:06 +0200 (CEST)
Received: (nullmailer pid 3242182 invoked by uid 1000); Fri, 30 Jul 2021 11:36:04 -0000
Date: Fri, 30 Jul 2021 13:36:04 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: cbor@ietf.org, draft-ietf-lake-edhoc@ietf.org
Message-ID: <YQPkJEnTlT1ndXEf@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/PQyZKHj8XgmUPji"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/F62hXMT8YKW6d9r3QYNKPuz8yDo>
Subject: [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:36:18 -0000


continuing my theme of creatively abusing CDDL constructs, I may have
found a practical use case for .cat that is not just about constants

(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)]


    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

    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?


To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom