Hi Laurence,
If you only care about how to use COSE CDDL in your spec then the answer is
simple:
1. If you are happy with the constructs offered by COSE, then you just use
the COSE CDDL constructs.
2. If you have to apply additional constraints to the use of COSE
primitives, then you have two options:
* Describe them in the text of the spec.
* Restrict the CDDL (which would correspond to “modifying” the COSE
CDDL).
In my experience, if you use anything beyond the most basic COSE primitives
then you are in case #2.
In many cases, you are problably going to be interested in
authentication/integrity protection (COSE_Sign/COSE_Mac), and encryption. With
encryption challenges will arise.
Ciao
Hannes
From: Laurence Lundblade <[email protected]>
Sent: Wednesday, December 8, 2021 3:31 PM
To: Hannes Tschofenig <[email protected]>
Cc: Carsten Bormann <[email protected]>; cose <[email protected]>; [email protected]; Henk
Birkholz <[email protected]>
Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD
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]<mailto:[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]<mailto:[email protected]>>
Sent: Wednesday, December 8, 2021 1:37 PM
To: Hannes Tschofenig
<[email protected]<mailto:[email protected]>>
Cc: Laurence Lundblade <[email protected]<mailto:[email protected]>>;
cose <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Henk Birkholz
<[email protected]<mailto:[email protected]>>
Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD
On 2021-12-08, at 13:30, Hannes Tschofenig
<[email protected]<mailto:[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.
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
