Re: [Rats] EAT Review Comments

[Laurence Lundblade <[e-mail]>]

First of all, I really appreciate the thorough reading. This is probably the first deep substantive set of comments ever made on EAT.


> On Dec 7, 2021, at 3:49 AM, Hannes Tschofenig <[e-mail]> wrote:
> 
> Hi all,
> 
> As promised, here are some high-level review comments, which are most important to us:
> 
> - The document would benefit from a normative language. Think in the following way: What does a party creating a claim and a party verifying the claim have to do in order to ensure interoperability. Use SHOULDs and MAYs when you can give the reader a decision path.
> 
> - Don't put comments into the CDDL since the same text is already in the draft. You are essentially putting the text in the document twice. This will reduce the size of the document.
> 
> - Normative vs. informative references: If you need to read a specification as a developer in order to implement a listed claim then this reference is normative. For example, the location claim cannot be implemented without having to open the W3C geolocation API. Hence, that reference becomes normative.
> 
> - Aim for consistent use of terminology. An example is the use of "entity", "entity/device", "device/entity", "entity/client device", "device entity", "entity or submod", "entity (typically a device)". In Section 1.4 you seem to suggest that "entity" is the right term. But throughout the text you mix the terms. The  EAT draft should adopt the terminology established in the architecture doc, which would be "attester" rather than "entity". Section 2 should import the vocabulary from the architecture document **by reference** and establish the aliasing "attester" = "entity" (and maybe = "device") by saying something along these lines: "attester and entity are used interchangeably in this document”.

Agree about most of the above and will work through it.

> 
> - The spec is long and there is a lot of feature creep. This makes it appear very complex. I believe there are two reasons for this, namely (a) there is suddenly a lot of architectural discussion in this document. This is unnecessary given that there is a separate architecture document. There is no need to repeat the content here as well. Do you expect a reader to go through the architecture document before reading this document?

OK. I will work to remove some of this.

A few hints and examples of what to remove would be helpful.  

I already made one pass at removing text from EAT that was covered in RATS architecture.  (EAT -01 actually predates RATS architecture, so there was lots of stuff to remove).


> (b) There are claims in this specification that may sound good but I wonder whether they are ready for prime time already. This document does not need to collect all claims that relate to attestation. Most likely there is not much experience implementing some of these claims either, which reduces the quality of the specification. Sometimes less is just more.

Definitely agree that less can be more.

Top of my list of claims to remove are uptime and boot seed.

The other claims have a strong purpose in my mind. They are necessary to describe the device and the attestation results.

- Maybe the DLOA’s claim could be removed, but I think it is important for RP’s to be able to know about certification status in attestation results.

- The description of SW manifests and measurements is a bit difficult, but I’ve tried make use of the best things out there and be flexible / pluggable since it is a moving target.

- The set of UEID/SUEID, HW OEM ID, HW Class and HW Version is what is necessary to identify HW.

There is similar reasoning for the other claims. 

Which claims would you remove?


> 
> - Unprotected CWT Claims Sets (UCCS): I see UCCS as an architectural aspect. Normally, the implications for the EAT spec should be quite small. The purpose of the EAT spec is to define claims that go into a CWT. EAT does not mandate a specific way to protect the claims (digital signature, MAC, encryption, etc.) then UCCS has not much implication besides a short mention in the security consideration section. Given that UCCS is a separate working group document we would remove Section 4 along with any reference to UJCS.

There’s strong logic here:
— RATS architecture explicitly calls out composite attestation
— A submodule can be a nested EAT to implement composite attestation
— A nested EAT can be a CWT, UCCS  or DEB
— The CDDL that specifies a nested EAT submodule thus must mention UCCS

So a UCCS is a claim that goes into a CWT. I think UCCS, particularly CDDL for UCCS, must be included because of this.


We decided a long time ago that EAT would support JSON in a normative way. The logic continues:
— An EAT can be a JWT
— EAT specifies claims that go into a JWT (and a CWT)
— A submodule can be an  nested EAT
— A submodule can then be a JWT in a CWT or a CWT in a JWT

If we stay with the idea that EAT has normative support for JSON, then I believe the above logic holds and specification of the above is necessary.

I don’t think we realized the implications of EAT formally supporting JSON/JWT in a normative way a few years back. I certainly didn’t. Trying to write and validate the CDDL for both JSON and CBOR, JWT and CWT brought it to light. Maybe it’s too much? What do people think about completely removing normative JSON support from EAT?


Now on to UJCS. The decision on it can be separate from the above logical conclusion, partly because JWT has the (awkward) null algorithm mode.

My main logic about UJCS is:
— JSON is far more popular than CBOR
— If there is reason to specify UCCS, then there is more reason to specify UJCS
— This also lines up with EAT being used for attestation results, which are likely to be JSON.

Maybe UJCS can be removed from EAT, but it seems like it should then exist somewhere else.

There is still a logic and power in bringing all this highly related stuff (CWT, JWT, UCCS and UJCS) together especially when you try to write CDDL for it where individual claims can be JSON or CBOR and individual tokens can be JSON or CBOR. This goes back to composite devices described in RATS architecture.

LL