[Rats] Review of draft-ietf-rats-eat-01

[Carl Wallace <[e-mail]>]

In section 1.2, it seems odd that the definition of the term "entity" is
limited to things that implement this draft. The last sentence of this
section and the definition of "The Entity" in section 1.3 bear this out.
Generally, 'entity' is used pretty loosely throughout the draft.

In section 1.2, why state "the attestation should be cryptographically
verifiable by the EAT consumer"? Is the intent that some EAT consumers
won't recognize the root of trust or that some EATs need not be
cryptographically verifiable at all? If the former, maybe change from
should to MUST and add qualifying words about root of trust for relying
parties. 

Section 1.4.2 claims to not standardize the "end-end process of
establishing signing attestation key material in the entity, signing the
EAT, and verifying it". However, the election of COSE, for example, does
standardize signing and verifying (see section 4.4 of RFC 8152). Also, the
language here needs to reflect expansion to include JWT.

Section 2 feels incomplete without a definition of claim (as in JWT and
CWT, which include similar definitions as here plus claim) and attestation
(given definition of Attestation Key Material). CWT Claims Set should
probably be renamed Claims Set given expansion to include JWT.

In 3.1, suggest re-phrasing "sent to the entity by any protocol" to
something simpler like "provided to entity".

Should 3.11 be 'nested EATs' or 'aggregated EATs'. In other words, are
these really nested (like signed then encrypted or signed then
countersigned) or are they aggregated into an array then signed? Should
these be wrapped as a bstr (at least for CBOR)?

In 4.4.1, suggest table presentation a la COSE spec.

In 4.4.2, are nested EATs allowed to make different encoding choices?

Throughout the draft, should and must are used in many places where SHOULD
or MUST is probably applicable. Examples include:

	- In section 3.1, the should should be SHOULD
	- In section 3.6, the must instances in bullets 3 and 4 could be MUSTs
	- In section 3.11, the must should be MUST
	- In section 4.3.2, the must instances in bullets 3 and 4 should be MUSTs
	- In section 4.4.2, the must in the last sentence of the second paragraph
should be a MUST (and it may be helpful to enumerate 'all' here)
	- Throughout 4.4.2, there are several instances of 'the server must'.
These must instances should probably be MUSTs and 'the server' should
probably the 'the relying party'.
	- In 5.1, the should should be SHOULD

	
The draft should probably include claims related to key attestation (I
think this was mentioned on the list as something that would be added).

Typos
- In the intro change "very small IoT device" to "very small IoT devices"
- In section 3 fix formatting of bullets