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

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 <mcr+ietf@sandelman.ca> wrote:
> 
> 
> {noticing this is not CC'ed to SUIT or SACM or RATS}
> 
> Laurence Lundblade <lgl@island-resort.com> wrote:
>> 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
> 
> 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.
> 
>> 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,
>> ]
> 
> ...
> 
>> 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.
> 
> 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   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose