Subject: [Rats] Claims Characteristics in EAT or in CWT

From: Laurence Lundblade <[email-masked]>
Date: Mon, 13 Apr 2020 13:23:57 -0700

Jim proposed that the EAT-defined claims would be put in their own EAT sub-area of CWT
- They would have a separate IANA registry that could have separate rules, particularly adding the guidelines from this PR <https://github.com/ietf-rats-wg/eat/pull/7>  (which are just guidelines).
- Would occur in CWT’s in a special map defined to hold them.
- Separate label space

The main advantages of this is that EAT could have separate IANA registration rules. There’s also a slight size advantage in that the one-byte labels could be re used.

I don’t think this advantage is out weighed by these disadvantages.

Confusion — Both EAT-oriented use cases and CWT-oriented use cases would likely use claims from both the CWT and EAT registries. Many many claims are going to be generically useful.

More Confusion — It is not particularly obvious to distant implementors and users why these two levels exist and what the rules are for using them.

Confusion Propagates — Future use cases, say endorsements, will inherit this split level because they will want to use claims from both registries.

IANA cross checking required — We would want experts to make sure that a claim wasn’t defined in both places

Replicate for JWT — We’d have to do the same subsetting in JWT with a new EAT JWT registry.

More registries is not better — Doesn’t seem operationally efficient to add two more registries really similar to ones we already have. Also, it is weird if very similar registries have significantly different rules.

Loophole — If someone doesn’t like the EAT rules, they’ll just register a claim under the CWT rules. There’s no way to prevent that.

Decode complexity — It will make CWT and EAT decoder a little more complex. It will also make encode more complex, but not of any significance.

The path of least resistance here is to just put the claims characteristics into the EAT document as a suggestion / recommendation. There would be no formal imposition of these guidelines. They were never meant as more than guidelines anyway.

Another option is to make EAT an update of CWT so it formally changes and adjusts CWT.

Another option is to publish a separate update of CWT.

My plan is to proceed with the path of least resistance, putting them in EAT as guidelines, unless there is support for more formal work on CWT.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 13 Apr 2020 22:16:52 +0000

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Monday, April 13, 2020 at 1:24 PM
To: "[email-masked]" <[email-masked]>
Subject: [Rats] Claims Characteristics in EAT or in CWT

Jim proposed that the EAT-defined claims would be put in their own EAT sub-area of CWT
                                                ^^^^^^^
Nms> Doesn’t sub-area mean the existing assigned tokens are still accessible by EAT? If EAT wanted to assign their own, they would have a separate namespace to allocate from. Or am I not understanding what sub-area means?

- They would have a separate IANA registry that could have separate rules, particularly adding the guidelines from this PR<https://github.com/ietf-rats-wg/eat/pull/7>  (which are just guidelines).
- Would occur in CWT’s in a special map defined to hold them.
- Separate label space

LL

---

From: Dave Thaler <[email-masked]>
Date: Mon, 13 Apr 2020 22:20:18 +0000

One more point is that if someone adds an EAT claim now, and later it’s found to need the same thing for a non-attestation use case,
then you’d end up with an entry in both registries, or else misusing a value out of an EAT registry for a non-EAT use case.

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Monday, April 13, 2020 1:24 PM
To: [email-masked]
Subject: [Rats] Claims Characteristics in EAT or in CWT

Jim proposed that the EAT-defined claims would be put in their own EAT sub-area of CWT
- They would have a separate IANA registry that could have separate rules, particularly adding the guidelines from this PR<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fpull%2F7&data=02%7C01%7Cdthaler%40microsoft.com%7C226eceb82d4a4670f69208d7dfe89c2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637224062455319806&sdata=Fbk5bNxTgE03LqWJ9KwI9w828UfLVhpO5jORYAN7Swk%3D&reserved=0>  (which are just guidelines).
- Would occur in CWT’s in a special map defined to hold them.
- Separate label space

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 14 Apr 2020 13:00:28 -0700

I’ve update this PR <https://github.com/ietf-rats-wg/eat/pull/7> so it is just guidance for creating EAT claims (with suggestion that CWT can use them too) and that EAT is not an update to the CWT RFC. Also, some improved word smithing. I would like to merge it.

To answer Ned’s question, the example in the EAT doc would look like this, if we followed Jim’s proposal

{
   / nonce /                  9:h'948f8860d13a463e8e',
   / time stamp (iat) /       6:1526542894,
   / EAT sub-area /          10:
   {
       / UEID /                  1:h'0198f50a4ff6c05861c8860d13a638ea4fe2f',
       / secure-boot /           2:true,
       / debug-disbale /         3:3,  / permanent-disable  /
    }
}
   
Claim with key / label 10 would be registered in the CWT registry and it would be defined as a map that contains all the EAT claims. Note that I have re used claim key / label 1, 2 and 3 above because it is a new EAT space separate from CWT.

LL

> On Apr 13, 2020, at 3:20 PM, Dave Thaler <[email-masked]> wrote:
> 
> - They would have a separate IANA registry that could have separate rules, particularly adding the guidelines from this PR <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fpull%2F7&data=02%7C01%7Cdthaler%40microsoft.com%7C226eceb82d4a4670f69208d7dfe89c2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637224062455319806&sdata=Fbk5bNxTgE03LqWJ9KwI9w828UfLVhpO5jORYAN7Swk%3D&reserved=0>  (which are just guidelines).

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2020 16:44:29 -0400

> Confusion — Both EAT-oriented use cases and CWT-oriented use cases
    > would likely use claims from both the CWT and EAT registries. Many many
    > claims are going to be generically useful.

I don't quite see the problem.
First, I don't think that they will, once security considerations are taken
into account, that this will happen as often as you think.

*IF* they are generically useful, and the CWT rules work, then register the
claim there.

    > More Confusion — It is not particularly obvious to distant implementors
    > and users why these two levels exist and what the rules are for using
    > them.

I agree: if people are unable to read the RFC, then they won't know.
This happens in all sorts of place.

I don't agree that it's a problem.
I think you are making this much bigger an issue than it is.

    > The path of least resistance here is to just put the claims
    > characteristics into the EAT document as a suggestion /
    > recommendation. There would be no formal imposition of these
    > guidelines. They were never meant as more than guidelines anyway.

I don't really know what "guidelines" means.
Does this mean that you aren't going to register any claims?

    > Another option is to publish a separate update of CWT.

I think that we've heard from COSE WG about this, and the suggestion is reasonable.

    > My plan is to proceed with the path of least resistance, putting them
    > in EAT as guidelines, unless there is support for more formal work on
    > CWT.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 18 Apr 2020 20:02:11 -0700

> I think that we've heard from COSE WG about this, and the suggestion is reasonable.

Sorry for having (presumably) missed the previous discussion, but what is
the proposal that would require EAT to update CWT (vs. just allocating
codepoints)?

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 20 Apr 2020 11:40:15 -0700

> On Apr 18, 2020, at 8:02 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

The thought is these claims characteristics <https://github.com/ietf-rats-wg/eat/pull/7> are just as applicable to claims registered for CWT as they are to EAT. The update would be to add them as guidance (not requirements) for the CWT registry. Perhaps during expert review, the expert, based on the claims characteristics, would ask things like “did you consider adapting the already-standard XXX format to CWT?” or “can you generalize this claim so it is not just for Linux systems?"

It’s clear that many claims defined in the registry will be useful both for EAT and CWT. So far the iat, exp and cti claims defined in CWT are used in EAT. I expect cnf claim to also be common. Going the other way, I expect the nonce and location claims defined in EAT to be useful in CWT. 

I think having hard separation between EAT-use-case claims and CWT-use-case claims is not a good thing. It will lead to the confusion I previously mentioned and I can’t see where there is that much benefit.

So, since the claims are in common and share a registry, the claims characteristics should be in common.

Since there seems to be little appetite among CWT folks for an update that makes these part of CWT, I’m current proposing this as soft guidance in the EAT draft, but I’m also OK just dropping them entirely.

LL