Re: [Rats] EAT Profiles

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

I do not see a problem with the EAT profile in the TEEP specification.
I also have no problem with the EAT specification to define a list of items to think about when creating such a profile.
I am fine with having EAT leave options for profiles.

A few minor issues:

* Would it be useful to reference profiles by number (rather than URLs)? Probably so.
* Is it OK that the TEEP profile of EAT does not mandate certain claims? Maybe it should do so, but this would be a topic to discuss in TEEP not in RATS.

Ciao
Hannes

-----Original Message-----
From: RATS <[e-mail]> On Behalf Of Michael Richardson
Sent: Monday, September 12, 2022 11:59 PM
To: [e-mail]
Subject: [Rats] EAT Profiles


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



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.