Re: [Rats] EAT Profiles

[Thomas Fossati <[e-mail]>]

Hi Michael,

Thanks.  This sounds like a useful exercise.  Could you please have a
look at the PSA draft from this angle too?  We have tried hard to make
the document a blueprint of a EAT profile definition that others could
follow. It'd be good to have confirmation that we are on the right
track.

On 14/09/2022, 16:06, "RATS" <[e-mail]> wrote:
> 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.

This is a choice TEEP made (and, BTW, PSA too [1])
For a more compact representation one could use a RFC9090 OID instead,
there is no need for a registry.  In fact, choosing URI / OID as the
underlying type was a conscious choice to avoid IANA round-tripping.

[1] https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-10.html#section-4.5.2

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

I think that's what the "The Constrained Device Standard Profile" [2] is
intended for?  One should use it as baseline, make a few custom
choices, define the claims set, and give it a new name.

[2] https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-6.3

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

Agree, this is quite surprising.  In contrast, a good chunk of the PSA
document (all of Section 4 [3]) deals with the definition of the claims
set.

[3] https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-10.html#name-psa-claims

> > Refined Claim Definition: None.
>
> This is part of what worries me.  There should never be any semantics
> changes between profiles for claims.

I don't know what is meant by "Refined Claim Definition".  It doesn't
look like something required by EAT.

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

cheers, t

--

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.