Hi Hannes, This is only about a tiny little part of the EAT spec and is not important for EAT publication.
This is only about how to use CDDL with COSE. It’s not about interoperability or what claims there are in the EAT spec. Hannes, you can probably ignore this thread if you want. To go further… 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 — SUIT just uses simple prose, not CDDL Note that I am only talking about the CDDL link between COSE and the COSE payload. Clearly SUIT, EAT and CoSWID all of which are COSE payloads are described in CDDL. See details below for what I mean by the link. I was quite happy with simple prose, but then I saw what CoSWID did. It seemed worth checking in because CoSWID went to a lot of trouble to do what it did. Right now, I think simple prose is fine and even prefer it. If I were the CoSWID author I would probably stick with simple prose so the CDDL for COSE doesn’t have to be replicated and to allow for COSE encryption. If I were the draft-ietf-cose-rfc8152bis-struct author, I’d make an attempt at a CDDL template for COSE so that future standards could do what CoSWID did without replicating COSE CDDL. If that turned out well, then for future protocols after publication of draft-ietf-cose-rfc8152bis-struct, I’d consider using the CDDL template for COSE messages. LL 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. <https://datatracker.ietf.org/doc/html/draft-ietf-sacm-coswid-19#section-7> COSE-Sign1-coswid<payload> = [ protected: bstr .cbor protected-signed-coswid-header, unprotected: unprotected-signed-coswid-header, payload: bstr .cbor payload, signature: bstr, ] Here it is in prose in SUIT in section 5.2 <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-16#section-5.2>: These blocks are one of: * COSE_Sign_Tagged * COSE_Sign1_Tagged * COSE_Mac_Tagged * COSE_Mac0_Tagged Each of these objects is used in detached payload mode. The payload is the bstr-wrapped SUIT_Digest. Here it is in CWT, section 7.1 in prose <https://datatracker.ietf.org/doc/html/rfc8392#section-7.1> 1. Create a CWT Claims Set containing the desired claims. 2. Let the Message be the binary representation of the CWT Claims Set. 3. Create a COSE Header containing the desired set of Header Parameters. The COSE Header MUST be valid per the [RFC8152 <https://datatracker.ietf.org/doc/html/rfc8152>] specification. 4. Depending upon whether the CWT is signed, MACed, or encrypted, there are three cases: * If the CWT is signed, create a COSE_Sign/COSE_Sign1 object using the Message as the COSE_Sign/COSE_Sign1 Payload; all steps specified in [RFC8152 <https://datatracker.ietf.org/doc/html/rfc8152>] for creating a COSE_Sign/ COSE_Sign1 object MUST be followed. 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. > On Dec 8, 2021, at 4:46 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Carsten, > > I suspect Laurence is sending this email because of his work on EAT. I am > arguing that an attempt to improve the CDDL for the mentioned specs will not > lead to any improvement at all because the problem is elsewhere. I am saying > that because I have just spent many hours reading the EAT spec. > > Ciao > Hannes > > -----Original Message----- > From: Carsten Bormann <[email protected]> > Sent: Wednesday, December 8, 2021 1:37 PM > To: Hannes Tschofenig <[email protected]> > Cc: Laurence Lundblade <[email protected]>; cose <[email protected]>; > [email protected]; Henk Birkholz <[email protected]> > Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD > > On 2021-12-08, at 13:30, Hannes Tschofenig <[email protected]> wrote: >> >> EAT by itself is not really an interoperable spec. COSE on its own is not >> interoperable either. > > If I guess about the definition of "interoperable spec” you are using here, > ASCII is not an interoperable spec either - you still have to agree on what > the text means… Still, ASCII was kind of useful as the basis for a lot of > interoperability, I think. > > I think the point here was to shape some CDDL that makes it easier to talk > about the way a more specific (interoperable?) spec uses COSE (which does > have CDDL, just not in a way that usually can be integrated as-is to express > the additional constraints a COSE-using specification typically makes). > > Grüße, Carsten > > 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
