Re: [Rats] EAT Review Comments

[Hannes Tschofenig <[e-mail]>]

Hi Henk,

> (Hannes, weirdly I believe I did not receive your reply, but I assume it is quoted in the msg below)

I was trying to explain how we have implemented the attestation functionality in our TF-M and TF-A.

> I can accept that we are past that point :-) Please consider this a me lamenting about bad choices in the past that we have to live with today.
> I also see the argument that you can "reuse" CWT code (and then teach it how to treat as an EAT with extra code).

I know what you mean. I keep complaining about the past as well.
I guess it's all good as long as we can get across the finish line in a reasonably good state.

Ciao
Hannes



Viele Grüße,

Henk

On 10.12.21 19:11, Laurence Lundblade wrote:
> Below...
>
>> On Dec 9, 2021, at 11:57 PM, Hannes Tschofenig <[e-mail]> wrote:
>>
>> Hi Henk,
>>
>> You write:
>>
>>> My biggest point of concern is the scope creep into JWT.
>>
>>> EAT was intended to be a CWT (more on that detail below). The
>>> implementation complexity of including JWT now is kind of mind-boggling.
>>> I have been for a while and will continue to be in strong support of
>>> moving JSON encoding related normative text out of the EAT core
>>> doucment to supplemental EAT document.
>>
>>> Fundamentally, I am still opposed to EAT being a CWT. It allows to
>>> include any kind of CWT claims from an increasingly growing CWT
>>> Claims registry. I am allowed to include a nonce and a cnonce Claim
>>> simultaneous due to that. Or simply mix an exi Claim in. How shall
>>> an implementation act on that? That is a valid EAT composition. Is
>>> "ignore what you do not understand" the strategy here? That is not a
>>> really useful approach, if your goal is to establish an
>>> interoperable way to assert trustworthiness. I'd very much prefer a
>>> better scoped usage scenario for EAT for RATS by making an EAT
>>> something more specialized than a CWT (on the CBOR tag level). Maybe
>>> someone can explain to my why this is not an implementer's nightmare
>>> as I might miss something obvious here.
>>
>> We are long past the point of deciding that an EAT is a CWT with special claims. Companies have spend a lot of resources implementing it that way. Practically, there is no problem since you will not randomly add claims to an EAT. As stated in the draft, a profile needs to determine what claims must be present and what to do with optional claims. Then, this is not an issue at all.
>
> Yes, I think we are long past on that decision.
>
> The flexibility is necessary for the broad range of use cases, the ones listed in RATS Architecture and more. I doubt we could converge on one set of claims.
>
> We have profiles to address the problem too many and confusing claims.
>
> LL
>
>
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.