]> Microsoft

xiling.sun@microsoft.com

NVIDIA

raghupathyk@nvidia.com

Microsoft

roksanag@microsoft.com

Security Remote ATtestation ProcedureS attestation EAT CoRIM SPDM composite device platform attestation This document defines an Entity Attestation Token (EAT) profile for composite platform attestation. A Lead Attester, such as a platform Root of Trust, produces a single signed composite EAT that carries its own measurements and cryptographic digests committing to detached, native evidence collected from peripheral sub-attesters. The full sub-attester evidence -- Security Protocol and Data Model (SPDM) signed measurements, device-emitted EATs, or SPDM-carried TCG DICE Concise Evidence -- is conveyed verbatim as detached Claims-Sets in a Detached EAT Bundle. This yields a single, freshness-bound, platform-scoped attestation artifact that a Verifier can appraise against platform-composition endorsements, even when the evidence is collected and conveyed by an untrusted mediator. About This Document Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

Problem Statement Platform attestation today is disaggregated. Where per-device evidence is retrievable (for example, over a Redfish-based interface), attesting a whole server takes N separate transactions returning N independently signed responses, and the Verifier must reconstruct platform topology from those separate per-device results. There is no signed, platform-level artifact that binds a single Verifier nonce, the platform Root of Trust (RoT) state, and the set of device evidence reported for the platform. Three gaps follow:

1. No aggregate. There is no single signed platform-scoped artifact; the Verifier reassembles the platform from independent per-device results.
2. No uniform claim. Devices variously expose SPDM signed measurements, emit their own signed EAT, or carry TCG DICE Concise Evidence inside SPDM measurements. No common platform structure carries these forms together without rewriting device evidence.
3. Heavier RoT firmware footprint. Attesting the platform RoT under the same per-device model would force a full SPDM responder path onto the RoT solely to attest itself.

Approach A Lead Attester ( composite device pattern) produces one signed composite EAT. The composite EAT carries the Lead Attester's own measurements and, for each peripheral sub-attester, a detached-submodule digest that commits to the sub-attester's evidence. The evidence itself is preserved in its native encoding and conveyed separately as a detached Claims-Set within a Detached EAT Bundle (CBOR tag 602, ). The signed digests bind the detached evidence; the native bytes preserve each device's own end-to-end signature.

Relationship to Other RATS Work defines an EAT profile for per-device attestation evidence in confidential-computing device assignment, and notes that such a device token is "typically enclosed in a wider platform specific attestation token." This document defines that enclosing, signed, self-attesting composite envelope for the platform/operator use case. A device token of that form MAY be carried as one detached sub-attester payload (); the two profiles address different consumers and are complementary.

Scope This document specifies the composite EAT evidence format: the signed composite token, the detached sub-attester evidence carriage, and the binding between them. Appraisal of the composite against a platform composition endorsement (for example, a platform CoRIM profile) is summarized informatively in and specified separately. Tenant-side attestation and TDISP composition are outside the scope of this document. Physical slot locality and bus-level anti-relay guarantees are also outside scope; this profile supports identity-based anti-substitution. Trust-anchor enrollment, endorsement authoring, and transport/collection APIs are also outside scope.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Data structures are defined using the Concise Data Definition Language (CDDL) . This document uses the terms Attester, Verifier, Relying Party, Endorser, Reference Value Provider, Lead Attester, Sub-Attester, Composite Device, Target Environment, and Attesting Environment as defined in . Additional terms:

Detached Claims-Set:

The native sub-attester evidence for one Target Environment, encoded as a CBOR Claims-Set and conveyed in the detached slot of the Detached EAT Bundle, committed to by a digest in the signed composite EAT.

Target Environment Identifier:

A stable, operator-owned topology label (rendered as an env.* string) used as the map key for a sub-attester in both the signed submods claim and the detached Claims-Set map.

Untrusted Collector:

The entity that discovers sub-attesters, collects evidence, and assembles the bundle. It is not trusted for content: it MAY drop, reorder, or mislabel evidence, but MUST NOT be able to forge it.

Architecture and Trust Model

Composite Device Realization This profile realizes the composite device pattern. The Lead Attester signs the composite EAT and contributes its own Attesting-Environment identity and measurements. Peripheral devices are Sub-Attesters whose evidence appears only as detached-submodule digests in the signed token, with the full evidence detached. The Lead Attester does not appear as a submodule; its claims are top-level claims of the composite EAT. This profile does not replace native Sub-Attester verification. A Verifier MUST validate each Sub-Attester signature or other native evidence protection in addition to validating the composite EAT signature.

Untrusted Collector and Conveyance The entity that collects sub-attester evidence and assembles the bundle is untrusted for content. Its labels and completeness are not proven by the composite signature; they are appraisal inputs. The design goal is that a misbehaving collector can cause detectable failures (missing or mismatched digests, failed device signatures) but cannot forge evidence or the composite signature. See .

Role Mapping RATS role mapping

Component	RFC 9334 role
Lead Attester (e.g. platform RoT)	Lead Attester
Peripheral device	Sub-Attester
Collector / conveyance	Evidence collection / conveyance
Endorser / RVP	Endorser / Reference Value Provider
Verifier	Verifier
Consumer of the Attestation Result	Relying Party

The Signed Composite EAT

Profile Conformance This section states the profile items for this profile. Profile conformance

Profile item	This profile
Profile identifier (eat_profile, claim 265)	https://datatracker.ietf.org/doc/draft-sun-rats-composite-eat/
Serialization	CBOR with deterministic encoding and definite-length items
Top-level message	Detached EAT Bundle with tag 602
Top-level media type	application/eat-bun+cbor
Main token	CWT tag 61 containing COSE_Sign1 tag 18
Token protection	COSE_Sign1 using ES384 (algorithm -35)
Detached digest	SHA-384 (algorithm -43), 48-byte output
Key identification	Protected SHA-384 x5t (label 34) and unprotected leaf-first x5chain (label 33)
Freshness	One 32-byte eat_nonce, unique for each request
Main token content type	application/eat+cwt

Conforming producers MUST emit every choice in the table above. Conforming Verifiers MUST support those choices. This is a full EAT profile in the sense of .

Bundle Structure The authoritative artifact is a Detached EAT Bundle (CBOR tag 602, ). This profile does not redefine the tag-602 construct; it constrains its two slots: slot 1 is the signed composite EAT (main-token); slot 2 is the detached Claims-Set map keyed by Target Environment Identifier and defined in . When conveyed with a media type, the bundle MUST use application/eat-bun+cbor . bstr .cbor detached-claims-set } ]) composite-eat = #6.61(#6.18([ ; COSE_Sign1-tagged CWT protected: bstr .cbor protected-headers, unprotected: unprotected-headers, payload: bstr .cbor composite-eat-claims, signature: bstr ])) protected-headers = { 1: -35, ; alg: ES384 3: "application/eat+cwt", ; content_type 34: certificate-thumbprint ; x5t: SHA-384 of leaf certificate } certificate-thumbprint = [ -43, bstr .size 48 ] unprotected-headers = { 33: cose-x509-chain ; x5chain: leaf certificate first } cose-x509-chain = bstr / [ 2* bstr ] ]]> Every certificate in cose-x509-chain is a DER-encoded certificate. When the chain contains more than one certificate, it MUST be ordered starting with the Lead Attester end-entity certificate, as specified by . The protected x5t MUST use SHA-384 (algorithm -43) and MUST equal the SHA-384 digest of the complete DER encoding of that end-entity certificate. This integrity-protects the end-entity certificate while allowing x5chain to be carried in the unprotected header bucket, as permitted by . A Verifier MUST reject the token if the protected x5t does not match the first certificate in x5chain. It MUST treat every carried certificate as untrusted input and validate a path to a trust anchor configured independently of the bundle, including applicable certificate usage, validity, and revocation checks .

Top-Level Claims general-uri, ; OPTIONAL locator hint } ]]> The eat_nonce claim contains exactly one nonce. The Verifier MUST generate a new nonce for every request, and the same nonce MUST be used to obtain each nonce-capable Sub-Attester evidence item included in the resulting bundle. The TBD_PLATFORM_CORIM_ID claim is a Verifier lookup/audit hint only and is not appraisal authority; see .

Lead Attester Self-Measurements The Lead Attester's platform-local evidence (RoT and platform firmware) is carried in the top-level measurements claim (273), not in submods. This constrains the measurements claim format defined by ; it does not define a map-based replacement for that claim. The Lead Attester MUST use a registered CoAP Content-Format for each value.

Detached Sub-Attester Evidence

Detached-Submodule-Digest Binding Every Sub-Attester is represented in the signed token as a Detached-Submodule-Digest (). The full evidence is the detached Claims-Set in slot 2 of , keyed by the same Target Environment Identifier. detached-submodule-digest } detached-submodule-digest = [ hash-alg: -43, ; SHA-384 in the COSE Algorithms registry digest: bstr .size 48 ; over encoded detached Claims-Set bytes ] env-id = tstr ]]> Binding invariant: for every Target Environment Identifier E, submods[E] in the signed token MUST equal the digest, computed per , of detached-claims-sets[E] in the bundle. The key set of submods MUST be identical to the key set of detached-claims-sets. A Verifier MUST reject a bundle containing a missing or unreferenced detached Claims-Set. Using detached digests for every Sub-Attester keeps the signed composite token and the Lead Attester input bounded by Sub-Attester count rather than by native evidence size. It also allows additional native evidence formats without changing the submods shape.

Deterministic Encoding and Digest Rules Each detached Claims-Set MUST be encoded with deterministic CBOR (). The detached-submodule digest MUST be computed over the encoded Claims-Set bytes directly, not over the byte-string wrapper used in the bundle and not over any textual encoding. This rule is the anti-forgery anchor: a modified or fabricated detached Claims-Set fails either the signed digest comparison or the device evidence signature check. SHA-384 (COSE algorithm -43) MUST be used for every detached-submodule digest. This digest algorithm is independent of any measurement hash algorithm negotiated by a native evidence protocol such as SPDM.

Native Evidence Carriage Sub-attester evidence is preserved in its native encoding as the value of one profile-defined CWT claim. Using one integer claim key satisfies the CBOR claim key requirements of while allowing the profile to carry several native evidence formats. native-evidence } native-evidence = spdm-evidence / device-eat-evidence ]]> The Collector constructs the enclosing Claims-Set and evidence-type array. It MUST NOT alter, translate, or re-author the native evidence bytes placed in that array.

SPDM Signed Measurements signed-measurements is the binary Redfish/SPDM SignedMeasurements value. For SPDM 1.2 and later it includes the negotiated-version, capabilities, and algorithms (VCA) transcript; for SPDM 1.0 and 1.1 it contains only the signed GET_MEASUREMENTS exchange. cert-chain is the raw reassembled SPDM certificate-chain object, not a PEM encoding or management-interface projection. vca is the observed VCA transcript and MUST be present for SPDM 1.0 and 1.1; it MUST be absent for SPDM 1.2 and later. See .

Device-Emitted EAT device-token MUST contain the complete token as emitted by the device, and token-format MUST identify its media type. The token MUST cryptographically bind the Verifier nonce. A device token of the form defined in MAY be carried here.

SPDM-Carried TCG DICE Concise Evidence Signed measurements that carry TCG DICE Concise Evidence use the spdm-evidence schema above; the measurement blocks are preserved verbatim. The Collector does not need to distinguish ordinary SPDM measurements from SPDM measurements carrying TCG DICE Concise Evidence. The Verifier interprets the signed measurement blocks according to the applicable evidence profile.

Relationship to Conceptual Message Wrappers This profile does not permit Conceptual Message Wrapper (CMW) typed values inside TBD_NATIVE_EVIDENCE; allowing an alternate inner representation would make the digest input ambiguous. A conveying protocol MAY carry the complete composite-bundle as a CMW typed value . Such an outer wrapper is not part of any detached Claims-Set digest input.

Target Environment Identifier The submods key and detached Claims-Set map key is a stable, operator-owned Target Environment Identifier, distinct from SPDM slot IDs, MCTP EIDs, device UUIDs, and CoRIM IDs. It:

1. is lowercase ASCII;
2. is dot-separated with first component env;
3. names the expected environment, not the device instance;
4. is at most 64 bytes.

Examples: env.nic.0, env.gpu.0, env.pcie.4.

Verification (Informative) A Verifier is expected to perform the following checks before producing an attestation result:

1. Decode the bundle, confirm tag 602, and enforce the encoding and algorithm choices in .
2. Match protected x5t to the end-entity certificate in x5chain, validate the Lead Attester certificate path, and validate the COSE_Sign1 signature.
3. Match eat_nonce to the challenge, match eat_profile to this profile, and validate the Lead Attester ueid and measurements.
4. Require identical submods and detached Claims-Set key sets, then recompute every digest per .
5. Parse each TBD_NATIVE_EVIDENCE value, validate its native signature and certificate or token chain, and match its nonce to the challenge.
6. Match the identity proven by each native evidence item to the expected identity for its Target Environment Identifier.

Completeness and anti-substitution are appraisal outcomes, not properties of the composite signature alone. They are determined by comparing the signed submods set and proven device identities against a platform composition endorsement (for example, a platform CoRIM profile; see ), which is specified separately. Native Sub-Attester measurements are appraised against trusted device reference values, such as vendor CoRIMs, selected by Verifier policy. This profile does not define endorsement selection or reference-value appraisal.

Security Considerations The security considerations of , , , , and apply.

Untrusted Collector Threat Model The Collector may drop, reorder, or mislabel evidence. A dropped device yields no valid submodule digest; exact key-set checking detects a detached Claims-Set omitted from the bundle, while appraisal against a platform composition endorsement detects an expected environment omitted from both maps. Reordering has no semantic effect because both collections are maps and their deterministic encodings are checked by digest. A mislabeled environment is detected when the identity proven by native evidence does not match the expected identity for that Target Environment. If appraisal policy has no trusted identity-to-environment binding, this profile alone cannot detect such substitution. The Collector cannot forge the composite signature or a Sub-Attester's native signature. It can, however, choose the label and digest records submitted to the Lead Attester. Consequently, the composite signature proves integrity and freshness of the included set; it does not prove that collection was complete or that a label was assigned correctly. The profile binds a proven Sub-Attester identity to a logical Target Environment Identifier. It does not prove physical connector locality or prevent bus-level relay. Deployments requiring those properties need an additional platform-specific transport or hardware binding.

Provenance Preservation Because sub-attester evidence is carried verbatim and pinned by a signed digest, device signatures remain end-to-end verifiable through an untrusted Collector. A Verifier MUST validate both layers: accepting the composite signature without validating native evidence would incorrectly treat Collector-authored bytes as device-authored evidence. The top-level nonce prevents replay of the composite EAT. Each native evidence item MUST independently prove binding to the same nonce; otherwise a Collector could combine current platform evidence with stale device evidence. A Verifier MUST reject a native evidence item whose nonce is absent, unverifiable, or does not match the challenge. The fixed ES384 and SHA-384 choices prevent algorithm substitution at the composite layer. For SPDM 1.0 and 1.1, the separately carried VCA transcript is not covered by the responder's measurement signature. Deployments requiring cryptographic binding of negotiated SPDM parameters MUST require SPDM 1.2 or later in appraisal policy.

Aggregator Self-Attestation and Key Handling The Lead Attester signs with a protected attestation key and contributes its own measurements. The signing key and the source of ueid and top-level measurements MUST be protected from the Collector. The ueid MUST be provisioned according to and remain stable for the Lead Attester. Compromise of the Lead Attester signing key permits forgery of the composite envelope, its nonce, Lead Attester measurements, labels, and device-evidence digests. It does not permit forgery of uncompromised Sub-Attester signatures, but it defeats the platform-scoped binding supplied by this profile. Verifiers therefore MUST validate the Lead Attester certificate path, revocation state, and applicable authorization policy rather than trusting a chain merely because it is carried in x5chain. They MUST also match the protected x5t to the end-entity certificate before accepting the Lead Attester signature. If x5chain were accepted without the protected x5t check, an attacker could substitute another certificate for the same public key and cause an identity misbinding when the issuing CA did not require proof of possession. The protected x5t prevents this attack by signing the exact end-entity certificate identity .

Resource Exhaustion Detached evidence, certificate chains, and the number of submodules are attacker-influenced inputs. Implementations SHOULD enforce deployment-specific limits on bundle size, Claims-Set size, certificate-chain length, and submodule count. Verifiers SHOULD validate structure and signed digests before performing expensive native-evidence appraisal, without treating a valid digest as a substitute for native signature validation.

Privacy Considerations A stable Lead Attester ueid and end-entity certificate enable correlation of attestations from the same platform. Native device certificates and device-emitted tokens can similarly identify and correlate individual Sub-Attesters. Target Environment Identifiers expose platform topology, and measurements can reveal firmware versions or configuration. Deployments SHOULD restrict bundle access to authorized Verifiers and use a confidentiality-protected conveying protocol when these identifiers or measurements are sensitive. A Verifier SHOULD disclose only the attestation result needed by a Relying Party rather than forwarding the complete bundle. Verifier nonces SHOULD be unpredictable random values and MUST NOT encode user, account, workload, or other identifying information. Where stable platform identification is unnecessary, deployments should use a context-specific identity mechanism in a separate profile; replacing ueid ad hoc would not conform to this profile.

IANA Considerations

Native Evidence CWT Claim IANA is requested to register the following in the "CBOR Web Token (CWT) Claims" registry:

• Claim Name: Native Evidence
• Claim Description: Native evidence carried in a detached Claims-Set
• JWT Claim Name: N/A
• Claim Key: TBD (TBD_NATIVE_EVIDENCE)
• Claim Value Type: array
• Change Controller: IETF
• Reference: of this document

Platform CoRIM Locator CWT Claim IANA is requested to register the following in the "CBOR Web Token (CWT) Claims" registry:

• Claim Name: Platform CoRIM Locator
• Claim Description: Locator hint for a platform CoRIM
• JWT Claim Name: N/A
• Claim Key: TBD (TBD_PLATFORM_CORIM_ID)
• Claim Value Type: URI
• Change Controller: IETF
• Reference: of this document

EAT Profile Identifier This document defines the provisional eat_profile value https://datatracker.ietf.org/doc/draft-sun-rats-composite-eat/. This value identifies the complete profile defined by this Internet-Draft. It is expected to be replaced by an RFC-based identifier if this document is published as an RFC; implementations of an Internet-Draft version therefore MUST treat this value as provisional.

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EATs). In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. DMTF In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Linaro Fraunhofer SIT Linaro In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust an assigned device, the device must provide the TVM with attestation Evidence confirming its identity, the state of its firmware and configuration. Since Evidence claims can be processed by 3rd party entities (e.g., Verifiers, Relying Parties) external to the TVM, there is a need to standardize the representation of DA-related information in Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. Trusted Computing Group

Worked Example This non-normative example uses temporary claim keys 60000 and 60001 from . The Verifier nonce is the 32-byte sequence 0x00 through 0x1f. The Lead Attester and device token use separate P-384 signing keys and self-signed example certificates. These certificates are test inputs, not trust anchors for deployment. For compactness, the SPDM byte strings are illustrative carriage values rather than a complete SPDM transcript and certificate chain. The following diagnostic notation elides long certificates, signatures, and nested token bytes. The complete encoded bundle follows it. >, {33: h''}, <<{ 10: h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f', 256: h'0111111111111111111111111111111111', 265: "https://datatracker.ietf.org/doc/draft-sun-rats-composite-eat/", 266: { "env.accel.0": [-43, h'a24620821bdc8c9aec86dae14bbce0a627c13fe41cefe58eb20cd748eb56154391368d509d001f70e1c6cfe2815c388c'], "env.nic.0": [-43, h'3032f9a41a6156dc45e054276a775bebade2a795c2412b91319326c6a299af6c2ceba175fc8fa4c51eb7721939760cf1'] }, 273: [[60, h'a1015830aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa']], 60001: "tag:example.com,2026:platform-corim:v1" }>>, h'' ]))>>, { "env.accel.0": <<{ 60000: [2, "application/eat+cwt", h''] }>>, "env.nic.0": <<{ 60000: [1, h'12010000aabbccdd', h'30820100deadbeef'] }>> } ]) ]]> The SHA-384 digest of the encoded env.nic.0 Claims-Set is 3032f9a41a6156dc45e054276a775bebade2a795c2412b91319326c6a299af6c2ceba175fc8fa4c51eb7721939760cf1. The SHA-384 digest of the encoded env.accel.0 Claims-Set is a24620821bdc8c9aec86dae14bbce0a627c13fe41cefe58eb20cd748eb56154391368d509d001f70e1c6cfe2815c388c. Both values appear under claim 266 in the signed main token. The complete 1682-byte bundle is below. A backslash indicates that one hexadecimal string continues on the next display line; the backslash and following indentation are not part of the encoded value.

Collected CDDL The following CDDL collects the definitions in this document. Values 60000 and 60001 are temporary stand-ins used only to make this Internet-Draft and its examples mechanically testable; they are not IANA allocations and implementations MUST NOT treat them as stable claim keys. bstr .cbor detached-claims-set } ]) composite-eat = #6.61(#6.18([ protected: bstr .cbor protected-headers, unprotected: unprotected-headers, payload: bstr .cbor composite-eat-claims, signature: bstr ])) protected-headers = { 1: -35, 3: "application/eat+cwt", 34: certificate-thumbprint } certificate-thumbprint = [ -43, bstr .size 48 ] unprotected-headers = { 33: cose-x509-chain } cose-x509-chain = bstr / [ 2* bstr ] composite-eat-claims = { 10: bstr .size 32, 265: general-uri, 256: bstr .size (7..33), 273: measurements-type, 266: submods-type, ? TBD_PLATFORM_CORIM_ID => general-uri } measurements-type = [ + lead-attester-measurement ] lead-attester-measurement = [ content-format: uint .le 65535, value: bstr ] submods-type = { + env-id => detached-submodule-digest } detached-submodule-digest = [ hash-alg: -43, digest: bstr .size 48 ] detached-claims-set = { TBD_NATIVE_EVIDENCE => native-evidence } native-evidence = spdm-evidence / device-eat-evidence spdm-evidence = [ evidence-type: 1, signed-measurements: bstr, cert-chain: bstr, ? vca: bstr ] device-eat-evidence = [ evidence-type: 2, token-format: tstr, device-token: bstr ] env-id = tstr .size (5..64) general-uri = tstr TBD_NATIVE_EVIDENCE = 60000 TBD_PLATFORM_CORIM_ID = 60001 ]]> general-uri above is the CBOR URI representation from , reduced to its tstr wire type so this stand-alone grammar has no external CDDL imports.

Acknowledgments The authors thank the design and implementation reviewers whose feedback improved the architecture, encoding, and verification procedures described in this document. Individual acknowledgments will be added as review continues.