Hi Laurence, I am wondering why you want to do this. The reason is that EAT by itself is not really an interoperable spec. COSE on its own is not interoperable either. With the SUIT manifest we have just stripped it down to the bare minimum to make it interoperable but it is not finished. I have no idea whether CoSWID is an interoperable spec.
Hence, I wonder whether it is just better to reference COSE by saying that they would be refined by a profile. For the SUIT manifest and for CoSWID I would even go a step further and move the "Software Manifests" claim to a separate specification. This specification would be finished after EAT. The main reason is that neither CoSWID nor SUIT are finalized and would block the publication of EAT. Spending more time on the software manifest topic will help to improve the quality of the claim once the details have all been fleshed out (including examples, implementation experience, end-to-end story). Just my 5 cents... Ciao Hannes -----Original Message----- From: Laurence Lundblade <[email protected]> Sent: Tuesday, December 7, 2021 11:17 PM To: cose <[email protected]> Cc: [email protected]; Hannes Tschofenig <[email protected]>; Henk Birkholz <[email protected]> Subject: CDDL for COSE + EAT/CWT + SUIT + CoSIWD Hi, 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: — CoSWID CDDL — SUIT CDDL — COSE CDDL — EAT/CWT CDDL 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. LL IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
