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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Dec 2021 14:51:37 +0000

Hi Laurence,

Looking at the EAT draft again I wonder whether it is really necessary to define CWT, and JWT in CDDL for the purpose of this document.
If so, is this document the right place to do so. It is certainly not the place where readers would expect to find it.

Why isn't it enough to define the claims defined in this document in a CDDL format?

Ciao
Hannes

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: Laurence Lundblade <[email-masked]>
Date: Thu, 16 Dec 2021 14:43:57 -0800

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

Similar for CDDL for JWT:
- EAT 
- UCCS/UJCS 
- JWTbis
- Some other new standard 
- no where, never create it

I’ve put it all in EAT so we can see what is necessary and what it looks like. That CDDL is complete and validating against the CBOR examples. There’s only one JSON example and there are minor issues with it validating.

Commenting on the last option first, yes, we could just never standardize the CDDL for the body of a CWT and still standardize claims in CDDL. That definitely leaves a pretty hole in the CDDL specification for EAT, but we could live with it if we had to.

Note that EAT nests recursively through the submods claim, so the submods claim couldn’t really be defined in CDDL unless we have standard CDDL for a CWT body. Same for DEB. The whole left if we never standardize is pretty big.

I would rather have the CDDL surprisingly in EAT rather than never create it.

Next consider the UCCS option. UCCS is an *attestation* document in the RATS WG. Most of its text is attestation security considerations. It is probably less surprising to put there than in EAT, but still somewhat surprising.

CWTbis wouldn’t be too hard if all we were doing was adding CDDL. The CDDL is already written and validated, But what WG and under what charter? 

Then there’s the issue of the CDDL being usable for both CBOR and JSON. It’s not quite as simple as doing it just for CBOR. Opinions vary on how hard it is. Mostly comments have been subjective. The CDDL in EAT is mostly working for both CBOR and JSON. So there is some hard evidence that is not a subjective opinion.

If we chose the option of some other new standard for this, I’d push for doing both CBOR and JSON.

I don’t have strongly formed opinion as to which way to go yet.

One more answer below.

LL

> On Dec 15, 2021, at 6:51 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Laurence, 
>  
> Why isn’t it enough to define the claims defined in this document in a CDDL format?

It seems like a job half done. It is leaving out the main CDDL structure that holds the token together. And, you couldn’t validate any EAT tokens against the normative CDDL using the cddl validate tool.

This is mostly about the CDDL for the body of the token, this in particular:

   ; 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

Claims-Set is used so individual claims can be neatly defined like this:

   $$claims-set-claims //= (ueid-label => ueid-type)
   ueid-type = bstr .size (7..33)
   ueid-label = 11

It is also use to specify the submod claim:

   $$claims-set-claims //= (submods-label => { + text => Submodule })

   ; A submodule can be:
   ; - A simple Claims-Set (encoded in the same format as the token)
   ; - A digest of a detached Claims-Set (encoded in the same format as
   ;    the token)
   ; - A nested token which may be either CBOR or JSON format. Further,
   ;   the mechanism for identifying and containing the nested token
   ;   depends on the format of the surrounding token, particularly
   ;   because JSON doesn't have any equivalent of a CBOR tag so a
   ;   JSON-specific mechanism is invented. Also, there is the issue
   ;   that binary data must be B64 encoded when carried in
   ;   JSON. Nested-Token is defined in the format specific CDDL, not
   ;   here.

   ; Note that at nested token can either be a signed token like a CWT
   ; or JWT, an unsigned token like a UCCS or UJCS, or a DEB (detached
   ; EAT bundle).  The specific encoding of these is format-specific
   ; so it doesn't appear here.

   Submodule = Claims-Set / Nested-Token / Detached-Submodule-Digest
   submods-label = 20

>  
> Ciao
> Hannes
>  
> 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. _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 17 Dec 2021 12:05:58 +0000

Hi Laurence,

I would define it in a separate specification. For those who want to reference the CDDL in their spec, they are probably less interested to explain why such a normative reference has no dependency on attestation.

I understand that you are interested in verify the examples in the spec easily. While this seems to be of great value, my experience tells me that this is less relevant for actual implementations. Why do I say that? There has been prior experience with validating instance documents against schemas dating back to XML. I recall that we also thought that implementations would then perform this validation. It turns out that this was wrong because implementations have to parse the content anyway and perform a semantic analysis as well. In our case, a verifier and a relying party has to verify the received input data against policies, and reference values.

Ciao
Hannes

From: Laurence Lundblade <[email-masked]>
Sent: Thursday, December 16, 2021 11:44 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Defining CWT, and JWT in UCCS in EAT

One more answer below.

LL

On Dec 15, 2021, at 6:51 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

   ; claim.

   ;

   ;

   Claims-Set = {

       * $$claims-set-claims,

   }

   Claim-Label = int / text

   string-or-uri = tstr

   ueid-label = 11

   ; A submodule can be:

   ;    the token)

   ;   here.

   submods-label = 20

Ciao
Hannes

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. _______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Dec 2021 16:46:51 -0500

> - no where, never create it

I'd say that it should go into RFC8152bis. (bis-bis. There is another german
term here).    It's still in AUTH48 right now.  Maybe an appeal to put it in
could occur in cose@

If it too late for that, then in an errata, or another document.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Dec 2021 22:58:19 +0100

On 17. Dec 2021, at 22:46, Michael Richardson <[email-masked]> wrote:
> term here).    

??

> It's still in AUTH48 right now.  Maybe an appeal to put it in
> could occur in cose@
> 

There is no errata.

There is a missing feature — making it easy to interact with the COSE specification via CDDL.
Missing features are addressed in new documents, not in AUTH48.
Certainly not in AUTH48 if there is considerable leeway for designing it and nothing in the original document depends on it.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Dec 2021 17:54:21 -0500

Isn't there a word for "thrice", which rarely used?
I mean RFC8152bis-bis here.

    > Certainly not in AUTH48 if there is considerable leeway for designing
    > it and nothing in the original document depends on it.

I agree that it's probably too late.
Documents have been extracted out at AUTH48 before and returned to the WG
when the WG realized that events had overtaken.

--
]               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: Carsten Bormann <[email-masked]>
Date: Sat, 18 Dec 2021 02:07:53 +0100

> On 17. Dec 2021, at 23:54, Michael Richardson <[email-masked]> wrote:
> 
> 

ter.  But that’s more of a French thing than German.

> when the WG realized that events had overtaken.

Nothing in COSE is overtaken.
This missing feature (of the specification, not of what is specified) is irking us when we put specs on top of COSE, but the COSE standard works fine without it.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 18 Dec 2021 10:53:58 -0800

On Dec 17, 2021, at 1:46 PM, Michael Richardson <[email-masked]> wrote:
> 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

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

   Claims-Set = {
       * $$claims-set-claims,

   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