[Rats] Re: Foundational document about TEE capabilities

[Markus Rudy <[e-mail]>]

Hi Jeremy,

Thanks for the constructive feedback on list with recommendations for existing TEE standards. With that information, I agree that RATS is not the right place to define such a standard.

Cheers, Markus

P.S.: For some reason, I can’t find your original message in my inbox, so replying to this quoted message instead.

From: Jeremy O'Donoghue <[e-mail]>
Date: Monday, 3. August 2026 at 13:49
To: Ionut Mihalcea <[e-mail]>; Ned Smith IETF <[e-mail]>; Michael Richardson <[e-mail]>; Markus Rudy <[e-mail]>; RATS <[e-mail]>
Cc: nd <[e-mail]>
Subject: RE: [Rats] Re: Foundational document about TEE capabilities



From: Ionut Mihalcea <[e-mail]>
Sent: Monday, August 3, 2026 12:07 PM
To: Jeremy O'Donoghue <[e-mail]>; Ned Smith IETF <[e-mail]>; Michael Richardson <[e-mail]>; Markus Rudy <mr=[e-mail]>; RATS <[e-mail]>
Cc: nd <[e-mail]>
Subject: Re: [Rats] Re: Foundational document about TEE capabilities


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi,

Below with [IM].

From: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Date: Monday, 3 August 2026 at 10:53
To: Ned Smith IETF <[e-mail]<mailto:[e-mail]>>; Michael Richardson <[e-mail]<mailto:[e-mail]>>; Markus Rudy <mr=[e-mail]<mailto:mr=[e-mail]>>; RATS <[e-mail]<mailto:[e-mail]>>
Subject: [Rats] Re: Foundational document about TEE capabilities
<snip>


  *   When we started RATS, the early versions of EAT had a “security level” claim which we eventually removed because while everyone agreed that it would be good to have such a claim, agreeing on what goes into the levels was much, much harder. We eventually settled on the “dloas” claim that lists relevant 3rd party certifications, and I think this is a better route to take than having the IETF attempt to re-invent a process to replace FIPS and Common Criteria.

…and so I’m going to “+1” the “this is not worth doing”.

[IM] What I get from this thread so far is: 1) Doing this work in IETF "at RATS level" is counterproductive;
[Jeremy O'Donoghue wrote]
I would more say that at RATS we went as far as we were able while maintaining broad consensus…

2) Doing some higher-level work in IETF "at SEAT level" might be required. Basically, we need some high level assumptions to rely on when devising RA + other protocol integrations (for example, "Can this key be extracted from the TEE?", as Markus mentioned), that must somehow tie back to RATS-level concepts / primitives.
[Jeremy O'Donoghue wrote]
Possibly. This question seems to fit into the SEAT charter section on “minimum subset of properties that the attested state must convey”, but SEAT should be careful to tie back to RATS in its definition. To use a couple of the examples that were given in the thread:

  *   Is the key that signed this statement known (and knowable) only the TEE?
     *   I’d suggest that “dloas” is the right claim to convery this information as e.g. a Common Criteria (or SESIP, or FitCEM, or OCP SAFE (but not FIPS)) certification covers exactly this type of topic. Yes, this implies a further lookup stage.
  *   Are mitigations present for CVEs?
     *   Not sure that this is a good question for the Attester, regardless of where it is. Attesting Environment sends Evidence and Verifier assesses this Evidence against e.g. CoRIMs which (hopefully) tie to CoSWIDs which eventually gets you to whether any of these SW versions are vulnerable. While it might be nice for attested DTLS to get an answer to this question without the need to go online, CVE environment is too dynamic for this to be a reasonable solution.
  *   Is debug enabled?
     *   We have a claim for that in EAT.

But the concepts themselves will be defined in documents produced by other SDOs. In the future, someone (those SDOs?) will have to link those concepts up to what we define in SEAT. Am I misunderstanding the context?
[Jeremy O'Donoghue wrote]
Maybe. I tend to categorize things in the following way:

  *   <claim> that is re-usable across many ecosystems: standardize in RATS.
  *   <claim> that is specific to some ecosystem but which might be embedded in RATS-defined formats/protocols: define in <other SDO> using IANA registration as needed.
  *   <claim> about how securely <other claim> is protected: rely on <3rd party security certification> referenced via dloas.
  *   How does <other SDO> map into RATS – whitepaper/specification in <other SDO>
  *   How does RATS map into <other SDO> - informational RFC.

Thus there could be a case for an informational RFC on how some specific 3rd party security certifications can be used to determine how securely claims from an attester are protected, but I really don’t think the IETF is the right place to create normative specifications defining security levels since there are already plenty of these - for me it would be an example of xkcd: Standards<https://xkcd.com/927/>.