Laurence Lundblade <lgl@island-resort.com> Tue, 07 December 2021 22:16 UTC

Return-Path: <lgl@island-resort.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 7D6033A0112 for <cbor@ietfa.amsl.com>; Tue, 7 Dec 2021 14:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 bL1t1gDYEnhb for <cbor@ietfa.amsl.com>; Tue, 7 Dec 2021 14:16:55 -0800 (PST)
Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B653A00D3 for <cbor@ietf.org>; Tue, 7 Dec 2021 14:16:54 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id uilZmlnWnUZTIuilamGnu8; Tue, 07 Dec 2021 15:16:54 -0700
X-CMAE-Analysis: v=2.4 cv=V+24bcri c=1 sm=1 tr=0 ts=61afdd56 a=VPU1mRQhDhA4uSX60JRRww==:117 a=VPU1mRQhDhA4uSX60JRRww==:17 a=IkcTkHD0fZMA:10 a=dRGUXtHy4CwCIdc_utsA:9 a=QEXdDO2ut3YA:10
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <85278E84-AD34-4F68-94DC-437BABCCD621@island-resort.com>
Date: Tue, 07 Dec 2021 14:16:53 -0800
Cc: cbor@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
To: cose <cose@ietf.org>
X-Mailer: Apple Mail (2.3608.
X-CMAE-Envelope: MS4xfHlGKqHqP/40Hrwr2oC3E3cDGWuXb3gBjA8KGz/EQ4yFp5YWFlqOK24P6vW/8yR7SYfnbCNjSGRLlSsEHLDpE43kHK4y9qs6a3U+fuujN3fXdmFrgK+U DMTj7q2+L1d5HG7D1dwsfwXHoHlUc4b2ImuGDodXYIWY65QXdH7ERoidqyjYbVWOtXUDWAFMWOOOgJCbNjtjb7ltb6Is9fG5jrJMViWAApzgIuN7jfd04aSq ZqcoIX/EgThqJwkO8n7Y5VXx6dLGzuXWFZO+6c6CySMIzr7k2QNZhdCoFHunPy2S
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/gGDLWk8YlcRtMg0Y-aHyb-ddLIs>
Subject: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD
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: Tue, 07 Dec 2021 22:16:58 -0000


Not sure where this will go, but thought it worth running up the flag pole.

To validate EAT CDDL I’m pulling in *all* of these into one:

I have diag format EAT example tokens with claims that are CoSWIDs that validate against the above.

CoSWID replicates and modifies a lot of COSE CDDL in normative text primarily so it can fully specify the COSE payload with a .cbor control. 

SUIT doesn’t replicate COSE. It specifies the COSE payload in prose.

I have thus far taken SUITs approach as I don’t want to replicate and modify COSE CDDL. EAT also must support nesting of COSE encryption inside COSE signing and such. (It seems CoSWID’s approach actively prohibits COSE encryption).

In an ideal world, I think the CDDL in the COSE struct draft would some how use a CDDL template through which one could specify the CDDL for the COSE payload.  This CDDL template would work for COSE signed, then encrypted or encrypted then MAC’’d and any other nesting of COSE. In this ideal world CoSWID wouldn’t have to replicate CDDL from COSE and SUIT and EAT could use it too. I’m not sure this ideal COSE CDDL is possible though.

Has anyone considered writing the COSE CDDL this way?

Another problem with the replicated COSE CDDL in CoSWID in the EAT document build and validate is that there is collision between the names of CDDL rules. I’m just manually tweaking stuff to get around this. CDDL name spaces would fix this.

If the world stays the same (no change to COSE struct document or CoSWID) I can make EAT work as follows:
 - No .cbor control to specify the COSE payload, only prose
 - Some non-normative, unpublished glue CDDL that is part of the EAT document build and example validation script is needed.