Re: [Rats] EAT Review Comments

[Jeremy O'Donoghue <[e-mail]>]

Hi list,

My thoughts below

Best regards
Jeremy

On 10/12/2021, 07:45, "RATS" <[e-mail]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Hannes & Laurence,
hi list,

a few essential comments in-line.


Viele Grüße,

Henk

On 09.12.21 11:45, Hannes Tschofenig wrote:
> 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.

As long as additional normative statements are in support of
deterministic and interoperable evidence generation and appraisal I am
all for that. I would like to carefully highlight that phrasing such
statements is a delicate procedure will cost additional time to get
aligned as WG consensus. In general, I see the necessity and in favor of
reviewing proposal for these.

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

Yes. Self-descriptive CDDL + English text for human readers outside the
CDDL elaborating on type semantics is the right direction.

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

It would be nice to have a review'able track of issues for each type of
inconsistency here. But speaking from experience that is the way how
Laurence works on the document for quite some while now (kudos), so I am
not worried by that, actually, still I felt the need to highlight that.

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

Thanks Hannes. I'll review your input and cross-check the proposals.

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

Personally, I was under the impression that the content of -08 was
already good enough.

My biggest point of concern is the scope creep into JWT.

EAT was intended to be a CWT (more on that detail below). The
implementation complexity of including JWT now is kind of mind-boggling.
I have been for a while and will continue to be in strong support of
moving JSON encoding related normative text out of the EAT core doucment
to supplemental EAT document.

Fundamentally, I am still opposed to EAT being a CWT. It allows to
include any kind of CWT claims from an increasingly growing CWT Claims
registry. I am allowed to include a nonce and a cnonce Claim
simultaneous due to that. Or simply mix an exi Claim in. How shall an
implementation act on that? That is a valid EAT composition. Is "ignore
what you do not understand" the strategy here? That is not a really
useful approach, if your goal is to establish an interoperable way to
assert trustworthiness. I'd very much prefer a better scoped usage
scenario for EAT for RATS by making an EAT something more specialized
than a CWT (on the CBOR tag level). Maybe someone can explain to my why
this is not an implementer's nightmare as I might miss something obvious
here.

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

[JOD] -1 on removing DLOA claim – it would otherwise go into a GlobalPlatform profile anyway, but I see the applicability as being much broader than the GlobalPlatform ecosystem – it allows a claim about a 3rd party security certification (e.g. PSA Certified / SESIP L3) which can be hosted on any webserver.

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

As rule of a thumb, I'd simple prune anything that was added after -08.
Maybe we should go from that demarcation line, enumerate the Claim names
of everything that was added after and then see, if there are candidates
in that list that the WG is interested in keeping.

I am not saying to abandon the "pruned" Claims, but to put them into the
next document. All implementation that I know of are based on -08. I
don't want to sound over-confident here... maybe it's -09 effectively...
my point is: divide an conquer.

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

Yes. This. I am in strong support (+1) of moving UCCS implications
solely into the Security Consideration Section.

[JOD] There are arguments both ways, but I could live with this. It does mean we (UCCS editors) should accelerate progress towards publication of the UCCS draft.


>
>
> We decided a long time ago that EAT would support JSON in a normative way. The logic continues:

I am not so sure how the group consensus really looks like here. Maybe
this calls for a dedicated question to the list. Again, I am not talking
about abandoning the whole JSON nested in CBOR nested in JSON idea. I
just think as part of the EAT core document it is adding an
insurmountable amount of complexity that could severely hamper adoption
in the end.

[JOD] My view is that there are two distinct use-cases here:


  *   Attester conveying attestation evidence to a Verifier (likely to be CBOR in most cases)
  *   Verifier conveying results to a Relying Party (likely to be JSON in most cases)

I am not fully convinced that the complexity of allowing an EAT to be almost any arbitrary composition of JSON and CBOR components is really necessary, and maybe it is reasonable to require that an EAT is composed of either CBOR or JSON components. Doing otherwise has potential to make all components in the chain (Attester, Verifier, RP) quite complex, and I’m generally keen on simplicity.

However I do think the need for support of JSON by EAT is widely supported by the group

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

+1 for companion document, +1 for if needed.

[JOD] I would rather see document reach consensus and get published sooner – if removing JSON support helps this goal, and I think it does, I’m +1.


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

+1

[JOD] There is a clear use-case for UCCS in the GlobalPlatform/Smartcard world. If it is not in the IETF document, GlobalPlatform would define it in a profile. We brought it to IETF because it seemed like there might be use-cases beyond GlobalPlatform.

+1 on JSON community can create UJCS , (+1) if required, when work on JSON EAT gets started.


>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>

_______________________________________________
RATS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rats