Re: [Rats] EAT Profiles

[Michael Richardson <[e-mail]>]

Laurence Lundblade <[e-mail]> wrote:
    >> <[e-mail]> wrote:
    >>
    >> 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.

    > CWT has most of this variability and it is a standards track
    > RFC. Should the CWT authors have been more opinionated? Should someone
    > write a follow-on RFC to it that says what CBOR serialization it should
    > use, what key ID scheme to use, ...?

No, but EAT is not CWT.
The lack of strong opinion makes EAT just a rehash of CWT, and that's just
not helpful.  Thomas has pointed me at the new section 6.3, and I'd like to
suggest that you just blow away most of 6.2 and replace it with 6.3.
What really are the arguments for doing anything other what 6.3 suggests?

    > and no one is trying to implement CWT in pure hardware. Possibly there
    > are some issues with algorithm selection. Probably there just isn’t
    > very much deployment, so we haven’t run into much.

I don't think that EAT needs to specify the signing algorithms.
I'm not sure an EAT Profile should either, but some SHOULD+/MUST is probably
a good idea.

    > I’m not trying to be argumentative here. I just want to get to the
    > bottom / heart of the issue.

We are here to make (well-informed) choices, not defer them.

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

    > What I wonder about here is layered or partial profiles.

    > We could write down the CBOR serialization selections and call it a
    > profile, but that doesn’t give 100% end-end interoperability because it
    > doesn’t pick the COSE algorithm, key identification scheme and such.

That's just fine.
We should say how kid is used, but we don't know need to force the algorithm choice.

    > I’m a bit scared of the notion of partial/layered profiles because that
    > adds complexity to EAT, but it doesn’t seem out of the question.

Remove things from the profile, write them down as MUSTs, and then entertain
arguments for why someone might want it to say SHOULD.

    >> EAT is all a la carte, and we are asking for a coordinated, three
    >> course set-menu.  (Please pair the wine with the fish.)

    > Good analogy! :-)

    > The desire for small code size is a really big factor here. Weight
    > watchers are definitely implementing EAT in scenarios where code and
    > memory size are big issue.

    > Not sure we can provide one set menu when some are vegan, some are
    > teetotalers and some have nut allergies, and some really really like
    > cheese steak with a beer.

    > Maybe EAT is the restaurant supply company and the profile authors are
    > the restaurants with the set menu?

I disagree.
CWT is the restaurant supply company.
EAT is a restaurant, and it is offering multiple, set-menus with
some choices in paired wine.  It doesn't have to be a single set-menu, but a
la carte does not help.

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