Re: [Rats] EAT Review Comments

[Hannes Tschofenig <[e-mail]>]

Hi Laurence,

Thanks for your quick response.

A few responses below:

-----Original Message-----
From: Laurence Lundblade <[e-mail]>
Sent: Tuesday, December 7, 2021 10:52 PM
To: Hannes Tschofenig <[e-mail]>
Cc: [e-mail]
Subject: Re: [Rats] EAT Review Comments

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).

[Hannes] I can go through the document again and focus on identifying on what could be simplified.


> (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?

[Hannes] I don't know the history of the DLOA and the SW manifests claim but I wonder whether people will use them in the near future.

>
> - 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.

[Hannes] I wonder whether everything in the RATS architecture should be covered in the EAT specification for several reasons:
- First, the EAT spec becomes complex and harder to read.
- Second, the RATS architecture enumerates everything that came into someone's mind or, as we later learned, can be patented.
- Given the status of the industry with attestation I believe it will take a while to even get the basic functionality deployed. For more complex use cases it can easily take several years.



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?

[Hannes] JSON may be something that is support from the verifier to the relying party because those are probably HTTP-based API. I am wondering whether it would make sense to just have a CBOR-based encoding for the attester-produced EAT tokens. Then, the JSON-based functionality could be published in a companion document, if needed.

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.

[Hannes] IMHO the UCCS functionality should be described in the UCCS draft. I doubt that JSON makes a sense for the community proposing it. I got the impression that this is something from the Smart Card/Secure Elements community and those would hopefully use CBOR rather than JSON.


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.