An EAT Profile for Composite Platform Attestation

1.1. 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.¶

1.2. Approach

A Lead Attester (Section 3.3 of [RFC9334] 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, [RFC9711]). The signed digests bind the detached evidence; the native bytes preserve each device's own end-to-end signature.¶

1.3. Relationship to Other RATS Work

[I-D.poirier-rats-eat-da] 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 (Section 5.3); the two profiles address different consumers and are complementary.¶

1.4. 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 Section 6 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.¶

3.1. Composite Device Realization

This profile realizes the Section 3.3 of [RFC9334] 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.¶

3.2. 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 Section 7.¶

3.3. Role Mapping

4.1. Profile Conformance

This section states the Section 6 of [RFC9711] profile items for this profile.¶

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 Section 6.2 of [RFC9711].¶

4.2. Bundle Structure

The authoritative artifact is a Detached EAT Bundle (CBOR tag 602, [RFC9711]). 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 Section 5. When conveyed with a media type, the bundle MUST use application/eat-bun+cbor [RFC9782].¶

composite-bundle = #6.602([
  main-token: bstr .cbor composite-eat,         ; slot 1, see 4.3/4.4
  detached-claims-sets: {                  ; slot 2, see Section 5
    + env-id => 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 [RFC9360]. 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 [RFC9360].¶

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 [RFC5280].¶

4.3. Top-Level Claims

composite-eat-claims = {
  10:  bstr .size 32,     ; eat_nonce      (MANDATORY) Verifier nonce
  265: general-uri,      ; eat_profile    (MANDATORY)
  256: bstr .size (7..33), ; ueid         (MANDATORY) Lead id
  273: measurements-type, ; measurements  (MANDATORY) see 4.4
  266: submods-type,      ; submods       (MANDATORY) see 5.1
  ? TBD_PLATFORM_CORIM_ID => 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 Section 9.¶

4.4. 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.¶

measurements-type = [ + lead-attester-measurement ]

lead-attester-measurement = [
  content-format: uint .le 65535,  ; payload CoAP Content-Format
  value: bstr                      ; payload bytes per content-format
]

This constrains the measurements claim format defined by [RFC9711]; it does not define a map-based replacement for that claim. The Lead Attester MUST use a registered CoAP Content-Format for each value.¶

5.1. Detached-Submodule-Digest Binding

Every Sub-Attester is represented in the signed token as a Detached-Submodule-Digest ([RFC9711]). The full evidence is the detached Claims-Set in slot 2 of Section 4.2, keyed by the same Target Environment Identifier.¶

submods-type = { + env-id => 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 Section 5.2, 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.¶

5.2. Deterministic Encoding and Digest Rules

Each detached Claims-Set MUST be encoded with deterministic CBOR (Section 4.2 of [RFC8949]). 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.¶

5.3. 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 [RFC9711] while allowing the profile to carry several native evidence formats.¶

detached-claims-set = {
  TBD_NATIVE_EVIDENCE => 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-evidence = [
  evidence-type: 1,
  signed-measurements: bstr,  ; native SignedMeasurements bytes
  cert-chain: bstr,           ; reassembled SPDM certificate chain
  ? vca: bstr                 ; required for SPDM 1.0/1.1
]

device-eat-evidence = [
  evidence-type: 2,
  token-format: tstr,   ; media type, e.g. "application/eat+cwt"
  device-token: bstr
]

5.4. 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.¶

7.1. 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.¶

7.2. 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.¶

7.3. 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 [RFC9711] 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 [RFC9360].¶

7.4. 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.¶

9.1. 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: Section 5.3 of this document¶

9.2. 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: Section 4.3 of this document¶

9.3. 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.¶

10.1. Normative References

[DSP0274]

DMTF, "Security Protocol and Data Model (SPDM) Specification", DSP0274 Version 1.3.2, 2024, <https://www.dmtf.org/dsp/DSP0274>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, <https://www.rfc-editor.org/rfc/rfc9360>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[RFC9782]

Lundblade, L., Birkholz, H., and T. Fossati, "Entity Attestation Token (EAT) Media Types", RFC 9782, DOI 10.17487/RFC9782, May 2025, <https://www.rfc-editor.org/rfc/rfc9782>.

10.2. Informative References

[I-D.ietf-rats-corim]

Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and W. Pan, "Concise Reference Integrity Manifest", Work in Progress, Internet-Draft, draft-ietf-rats-corim-11, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-11>.

[I-D.poirier-rats-eat-da]

Poirier, M., Birkholz, H., and T. Fossati, "An EAT Profile for Trustworthy Device Assignment", Work in Progress, Internet-Draft, draft-poirier-rats-eat-da-10, 23 June 2026, <https://datatracker.ietf.org/doc/html/draft-poirier-rats-eat-da-10>.

[RFC9999]

Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig, "Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026, <https://www.rfc-editor.org/rfc/rfc9999>.

[TCG-DICE-CE]

Trusted Computing Group, "DICE Attestation Architecture (Concise Evidence)", <https://trustedcomputinggroup.org/>.