Subject: Re: [COSE] [Rats] Defining CWT, and JWT in UCCS in EAT

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 4 Jan 2022 13:02:08 +0000

I absolutely would not put the CWT CDDL into RFC8152bis – it is a payload definition, and RFC8152 is nicely agnostic as to payload right now – it makes sense to keep it that way. I agree with Laurence that RFC8152bis needs a way to indicate the payload type.

I think it most logically fits into CWTbis, but depends if:

  1.  There is appetite in ACE to prioritize work on CWTbis and availability of editors for CWTbis
  2.  How well this fits the ACE charter (probably OK, by my reading)

One problem that would need to be addressed with the CWTbis approach is that CWT does not significantly envisage extension, as far as I can tell. Such a change should not break existing CWT implementations (“all claims that are not understood by implementations MUST be ignored”, RFC8392, section 3), but no doubt it would do so in practice. Note that JWT contains almost identical text, and likely has same considerations.

The most generic approach would be to have a new standards track document that defines how to extend both a CWT and a JWT. It would mainly contain the CDDL below, with some explanatory text. Advantage would be that other WGs, and even non-IETF orgs, could use this as the starting point for standardized extensions on both token types. This should be fully in scope for RATS (see “Program of Work”, item 4 in the RATS charter).

Notwithstanding all of the above, I can live with keeping this CDDL in EAT – particularly if alternatives would meaningfully delay publication of a complete standardized attestation format.

Best regards
Jeremy

On 18/12/2021, 18:54, "COSE" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
On Dec 17, 2021, at 1:46 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

So the question is: where should the CDDL for a CWT go? Here’s the main options I can think of:
- EAT
- UCCS
- CWTbis (a revision of CWT to include CDDL)
- Some other new standard
- no where, never create it

I'd say that it should go into RFC8152bis.

Seems it would be as odd going into COSE as it would EAT.

It would create a circular dependency between CWT and COSE. COSE payloads can be lots of different things. We don’t want to collect the CDDL for various the COSE payloads in COSE. The separation between COSE and its payloads is very clean right now.

What should go into COSE is modifications to the COSE CDDL that defines a template by which the type of the payload can be specified (that template would use a .cbor control; see it done in the replicated COSE CDDL in CoSWID section 7 and 8), but that is not what this thread is about.

Below is the CDDL that this thread is about.

If the below CDDL went into its own document, it would be short. Below is the bulk of the document.

What WG and what charter? It needs to be standards track.

LL

   ; This is the fundamental definition of a Claims-Set for both CBOR

   ; and JSON. It is a set of label-value pairs each of which is a

   ; claim.

   ;

   ; In CBOR the labels can be integers or strings with a strong

   ; preference for integers.  For JSON, the labels are always strings.

   ;

   ; The values can be anything, with some consideration for types that

   ; can work in both CBOR and JSON.

   Claims-Set = {

       * $$claims-set-claims,

       * Claim-Label .feature "extended-label" => any

   }

   Claim-Label = int / text

   string-or-uri = tstr

   time-int = #6.1(int)

   ; This is CDDL for the 7 individual claims that are defined in CWT

   ; and JWT.  This CDDL works for either CBOR format CWT or JSON format

   ; JWT.

   $$claims-set-claims //= (iss-label => string-or-uri)

   $$claims-set-claims //= (sub-label => string-or-uri)

   $$claims-set-claims //= (aud-label => string-or-uri)

   $$claims-set-claims //= (exp-label => ~time)

   $$claims-set-claims //= (nbf-label => ~time)

   $$claims-set-claims //= (iat-label => ~time)

   $$claims-set-claims //= (cti-label => bytes)

   iss-label = 1

   sub-label = 2

   aud-label = 3

   exp-label = 4

   nbf-label = 5

   iat-label = 6

   cti-label = 7

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Jan 2022 17:09:22 +0100

On 2022-01-04, at 14:02, Jeremy O'Donoghue <[email-masked]> wrote:
> 
> I absolutely would not put the CWT CDDL into RFC8152bis – it is a payload definition, and RFC8152 is nicely agnostic as to payload right now – it makes sense to keep it that way.

Obviously.

But before I agree with you any further, please note that we are not at liberty to put new work into the two RFCs-to-be (9051 and 9052) that used to be called RFC8152bis.  These are approved documents, and they have long left the WG.

> I agree with Laurence that RFC8152bis needs a way to indicate the payload type.

I don’t understand this sentence, not only because RFC8152bis doesn’t really need anything (see above), but also because there is common header “content type” (label 3), which is a way to indicate the payload type.

Note that CWT is reasonably well-defined (suffering only by the lack of CDDL definitions for the individual registrations, and of a CDDL framework to put these in).  All we seem to be discussing is the editorial matter where to put a CDDL definition that expresses that content.  We are doing this not because we “need” it, but to make it easier to exercise the well-defined extension points CWT offers.

I’m not sure I understand the rest of the message given that background.
There is no need for a CWTbis.  Any document could define that CDDL, even EAT. I’d still prefer to have this CDDL text and the accompanying conventions explained in a separate document.  (No, splitting that out doesn’t need to delay EAT.)  Which WG gets to run the process for agreeing that document is a second-order consideration; the decision should be dominated by quality and expediency considerations (including any rechartering that may be required).  There is no need to wait with writing that document while that decision is being made by the SEC ADs; we can simply discuss it by cross-posting to all candidate WGs.

As a general observation, the IETF is really bad in writing up small tweaks to an existing specification that may be needed for new work unless that happens in the same WG.  Another contributor to the appetite for large, long-running WGs...

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 5 Jan 2022 11:15:18 -0800

Generally agree with what you say below, Carsten.

It is partly my mistake for bringing up 8152bis. I didn’t realize 9051 and 9052 were out. I only brought it up because someone else suggested we put the CWT CDDL in a COSE document.

I believe there has been some confusion between these two:
   1) The CDDL for a CWT
   2) A new CDDL mechanism kinda like .cbor so that the CDDL for an encrypted COSE payload can be specified. There would be two parts to this
       2a) Some additional CDDL control add-on to RFC 8610 that is not COSE-specific
       2b) An add-on to the COSE spec that makes use of the new CDDL control for payload specification

To write a full tight CDDL spec for CWT, we need all off the above. 

But of course the prose-based specification of COSE and CWT are perfectly fine now; the above would just allow all of it to be expressed in CDDL, rather than partly in prose and partly in CDDL.

(Seems like we’re in a transition period into the CDDL era were we are going to have a number of RFCs that add some CDDL to an existing document that isn’t fully CDDL. Some of these will be because CDDL itself is evolving. Not a bad thing, but a transition nevertheless).

LL

> On Jan 4, 2022, at 8:09 AM, Carsten Bormann <[email-masked]> wrote:
>