[Rats] EAT Profiles

[Michael Richardson <[e-mail]>]

I read through the EAT profile for TEEP.  Dave posted the link at:

https://www.ietf.org/archive/id/draft-ietf-teep-protocol-10.html#name-eat-profile

let me reproduce some of it:

> profile-label: The profile-label for this specification is the URI
> https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-10. (RFC-editor:
> upon RFC publication, replace string with
> "https://www.rfc-editor.org/info/rfcXXXX" where XXXX is the RFC number of
> this document.)

First, this really feels wrong to use a string here for a constrained object.
My first suggestion is that it be FCFS registry.

Second, the next bunch of items:

> Use of JSON, CBOR, or both: CBOR only.
> CBOR Map and Array Encoding: Only definite length arrays and maps.
> CBOR String Encoding: Only definite-length strings are allowed.
> CBOR Preferred Serialization: Encoders must use preferred serialization,
> and decoders need not accept non-preferred serialization. 
> COSE/JOSE Protection: See Section 8.
> Detached EAT Bundle Support: DEB use is permitted.
> Verification Key Identification: COSE Key ID (kid) is used, where the key
> ID is the hash of a public key (where the public key may be used as a raw
> public key, or in a certificate).
> CBOR Tags: CBOR Tags are not used.

I really don't like the EAT has not made a clear judgement on these things
already.   I'd really really like EAT to be far more opinionated.

The above list looks like it will be 95% of CBOR-based EAT "profiles"
Could EAT just write this down, and give it a name?
That way, we can well tested libraries that do the right thing here.
I think that really this is where Eliot is coming from.
EAT is all a la carte, and we are asking for a coordinated, three course set-menu.
(Please pair the wine with the fish.)

> Endorsement Identification: Optional, but semantics are the same as in
> Verification Key Identification.

I guess I have to read more about what this means, as told me nothing :-)

> Freshness: See Section 9.

It's totally reasonable that TEEP would have some specific freshness requirements.

> Required Claims: None.
> Prohibited Claims: None.
> Additional Claims: Optional claims are those listed in Section 4.3.1.

This totally surprises me.  Are you saying that it's okay for TEEP evidence
to have *NO CLAIMS*?   Surely that can't be right.    If there was anything I
expected to see in a profile it would be a list of required claims.

> Refined Claim Definition: None.

This is part of what worries me.  There should never be any semantics changes
between profiles for claims.

> Manifests and Software Evidence Claims: The sw-name claim for a Trusted
> Component holds the URI of the SUIT manifest for that component.

okay, this is actually important.



-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-