Consider using TCG Concise Evidence Binding, like the OCP Profile for EAT

[dkumar-nv]

Summary

This draft introduces a new measured-component format to fill the gap that the measurements claim in EAT (RFC 9711) supports only CoSWID. While the motivation is valid, a well-established format already exists that addresses this need: TCG DICE Concise Evidence Binding for SPDM v1.1 (concise-evidence), as seen in OCP Profile for IETF EAT

Background

The TCG DICE Concise Evidence Binding for SPDM (v1.1) defines a concise-evidence schema that:

1. Is not limited to filesystem-anchored measurements (it handles early boot, firmware, runtime integrity, SPDM measurement blocks, and more).
2. Is compatible with the CoRIM schema and designed for IETF RATS-style appraisal workflows.

The OCP Profile for IETF EAT demonstrates that TCG concise-evidence can be carried directly as a measurements-format value within an EAT token — making it applicable beyond SPDM, as a general-purpose format for measurements claim within EAT.

Concern

1. Introducing a new mechanism creates:
   A. Fragmentation: Attesters working across OCP/TCG as well as RATS ecosystems may face pressure to support two distinct measurement encoding formats within EAT.
   B. Interoperability risk: Verifiers appraising EAT tokens would need to handle both formats, increasing complexity and the attack surface of the appraisal logic.
2. concise-evidence enables straightforward comparison with CoRIM by making the structure of measurements claim in evidence same as the structure of CoRIM. But with draft-ietf-rats-eat-measured-component, the comparison to CoRIM is not straightforward.

Request

I request that the authors and WG consider the following:

1. Acknowledge the existence and applicability of TCG concise-evidence as an existing measurements-format for EAT, as demonstrated by the OCP Profile for IETF EAT. It would be great to see draft-ietf-rats-eat-measured-component mention the existing work in its gap analysis.
2. Evaluate whether the information model is meaningfully distinct from the semantics already encoded in concise-evidence (component name, version, digest, algorithm, authority — these are all present in TCG concise-evidence).
3. Coordinate with TCG DICE WG and OCP Security WG to avoid multiple standards for measurements claim.
4. Consider friendliness with CoRIM with draft-ietf-rats-eat-measured-component to keep verifier implementation straightforward.

References

• TCG DICE Concise Evidence Binding for SPDM v1.1
• OCP Profile for IETF EAT
• RFC 9711, Section 4.2.16 – Measurements claim

[ionut-arm]

Hi!

Thank you for the feedback, however the draft is currently in the IETF editor queue, so we're past the point of making functional changes to the document. More than that, it's worth pointing out that, as an extension of EAT, the Measured Component draft came before any attempt to plug the Concise Evidence structure in EAT [0]. (Note that the emails in [0] do not reflect the exact timeframing for the IANA interaction, which would've started maybe a month earlier.) IIUC EAT MC was a trigger towards defining the EAT CE claim in the first place. It does seem like there was a missed opportunity here to flag a potential conflict, as IETF RATS members were also heavily involved in the TCG effort towards DICE CE. The only potential overlap with TCG that we were aware of didn't go anywhere [1].

Nonetheless, I wanted to address some of your concerns.

• Fragmentation and interoperability: I agree that there's a minor risk here, but we'd expect some level of translation to happen to all EAT claims anyway, before any processing is done. And the extensibility points for EAT were defined exactly for handling a variety of formats. More than that, some of the semantics of MC do not map neatly onto CE contents. Authorities, for example, mean something different. In CE it's used as a way to convey who is allowed to provide reference values / endorsements for some measurement, while in MC it is used to denote who authorized the thing that was measured to be used on the attester (e.g., a device owner allowing a binary to be executed via some on-device policy).

• Compatibility with CoRIM: The solution here should be fairly simple and inexpensive for a verifier - define and implement an evidence transformation that specifies how to convert an MC to a CoRIM [2].

[0] https://mailarchive.ietf.org/arch/msg/media-types/xq4qnV32WV1ABcXVxXXaIX7r02Q/
[1] https://mailarchive.ietf.org/arch/msg/rats/pdKk9IlqnyjF0scP9QtP391qlOs/
[2] ietf-rats-wg/draft-ietf-rats-evidence-trans#25