Subject: [Rats] EAT / CWT / JWT

From: Laurence Lundblade <[email-masked]>
Date: Sat, 22 Jun 2019 12:34:17 -0700

Here’s a proposed position on EAT in relation to CWT and JWT and claim definition. This roughly gives a position on many of the issues identified by Kathleen. I didn’t attend the interim meeting and haven’t seen notes from it, so don’t know how this lines up with that discussion.

An EAT is either a CWT or a JWT. The difference is just syntax / encoding.

When this WG defines an EAT claim we will define it for both CWT and JWT and register it in both registries. 

Just like with CWT and JWT, there is no formal requirement or mechanism that requires that a claim be defined or registered for both, so folks outside this WG may define an attestation for just CWT or just JWT, the same as it is for the authentication use cases.

We will not modify the main rules given in the CWT and JWT RFCs for for registration of new claims. (Note that CWT and JWT have different set-ups for claim registration. JWT is always Specification Required (which requires expert review)). CWT has several levels. Seems a bit weird to me that they are different.)

Claims defined by this WG are standards track so they pass both criteria.

Others wishing to define a  claim for both CWT and JWT that is not standard track must meet the “Specification Required” criteria because that is the minimum set by JWT and it is higher than that set for CWT.

The primary means for use cases and implementations to settle on only high-quality claims is through the creation of profiles, not through the claims registration process (expert review and such). Some profiles could be IETF standards.

I believe I know how to write down the information model in CDDL and deterministically derive the JSON and CBOR data models from it.

It doesn’t make sense to me to not have CWTs and JWTs used for attestation as anything but equivalent. 

I’m not clear yet if we need to some how mark CWT and JWTs some how when they are used for entity attestation. Maybe you can always tell by context. Maybe not. 

LL

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 11:18:49 -0400

Laurence Lundblade <[email-masked]> wrote:
    > We will not modify the main rules given in the CWT and JWT RFCs for for
    > registration of new claims. (Note that CWT and JWT have different
    > set-ups for claim registration. JWT is always Specification Required
    > (which requires expert review)). CWT has several levels. Seems a bit
    > weird to me that they are different.)

I can not speak authoritatively for the writers, but let me try to explain:

1) JWT claims are always strings, and it's therefore always easy to come up
   with a unique private slug (just insert domain name, or PEN).  Any claim
   that is worth standardizing in a public fashion (vs defacto API from
   example.com) should have widespread understanding, and thus a good
   specification. (Yes, Spec. Required requires an expert to agree that the
   specification is legit)

2) CWT claims can also be strings (and thus all the points in (1) apply), but
   if you want to use the small-byte-count integers, then you want the registry.
   There are different mechanism in CWT to reflect the fact that the
   different categories of CBOR integers are limited in size.  The shortest
   items should be reserved for things that occur a lot.

    > Others wishing to define a claim for both CWT and JWT that is not
    > standard track must meet the “Specification Required” criteria because
    > that is the minimum set by JWT and it is higher than that set for CWT.

I'm not sure that this is precisely the case.
Others wishing to define non-standard claims can do so with strings.
JWT calls these

   Collision-Resistant Name
      A name in a namespace that enables names to be allocated in a
      manner such that they are highly unlikely to collide with other
      names.  Examples of collision-resistant namespaces include: Domain
      Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
      X.670 Recommendation series, and Universally Unique IDentifiers
      (UUIDs) [RFC4122].  When using an administratively delegated
      namespace, the definer of a name needs to take reasonable
      precautions to ensure they are in control of the portion of the
      namespace they use to define the name.

My opinion is that such claims in a RATS context may have little long-term
value, but I would expect them to be used in experimental ways regularly.

    > attestation as anything but equivalent.

Due to the signature, they are not interchangeable.
While many constrained devices would prefer CWTs, and most non-constrained
environments can affort to have two libraries, I wonder if we can prefer CWT?

At the same time, I've heard that some vendors have JSON libraries already
and feel that CWT would require new work.  I'm not convinced, because I think
that the distance between JSON and JWT involves adding a crypto library, and
that's significant.

    > I’m not clear yet if we need to some how mark CWT and JWTs some how
    > when they are used for entity attestation. Maybe you can always tell by
    > context. Maybe not.

To disguish JWT vs CWT?
A JWT probably always starts with "{" :-)
A CWT probably always starts with CBOR tag 61.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 Jun 2019 09:30:21 -0700

Hi Michael,

> On Jun 25, 2019, at 8:18 AM, Michael Richardson <[email-masked]> wrote:
> 
>> registration of new claims. 

Will do even more reading on the labels / keys / registration issue and get back.

> that the distance between JSON and JWT involves adding a crypto library, and

Here's what I meant when I used the word equivalent:
-  Claims in CWT and JWT have the same expressive power
- Any claim we standardize for JWT is also standardized for CWT and vice versa
- A standard claim in JWT has the same semantics as a standard claim in CWT and vice versa
- The information model is the same for both (see 
- You never run into this: “if you were using a CWT for attestation for claim XXX it works great, but unfortunately JWT based attestations can’t do that"

The syntax (data model) of the claims is obviously different as is the signature.

I’m not saying conversion back and forth is part of equivalence or is a goal, though it does seem like something that would be nice to have. Obviously, the steps to do that are roughly: 1) Verify the signature on the original, 2) parse each claim, 3) generate the new syntax for each claim, 4) re sign in the new format. And do this is in a secure computing environment of some sort.

The main thing is that an implementor does not need to choose between CWT and JWT because of claims that are available in one and not the other.

> A CWT probably always starts with CBOR tag 61.

To distinguish the use of CWT for attestation from the use of CWT for authentication or other. Same to distinguish the use of JWT for attestation from the use of JWT for authentication. You might not be able to tell by the claim set. 

I know you can tell in some use cases by the way it is carried in the protocol. For example if an EAT is used for attestation in FIDO, the FIDO protocol will clearly label it as attestation. Probably in a YANG RPC used with a router, it will also be clearly labeled as an attestation.  But maybe there are some contexts that it is not. 

This has some similarity to X.509 extended key use. You say whether the key is used for email encryption, server authentication, code signing…

As I said, I don’t have a strong opinion on this one way or another, but it seems like part of figuring out how CWT and JWT are used for EAT.

LL

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Jun 2019 12:44:04 -0500

> As I said, I don’t have a strong opinion on this one way or another, but it seems like part of figuring out how CWT and JWT are used for EAT.

Is this just a matter of defining a JWS "typ" parameter (i.e., media type)
for our usage [https://tools.ietf.org/html/rfc7515#section-4.1.9]?  (I did
not check for the COSE analogue.)

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 26 Jun 2019 11:33:13 -0700

Comment below

> On Jun 26, 2019, at 10:44 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
>>> ...
> for our usage [https://tools.ietf.org/html/rfc7515#section-4.1.9]? <https://tools.ietf.org/html/rfc7515#section-4.1.9]?>  (I did
> not check for the COSE analogue.

Yes, there’s a COSE analog, the content-type header. The IANA registry is here <https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats>. Seems pretty similar, but not the same (as often seems to be the case with CWT and JWT).

LL