Re: [Rats] EAT Profiles

[Thomas Fossati <[e-mail]>]

> Thomas Fossati <[e-mail]> wrote:
>     > 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.
>
> Hi, Looking at section 4.5.
> I'm surprised at how little you write compared to TEEP (that's good, I
> think) You are just declaring the profile claim value.
> Again, I really think a URL is wrong in a constrained environment.

One could use OID (~10 bytes on average) or maybe spare a few bytes
using a CRI [1].

(For the record, I am not against a constrained profile id using
something like "uint .size 2" as type.  It does not overlap with an
absolute OID or URI so it's OK to allow it as a choice alongside the
other two.)

[1] https://datatracker.ietf.org/doc/html/draft-ietf-core-href

>     >> 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.
>
> I think that's a wrong optimization.
> A FCFS Registry is an email to IANA, and take as little as one
> business day if time zones line up for you.
> An OID could be much bigger than a 2-byte CBOR integer.
>
>     >> 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.
>
> Ah, this seems new to me.
> Why didn't TEEP use it?  It looks identical to me.
> Are each of these SHOULDs, or MUSTs?
> If they are SHOULDs, then what are the exceptional case?

They are all MUSTs in the context of the "Constrained Device Standard
Profile".

We use something quite similar - modulo DEB / BUNDLE usage (which we do
not support altogether), and COSE Mac0 (which we allow as an alternative
to Sign1).  And, obviously, the Claims part which for us is strictly
limited to the PSA claims set.

>     >> > 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.
>
> Maybe it's old.

Or maybe it’s a typo for "required claims definition"

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.