[Cbor] Using cddl-control to dissect byte strings

[Christian Amsüss <[e-mail]>]

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