Re: [Rats] EAT Profiles

[Carl Wallace <[e-mail]>]

Inline...

On 9/19/22, 9:24 AM, "Michael Richardson" <[e-mail]> wrote:


    Carl Wallace <[e-mail]> wrote:
        CW> This does not follow from Hannes' statement. Another vendor may use
        CW> some library to produce EATs for their profile and yet another vendor
        CW> may use the same library to produce EATs for a different
        CW> profile. From elsewhere in the threads, I also do not see why a
        CW> cookbook of profiles (i.e., your yellow, brown, red, etc. examples)
        CW> could not be produced referencing EAT as a base specification.

    It could be produced, but it actually would be difficult for many entities to procure.
    Being able to say, in an RFP, "RFCXXXX Yellow Profile" would be perfectly
    acceptable to international trade agreements.   The users of the profiles
    that become RFCs will also be relative easy.  

[CW] This is exactly what is emerging with the TEEP and PSA profiles. There will be RFCs for those. I was noting that someone may write an RFC for some profiles with broad appeal if/when those emerge. There is already one in the EAT spec.

Then the waters get murky when we get
    to other profiles that might only be published by vendors and consortia.
    They don't have standing in trade agreements... some ITU types claim that
    RFCs actually don't count.

[CW] There is nothing to be done about the fact that different use cases will require different claims, specific uses of common claims, etc. That EAT sustains this is a good thing to my eye. That there is a sibling specification for reference values to support verification is also a good thing. There will always be profiles, even if no new claims are defined (for example in a different profiling idiom, certificate profiles may define names, URIs, policy OIDs, etc. but no custom structures).

    Anyway, in every other security area, we have looked at multiplicity of
    options and decide that we don't want every option.  We've gone to either
    crypto suites being explicit, or UI suites where we don't present the user
    with all possible options.

[CW] That this is not the case is part of the issue here. COSE and JOSE are sources of optionality that profiles address. Additionally, EAT is paying some freight for being an early spec that straddles JSON and CBOR. Let's say it didn’t and chose CBOR only then a parallel spec that provided JSON emerged. How would we be any better off?

    I'm just asking for the same thing.


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