Subject: [COSE] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Dec 2021 14:16:53 -0800

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Dec 2021 23:21:53 +0100

> Has anyone considered writing the COSE CDDL this way?

Yes.  I think that is easy to do for MACed/signed, not so easy for encrypted (because that is not transparent to the CDDL engine).

We could define a control operator for the encryption.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Dec 2021 12:30:05 +0000

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-masked]>
Sent: Tuesday, December 7, 2021 11:17 PM
To: cose <[email-masked]>
Cc: [email-masked]; Hannes Tschofenig <[email-masked]>; Henk Birkholz <[email-masked]>
Subject: CDDL for COSE + EAT/CWT + SUIT + CoSIWD

Hi,

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.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Dec 2021 13:36:42 +0100

On 2021-12-08, at 13:30, Hannes Tschofenig <[email-masked]> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Dec 2021 12:46:34 +0000

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-masked]>
Sent: Wednesday, December 8, 2021 1:37 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>; cose <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Dec 2021 14:26:42 +0100

Hi Hannes,

> On 2021-12-08, at 13:46, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Carsten,
> 

Thank you for clarifying this, providing the RATS perspective that I’m missing here.

I’m glad to hear that EAT only has one problem :-) (“the problem”).

I still think that doing the work I was outlining would help us in various specifications.
And when it comes to EAT, I’m assuming that at some point we want to describe EAT claims with some statements about their structure, which would naturally use CDDL.  But that may not be needed for the initial EAT specification; I haven’t checked that.  If it is not needed, it might be too much of a distraction to apply the work I was outlining to EAT now.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 8 Dec 2021 06:30:54 -0800

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-masked]> wrote:
> 
> Hi Carsten,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Dec 2021 14:45:46 +0000

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-masked]>
Sent: Wednesday, December 8, 2021 3:31 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; cose <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

Hi Hannes,

To go further…

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>

       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

Here it is in CWT, section 7.1 in prose<https://datatracker.ietf.org/doc/html/rfc8392#section-7.1>

       Set.

       Parameters.  The COSE Header MUST be valid per the [RFC8152<https://datatracker.ietf.org/doc/html/rfc8152>]

       specification.

       there are three cases:

          steps specified in [RFC8152<https://datatracker.ietf.org/doc/html/rfc8152>] for creating a COSE_Sign/

On Dec 8, 2021, at 4:46 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carsten,

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 8, 2021 1:37 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; cose <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

On 2021-12-08, at 13:30, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Dec 2021 16:08:17 +0000

Hi Carsten,

Let us ignore the current status of the EAT spec for a moment.

Laurence was saying:
"

"

The statement about SUIT is only partially true. At the beginning we only referenced COSE and didn't "modify" (or profiled anything) because we thought we don't need to do it.
When we started the work on firmware encryption we suddenly realized that this is not really practical. You need to provide more rules on how to use COSE to provide implementers enough context to build interoperable specifications. That's why the firmware encryption draft modified the COSE CDDL and later it then introduced HPKE (instead of using an alternative public key encryption scheme specified in COSE itself).

It is unclear to me whether a similar approach will be needed for the SUIT manifest as well. It might be insufficient to say "use COSE_Sign, COSE_Sign1, COSE_Mac, and COSE_Mac0" alone. One could write the additional constraints into the specification text but it might be better to take the respective CDDL fragment and modify it accordingly.

Ciao
Hannes

PS: I am not sure whether the ".cbor control" is an important concept in this conversation.

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Sent: Wednesday, December 8, 2021 2:27 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>; cose <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Cbor] CDDL for COSE + EAT/CWT + SUIT + CoSIWD

Hi Hannes,

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 8 Dec 2021 09:47:04 -0800

> PS: I am not sure whether the ".cbor control" is an important concept in this conversation.

It is absolutely critical and central to the topic I brought up. It is the only thing I wanted to talk about.

But, happy for you to discuss other things about COSE.

LL

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Dec 2021 13:54:10 -0500

{noticing this is not CC'ed to SUIT or SACM or RATS}

    > — 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.

    > payload: bstr .cbor payload,

...

    > 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 15 Dec 2021 13:28:27 -0800

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.

LL

> On Dec 9, 2021, at 10:54 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Dec 2021 22:57:17 +0100

Hi Laurence,

I hope that the CBOR WG takes good note of these observations:

> On 2021-12-15, at 22:28, Laurence Lundblade <[email-masked]> wrote:
> 

Right, and that is what the 2.0 work is trying to address (at least partially).
Workarounds do exist.

> - 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

Indeed.  Some of this could be added easily by defining control operators in drafts that need extended functionality for CDDL.  Some of this is just conventional usage that simply needs to be worked out.  I’m sure the CBOR WG is interested in doing just that, and the COSE WG should be interested, too (with the caveat that this must not slow down current publication processes).

A separate document that describes how to best use CDDL with COSE would be optimal, but simply defining the CDDL conventions needed inside a spec that uses CDDL also works.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Dec 2021 10:18:45 -0500

Laurence Lundblade <[email-masked]> wrote:
    > - 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.

I think that this is because we haven't gotten a library/public-include
system for CDDL.  So the urge is to make documents self-contained.

Given the audience for CoSWID is largely outside of the IETF, in a sector of
the industry that is, at present, very immature, I think that CoSWID did the
right thing.

EAT is a bit more inward facing (given TEEP, SUIT, etc. customers), or at
least, the external audience is a lot more mature (TCG, CCC, ...), so perhaps
the outgoing references are really a sign of the direction we should be
going.

As Carsten said, the CBOR WG needs to think about how exactly to use CDDL.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 16 Dec 2021 10:58:47 -0800

> system for CDDL.  So the urge is to make documents self-contained.

It didn’t replicate all of the COSE CDDL, just the parts to enable control of the headers and to allow specification of the payload with .cbor.

It did replicate not enough to be self-contained, so I don’t think that is the reason.

Also, it doesn’t just replicate the CDDL, it modifies it! This is so the CDDL also controls some of the COSE headers. (Again, I find this odd and awkward; CWT and EAT don’t try to control the COSE headers).

I think the reason is so the CDDL specification is more thorough and covers more of the CoSWID protocol. It is so prose is not relied upon for these.

It is also a cool use of CDDL templates.

LL

Note, that I have replicated COSE CDDL in the EAT document build system so I can do thorough CDDL validation of the EAT examples, but it is not part of the published document. I’m also using curl to fetch CoSWID and SUIT CDDL for this. All of this is because we don’t have a scheme for publish/reference, #includes and such. If all this broke because the URLs changed or the CDDL in CoSWID CDDL in GitHub was refactored or such, all that would break is the CDDL validation. The EAT document and building of the EAT document doesn’t rely on any of it. (Thanks Thomas)