[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [5.9.147.112]) (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 [95.129.206.250]) 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 [188.20.219.122]) 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

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