Subject: [Rats] Recommendations for the EAT draft

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 May 2019 17:17:43 +0200

Hello EAT authors,
hello list,

to get a better opinion about the state of the EAT I-D, I reviewed the 
draft more carefully.

On the one hand and most importantly, I think the claim sets defined are 
a valuable contribution to standardized remote attestation 
claims/assertions and this alone is reason enough to adopt the I-D (even 
though the scope of some these seems to be a very generic catch-all, but 
that can be fixed later).

On the other hand, I would like to give the authors a chance to tell us 
what they intended to do here.

In any case, my recommendations to the authors are to:

* remove the definition of FloatOrNumber, as that is a weirdly redundant 
mix of types. Number encompasses all of them. Essentially, Float is a 
specialization of Number, as is Negative Integer or Integer,

* remove the definition of NumericDate as CWT already defines that (or 
only reference the source text in RFC 8392 via rephrasing),

* distinguishing verifiable claims from state assertions (or 
not-verifiable claims),

* highlight explicitly that the CWT Claim Set can be used in EAT (or 
even better that EAT defines new claims for CWT and therefore creates 
the specialized CWT that is an EAT),

* replace the text "EAT is a one-way protocol. It only defines a single 
message that goes from the entity to the server." at the beginning of 
section 4 and replace it with "EAT is intended to be used in one-way 
protocol messages conveyed from entities to services." as it was stated 
multiple times that EAT defines Claim Sets and how to nest them - and 
not a protocol (in general I'd substitute server with services, but that 
is not a high priority),

* strongly consider to not use EAT as protocol messages without defining 
at least a reference protocol that shows the usefulness of all 
not-verifiable claims, e.g. nonce,

* highlight why it is useful that a submods claim is an array of "CBOR 
maps, which may or not may be EAT, instead of simply define it as an 
array of EAT,

* finish the sentence in 4.7, and

* do not register a separate CBOR tag for EAT next to the CWT CBOR tag, 
but make EAT a CWT.

Viele Grüße,

Henk