[Rats] Response to Eliot's major issues with EAT

[Laurence Lundblade <[e-mail]>]

Here’s PR’s and comments on the major issues from Elot’s IoT review of EAT.  I have made some PR’s for the minor issues, but haven’t listed them here.

Thanks for the comments. They are making the document better.

LL

> Major:
> 
> The most major problem with the document is this:
> 
> 7.  Profiles
> 
>    This EAT specification does not gaurantee that implementations of it
>    will interoperate.  The variability in this specification is
>    necessary to accommodate the widely varying use cases.  An EAT
>    profile narrows the specification for a specific use case.  An ideal
>    EAT profile will guarantee interoperability.
> 
> This is quite counter-cultural to the IETF.  You start with the
> smallest set of functionality and then expand outward to cover
> different use cases that make use of different extensions.  I'm
> not saying that profiles would not be necessary, but that some
> additional thought be given to extension mechanisms.
> 
> This statement in particular is quite disturbing.
> 
>    In some cases CDDL may be created that replaces CDDL in this or other
>    document to express some profile requirements.
> 
> Not only is this counter-cultural, but it would require an Updates:
> header on any such profile, and would further just be plain out
> confusing.
> 
> In short, the profile mechanism is harmful to the very concept of
> interoperability.
The updated text points out the sections in CBOR, COSE and JWT that discuss implementation variation. COSE actually use the term “profile” to name its section.

As I commented previously, I think EAT profiles are a mechanism to explicitly tackle all this stuff all in one place that predated EAT (and is mentioned in various RFCs already).

https://github.com/ietf-rats-wg/eat/pull/215
https://github.com/ietf-rats-wg/eat/pull/216
https://github.com/ietf-rats-wg/eat/pull/210


> 
> Section 4.1:
> 
>    The nonce MUST have 64 bits of entropy as fewer bits are unlikely to
>    be secure.  A maximum nonce size is set to limit the memory required
>    for an implementation.
> 
> There are two sides to this equation: the generator of the nonce and
> the consumer.  How is the generator supposed to know how much memory
> the consumer has?
The memory use of the nonce for the consumer is capped by the specification of a maximum size. That maximum is 74 bytes per nonce which is a relatively small amount that any implementation should be able to afford.

I think it is right to cap the size of the nonce and a few other critical and common claims like UEID, but obviously we can’t cap them all.


> 
> Section 4.2.1:
> 
>    UEIDs are variable length.  All implementations MUST be able to
>    receive UEIDs that are 33 bytes long (1 type byte and 256 bits).  No
>    UEID longer than 33 bytes SHOULD be sent.
> 
> 256/8 = 8.  8+1 = 9.  I don't understand the parenthetical.
Clarifications here <https://github.com/ietf-rats-wg/eat/pull/196>. No more need to do math.


> 
> Between Section 4.2.1 and 4.2.2 there is a particular use case I would
> like to understand:
> 
> If a system integrator resells a bunch of components that have been
> tied together, what guidance is given as to which [S]UEID should be
> exposed and for what purpose?  Does the consumer consume a full array
> of each of these things?  What's the intent?
The main intent here is that this is use case specific and that detailed behavior should be addressed by a profile. There’s no way this document can address all the use cases.

Wording improvement to SUEDs is here: https://github.com/ietf-rats-wg/eat/pull/197/files


> 
> Section 4.2.6:
> 
> Please do not use a free-form text field for the software.  That makes
> comparisons and authorities quite difficult.  In fact between this
> section and section 4.2.7, you may wish to consider using Package
> URLs.
> 
It seems like there a lot of ways of naming SW and no particular one that is as broadly applicable as EAT is so it’s not really possible to create a broad standard here.

So the purpose of this claim is kind of a crude last resort (that I think will be valuable and useful).

Note that this claim is to describe the final SW build/load for a finished device. Package URLs seem more about naming SW libraries that will be used in the build process. That said, I have no objection to a claim for them, but think it should be outside of EAT.

I made some wording improvements:

https://github.com/ietf-rats-wg/eat/pull/217



> Section 4.2.8:
> 
> As a whole this section is a bit too talkative.  Also, there are many
> claims programs, and so I question the value its value.  If it is seen
> as important, then some qualitative statement about specific
> certifications seems more appropriate.
A very controversial claim. See other discussion on RATS list.

It tries very hard to explain why it is not based on certification and that if you want a list of certifications you should use a DLOA. Any suggestions to make it more clear without being more talkative?


> 
> In general the CDDL for uints in particular requires .size values.
> Otherwise you are just asking for random failures based on the limits
> of varying tests.
I went through all int and uint in the CDDL to see where a size could be imposed. 

I added a limit <https://github.com/ietf-rats-wg/eat/pull/201> for CoAP content-format.

Others like bootseed and time stamps shouldn’t have a limit.

The PEN registry doesn’t specify a limit and there is no limit on OID arc integers so I have not put a limit on it, but maybe we should. A limit of 32 bits would certainly be enough.


> 
> 4.2.15  DLOA
> 
>    This claim is typically issued by a Verifier, not an Attester.  When
>    this claim is issued by a Verifier, it MUST be because the entity has
>    received the certification in the DLOA.
> 
> Unclear antedent.  Perhaps you mean:
> 
>    This claim is typically issued by a Verifier, not an Attester.
>    Verifiers MUST NOT issue this claim unless they have received the
>    the certification in the DLOA.
> 
> Same issue with multiple DLOAs.
> 
> Also, is it possible that DLOAs will be produced in JSON at some point
> in the future?  If so, why not allow for that by not mentioning XML,
> and simply requirng observance of HTTP Content-type semantics?
I’ve made fixes here <https://github.com/ietf-rats-wg/eat/pull/200>. 

To allow for JSON DLOAs I’ve removed any mention of XML. However this still relies on the DLOA standard so it would be up to it to specify JSON.


> 
> Section 4.2.16
> 
> Can a software manifest be an SPDX or CycloneDX document or a pointer
> to same?  There's a WHOLE lot of the former out there, and the latter
> is growing in popularity.  If this is the case, let's define
> appropriate types now.
> 
>    If there is no CoAP identifier
>    registered for the manifest format, one should be registered, perhaps
>    in the experimental or first-come-first-served range.
> 
> This sentence seems redundant, and the policy aspects opens this work
> up to the peril of a policy change for the IANA registry.
There’s not any restrictions put on what can be use here, so yes an SPDX or CycloneDX can be used here.

I floated the question of registering it now on the RATS list and no one expressed any interest, so I haven’t done anything to add that to EAT


> 
> Section 9
> 
> The IANA will not know what to do with this section as most of it is
> not directed to them.  Much of it might be better suited as a
> standalone document.  But it does raise the question of whether or not
> some sort of subregistry should be formed for new claims, where an
> appropriate evaluation could be managed through the IANA process (pick
> your favorite).  How that would be accomplished I leave to you.
A lot of the early discussion in RATS was about how to define claims. It was a lot and it seems valuable to me so I wanted to capture and keep it. I’ve moved it into an appendix.

https://github.com/ietf-rats-wg/eat/pull/202