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

Hi Carl. Thanks for the comments!

My comments below...

> On Jul 15, 2019, at 2:31 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:
> 
> 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.

Please file a GitHub issue here <https://github.com/ietf-rats-wg/eat/issues>. 

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

Please file a GitHub issue here <https://github.com/ietf-rats-wg/eat/issues>. 

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

COSE, EAT and CWT do not mandate support for specific algorithms to the degree the interop is guaranteed. For example an entity could implement ECDSA and the relying party could implement the Edwards Curves. This is the intent of this sentence. 

I believe it is up to profile documents to lock this down for guaranteed interop

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

Since an EAT is just a CWT or JWT now, I was thinking the definition from CWT and JWT just carries over. 

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

OK. 

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

They really are nested. It says:

   The contents of the "eat" claim must be a fully signed, optionally
   encrypted, EAT token.

The nesting is really powerful as it allows multiple subsystems to make EAT tokens (a modern cell phone has lots of CPUs, often well isolated from each other) and for them to be combined and bound to each other.

My thought is that they do not need bstr wrapping. It’s only inputs to hash functions that need that because of the way CBOR decoders work.

If you still think it needs bstr wrapping, please file a GitHub issue.

> 
> In 4.4.1, suggest table presentation a la COSE spec.

That is CDDL. It should not be a table.

But latitude and such should have an “=“. I’ve filed an issue for that. 

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

Yes

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

You must use the word should and should use the word must as many times as possible in a sentence. :-)

I’ve heard different philosophies on this and tended to the more mellow ones that imply. I’ve filed an
Issue to resolve this.

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

Issue filed a long while ago.

> 
> Typos
> - In the intro change "very small IoT device" to "very small IoT devices”

That is from the -00 draft. It is not in the -01 draft. 

> - In section 3 fix formatting of bullets

The CDDL section header was wrong in 3.3. Is that what you meant?

LL

> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> 