Laurence Lundblade <> Wed, 15 December 2021 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EEC63A110E for <>; Wed, 15 Dec 2021 13:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h-TOaYMPlRpc for <>; Wed, 15 Dec 2021 13:28:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B449D3A110B for <>; Wed, 15 Dec 2021 13:28:28 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id xbp5m3LEUjHgNxbp5mmCz1; Wed, 15 Dec 2021 14:28:27 -0700
X-CMAE-Analysis: v=2.4 cv=LM2j/La9 c=1 sm=1 tr=0 ts=61ba5dfb a=VPU1mRQhDhA4uSX60JRRww==:117 a=VPU1mRQhDhA4uSX60JRRww==:17 a=IkcTkHD0fZMA:10 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=3F5Xlz0UzajNc3dAvK8A:9 a=QEXdDO2ut3YA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Laurence Lundblade <>
In-Reply-To: <9912.1639076050@localhost>
Date: Wed, 15 Dec 2021 13:28:27 -0800
Cc: "" <>, cose <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <9912.1639076050@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfJC1Jd9G4BRKIpW79k0ke4m5yb4XbqJ7YtEef995j1TXBrwrECbul6KloxEMOBBPD7/WDP4i6+8Y6w04CPB2KgJOF89ZFglLfKcP7ULzVssvL3VUFFTn e8CPl7QKSPGCPwVWBGZYy31WqRzD4qLFjcia5CydxxTpdVujXvwqmvZB3UuV1OSdUHU6BRz36i5r2EqllDfZ3749vW8VzbFlFTaZCe2KwDaxVrmqYL91rnvJ rl8c2sD84yA2350wmKJojQ==
Archived-At: <>
Subject: Re: [Cbor] [COSE] CDDL for COSE + EAT/CWT + SUIT + CoSIWD
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: Wed, 15 Dec 2021 21:28:34 -0000

I guess for me this thread is about the state of the art for use of CDDL.

- CDDL seems just fine for protocol messages
- CDDL is missing some pieces when combining CDDL-defined protocols (name spaces, a publication and reference mechanism)
- CDDL is missing some pieces for specifying encryption payloads and maybe draft-ietf-cose-rfc8152bis-struct is not using what is available now for signing/MAC

(This is not any criticism of CDDL; just observing more good things we could do with it).

It seems a relatively new thing where we take the formal protocol specification and computationally and deterministically validate messages and examples the way I’m doing it in EAT (Thx Thomas) and probably others are doing. I haven’t seen it done with ABNF. We usually don’t do it with ASN.1 and [BDC]ER (lack of tools?). Not sure about YANG.

I don’t think it is mandatory that we do this formal validation of 100% of a protocol. Almost 10,000 RFCs and the majority don’t.

So it seems that specifying COSE payloads with .cbor is a “nice to have”, but not mandatory.  We’re still kind of figuring out how to do it.

For example, I find what CoSWID does awkward:
- Replicating code and definitions generally seems poor practice
- It excludes the possibility for encryption
- It doesn’t define what EAT needs, a signed or unsigned message that is always a tag, somewhat motivating me to replicate/author CoSWID CDDL in EAT.

So where I land on this now is to use CDDL as much as possible (in EAT), but don’t push it to where it gets awkward or contorted. Hope that CDDL and COSE get improved so that EATbis and future protocols can easily do more CDDL.


> On Dec 9, 2021, at 10:54 AM, Michael Richardson <> wrote:
> {noticing this is not CC'ed to SUIT or SACM or RATS}
> Laurence Lundblade <> wrote:
>> I am observing how two different protocols that use COSE specify what the COSE payload should be. I am interested because EAT must specify this too. I noticed that they do it different:
>> — CoSWID goes to a lot of trouble to use CDDL via a .cbor control
> probably because CoSWID author (Henk) is also CDDL author, and therefore is
> more expert at using CDDL.
>> — SUIT just uses simple prose, not CDDL
> I think that the question is what kind of advice CBOR and COSE WG should provide to
> other WGs about whether or not to explain things with .cbor controls.
>> Here’s the link between for COSE payload for CoSWID. It is in blue in this CDDL that is replicated from COSE. It occurs in  section 7 of CoSWID. <>
>> COSE-Sign1-coswid<payload> = [
>> protected: bstr .cbor protected-signed-coswid-header,
>> unprotected: unprotected-signed-coswid-header,
>> payload: bstr .cbor payload,
>> signature: bstr,
>> ]
> ...
>> EAT inherits this from CWT so it doesn’t need to say it explicitly.
>> However EAT uses CDDL so it is a possibility that EAT can do what CoSWID did.
> That seems like the right way to me.
> It's unclear to me which direction will work better for people who are not
> CDDL experts.  Consider  that a formal language like CDDL might actually be
> easier to understand for non-native-english speakers!
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]        |   ruby on rails    [
> _______________________________________________
> COSE mailing list