]> Linaro

mathieu.poirier@linaro.org

Fraunhofer SIT

henk.birkholz@ietf.contact

Linaro

thomas.fossati@linaro.org

Security Remote ATtestation ProcedureS attestation device assignment EAT 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. About This Document The latest revision of this draft can be found at . 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 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). Most confidential computing platforms (e.g., Arm CCA, AMD SEV-SNP, Intel TDX) provide DA capabilities. Such capabilities prevent execution environments or software components that are untrusted by the TVM (including other TVMs and the host hypervisor) from accessing or controlling a device that has been assigned to the TVM. This includes, for example, protection of device MMIO interfaces and device caches. From a trust perspective, DA allows a device to be included in the TVM's Trusted Computing Base (TCB). For the TVM to trust the device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. gives an overview of the architecture targeted by this specification. Devices assigned to a TVM must be authenticated by a 3rd party verifier before being accepted into the TCB.

Confidential VM with Trusted Device(s)

This document defines an attestation Evidence format for DA as an EAT profile. The format is designed to be generic, extensible and architecture-agnostic. Ongoing work on DA concentrates on PCIe devices that support the SPDM protocol . As such, this document focuses on establishing the overall framework and formalizing an Evidence format for SPDM-compliant PCIe devices. It does not support on-chip SPDM-compliant device, something that is left for future consideration. The TVM uses the platform, i.e., PCIe Data Object Exchange (DOE), to transport SPDM packets, but the SPDM protocol uses its own mechanisms and messages to guarantee the authenticity and privacy of the information it carries. It defines specific messages for creating and exchanging cryptographic keys between requester and responder to establish secure communication. The cryptographic algorithms are selected based on the pre-negotiated capabilities of both parties (Section 10.16 of ). The SPDM protocol does not rely on the hypervisor or host for anything else other than the physical delivery of content between the trusted and non-trusted worlds. This format is based on the information provided by the SPDM protocol without imposing additional security constraints. It is incumbent upon other entities to describe, select and enforce those additional security constraints based on operational requirements. Since other bus architectures and protocols are expected to be supported as the technology gains wider adoption, provisions have been made for the definition of other Evidence formats such as Compute Express Link (CXL) and the Coherent Hub Interface (CHI). This list is by no means exhaustive and is expected to expand. outlines the requirements for incorporating new bus technologies into the Device Assignment Token (DAT) framework. Lastly, live migration of a TVM from one host to another is currently not addressed by the SPDM specification and therefore not covered herein. As discussed in , a lead Attester may also act as an internal Verifier. For example, the lead Attester would verify the identity of the SPDM responder locally using a provisioned trust anchor. If satisfied, it would then repackage the sub-Attester claims in the format defined in this document. In other words, the lead Attester would use the framework and claims defined in this document to create Attestation Results. In this sense, DAT can be considered to provide both an Attestation Result format and an Evidence format. Generally, the distinction between Evidence and Attestation Results, when applied to Conceptual Messages generated by a composite device, may not always be completely transparent to the receiver. Note that when using CMW to wrap the collected claims, the ind field could be used to refine the Conceptual Message type expressed by the EAT media type .

Conventions and Definitions 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. PCIe devices maximize hardware efficiency by splitting a single physical card into multiple independent logical devices called functions (see Section 9 of ). Because each physical or virtual function operates in isolation, multiple VMs can directly and safely share the same underlying hardware simultaneously. In this document, the terms "device", "interface" and "device interface" refer to the physical or virtual function of a device.

Device Assignment Token (DAT) Claims The Device Assignment Token (DAT) is the encompassing envelope for the individual device claims to be presented. A DAT can be used as a standalone entity but can also be embedded in a larger, platform-specific attestation token. A DAT consists of an EAT profile identifier, a nonce and an EAT submodule () that contains any number of individual device claims. Each individual submodule is the combination of a device name and a standard claims-set based on the bus or protocol the device supports. The syntax of the device name depends on the type of bus or protocol used. Each name consists of two parts joined by a colon: a namespace and a bus-specific name. See for SPDM devices, and for legacy PCIe devices. As previously mentioned, this draft currently defines the claims-set for SPDM compliant devices and PCIe legacy devices that do not support the SPDM protocol. Careful consideration was also given to the overall design in order to leave room for future expansion. "tag:linaro.org,2025:device#1.0.0" &(eat_nonce: 10) => bytes .size (8..64) &(eat_submods: 266) => { + device-name => $device-claims-set } } device-name = text $device-claims-set /= spdm-claims $device-claims-set /= pcie-legacy-claims ]]>

SPDM Claims A SPDM claim instance is expected to be present for each SPDM compatible device to be attested. Each instance consists of a measurements section, a certificates section, or both. These can be supplemented with two additional sections: (1) a challenge for Component Mesaurement and Authentication (CMA) scenarios and (2) a device interface report that contains information from the TEE Device Information Security Protocol (TDISP) Device Interface Report (see Chapter 11 of ). A challenge needs certificate information from the certificate section and as such, can only be present if certificates are included in the SPDM artifacts. TDISP messages are embedded in the VENDOR_DEFINED_REQUEST and VENDOR_DEFINED_RESPONSE messages of the SPDM protocol. Optionally, the Negotiated State preamble (version, capabilities and algorithms) bytes can be included to present the full negotiated state between the SPDM requester and responder. "tag:linaro.org,2025:device-spdm#1.0.0" spdm-artefacts ? &(vca: 3804) => bytes } spdm-artefacts //= ( &(measurements: 3802) => spdm-measurements &(certificates: 3803) => spdm-certificates ? &(challenge: 3807) => spdm-signature ? &(device-interface-report: 3808) => tdisp-device-interface-report ) spdm-artefacts //= ( &(measurements: 3802) => spdm-measurements ? &(device-interface-report: 3808) => tdisp-device-interface-report ) spdm-artefacts //= ( &(certificates: 3803) => spdm-certificates ? &(challenge: 3807) => spdm-signature ? &(device-interface-report: 3808) => tdisp-device-interface-report ) ]]>

Measurements Claim The SPDM specification reserves measurement indexes between 240 and 255, leaving space for 239 measurements per device. The entire measurement log is optionally signed by the certificate populated in one of the 8 certificate slots. It should be noted that measurements formalized herein follow the DMTF measurement specification (see Table 55 of ). spdm-measurement ? "signature" => spdm-signature } block-id = 1..239 ]]>

Measurement SPDM measurements start with a component type that reflects one of the 10 categories defined by the SPDM specification. Following is the measurement itself represented by either a raw bitstream or a digest. The size of the digest value is derived from the measurement hash algorithm conveyed by the SPDM ALGORITHMS message response. component-type measurement } measurement //= ( &(digest-measurement: 2) => digest-measurement ) measurement //= ( &(raw-measurement: 3) => raw-measurement ) component-type /= &(immutable-rom: 0) component-type /= &(mutable-firmware: 1) component-type /= &(hardware-config: 2) component-type /= &(firmware-config: 3) component-type /= &(freeform-measurement-manifest: 4) component-type /= &(device-mode: 5) component-type /= &(mutable-firmware-version: 6) component-type /= &(mutable-firmware-svn: 7) component-type /= &(hash-extend-measurement: 8) component-type /= &(informational: 9) component-type /= &(structured-measurement-manifest: 10) raw-measurement = bytes digest-measurement = digest digest = [ alg: uint / text val: bytes ] ]]>

SPDM Challenge Claim SPDM compliant devices can optionally support the capability to authenticate responders through the challenge-response protocol and sign measurements. Included in the signature are all the elements needed by a third party entity to reconstruct the original transcript or measurement log signed by the device. Those elements include M1 for challenge signatures or L1 for measurement signatures (see CDDL below), the combined SPDM prefix, the hash algorithm used to generate a digest of the measurement log and nonces provided by the requester and responder. The slot number of the leaf certificate used to sign the measurement log is also provided. 0..7, ; Slot of the certificate chain used to ; authenticate the measurement. Default ; should be 0. &(requester-nonce: 2) => bytes .size 32, &(responder-nonce: 3) => bytes .size 32, &(combined-spdm-prefix: 4) => bytes .size 100, &(IL1: 5) => bytes, ; M1 or L1 (see comment above) &(base-hash-algo: 6) => hash-algorithm-type, &(signature: 7) => bytes } ]]>

Certificate Claims According to the specification, SPDM compliant devices should support at most 8 slots, with slot 0 populated by default. Slot 0 SHALL contain a certificate chain that follows the Device certificate model or the Alias certificate model. Regardless of the certificate model used, a certificate chain comprises one or more DER-encoded X.509 v3 certificates . The certificates MUST be concatenated with no intermediate padding. As described in paragraph 355 of Section 10.6.1 of , the certificates in the chain are sorted in descending order, with the end-entity certificate (also known as the "leaf") appearing last. According to the same paragraph, a trust anchor may appear as the first certificate in the chain. If so, it should not be used to validate the chain without first confirming its presence in a trust anchor store. cert-chain ? aux-cert-slot-1 => cert-chain ? aux-cert-slot-2 => cert-chain ? aux-cert-slot-3 => cert-chain ? aux-cert-slot-4 => cert-chain ? aux-cert-slot-5 => cert-chain ? aux-cert-slot-6 => cert-chain ? aux-cert-slot-7 => cert-chain } ; ASN.1 DER-encoded certificates concatenated with no intermediate ; padding. cert-chain = bytes default-cert-slot = 0 aux-cert-slot-1 = 1 aux-cert-slot-2 = 2 aux-cert-slot-3 = 3 aux-cert-slot-4 = 4 aux-cert-slot-5 = 5 aux-cert-slot-6 = 6 aux-cert-slot-7 = 7 ]]>

TDISP Device Interface Report A TDISP Device Interface Report can only be obtained if the device interface has transitioned to the CONFIG_LOCK or RUN state of the TDISP state machine. Once in either of these states, the device's firmware ensures that modifications to the interface can't be made by an untrusted party. Trust in the device firmware's implemenation is imparted by its measurement and the signature it generates, both verifiable by a 3rd party entity. A TDISP Device Interface Report begins with various bitfields indicating the state and characteristics of the PCIe device interface. Next are 3 register fields pertaining to MSI-X (Message Signalled Interrupts), LNR (Lightweight Notification Requester) and TPH (TLP Processing Hints) capabilities. MMIO ranges are assigned from PCIe BAR(s) and provide information about the memory areas a device is working with. More information on the MMIO range bitfields and the ones defined as part of the device interface field (above) can be found in the TDISP section of the PCI Express specification. The last field is device-specific and optionally included to convey additional configuration information about the device. The tdisp-device-interface-report map MUST NOT be empty. interface-info-bits ? &(msi-x-message-control: 2) => bytes .size 2 ? &(lnr-control: 3) => bytes .size 2 ? &(tph-control: 4) => bytes .size 4 ? &(mmio-ranges: 5) => mmio-ranges ? &(device-specific-info: 6) => bytes }> interface-info-bits = bytes .bits interface-info-flags interface-info-flags = &(bit0: 0, bit1: 1, bit2: 2, bit3: 3, bit4: 4, bit5: 5, ) mmio-ranges = { + &(mmio-range: 1) => mmio-range } mmio-range = { &(first-4k-page: 1) => bytes .size 8 &(number-of-4k-pages: 2) => bytes .size 4 &(attributes: 3) => range-attributes } range-attributes = { &(range-attribute-bits: 1) => range-attribute-bits &(range-attribute-range-id: 2) => bytes .size 2 } range-attribute-bits = bytes .bits range-attributes-flags range-attributes-flags = &(bit0: 0, bit1: 1, bit2: 2, bit3: 3, ) ]]>

Negotiated State Preamble (Version, Capabilities and Algorithms) The Negotiated State Preamble (i.e., vca) claim contains the concatenation of messages GET_VERSION, VERSION, GET_CAPABILITIES, CAPABILITIES, NEGOTIATE_ALGORITHMS, and ALGORITHMS last exchanged between the SPDM Requester and Responder.

Submodule Naming The namespace used for SPDM submodules is "spdm". The name associated with an SPDM submodule is extracted from the leaf certificate of the relevant device.

• If the leaf certificate contains a Subject Alternative Name of type DMTFOtherName, the submodule name is the value contained in ub-DMTF-device-info. For example: "spdm:ACME:WIDGET:0123456789".
• Otherwise, the submod name is the string representation of the certificate Subject, as described in . For example: "spdm:C=CA,O=ACME,OU=Widget,CN=0123456789".

PCIe Legacy Device Claims A definition is provided for a device claims-set for PCIe legacy devices that do not implement the necessary extensions to attest to their provenance and configuration. This makes it possible to keep using current assets as secured ones are being provisioned. This legacy device claims-set simply mirrors the type 0/1 common registers of the PCIe configuration space, mandating only that the vendor and device identification code be provided. Other fields of the configuration space header may optionally be included should they add value. A binary format of the PCIe configuration space is made available for processing by existing PCIe configuration space tools. Implementers may optionally choose to include both text and binary versions should there be a use case to support this representation. "tag:linaro.org,2025:device-pcie-legacy#1.0\ .0" pcie-legacy-artefacts ? $$pcie-legacy-claim-extension } pcie-legacy-artefacts //= ( &(artefacts-text: 3805) => pcie-type-0-1-config-space-text &(artefacts-bytes: 3806) => pcie-type-0-1-config-space-bytes ) pcie-legacy-artefacts //= ( &(artefacts-text: 3805) => pcie-type-0-1-config-space-text ) pcie-legacy-artefacts //= ( &(artefacts-bytes: 3806) => pcie-type-0-1-config-space-bytes ) pcie-type-0-1-config-space-bytes = bytes .size 256 pcie-type-0-1-config-space-text = { &(vendorID: 1) => bytes .size 2 &(deviceID: 2) => bytes .size 2 ? &(command: 3) => bytes .size 2 ? &(status: 4) => bytes .size 2 ? &(revisionID: 5) => bytes .size 1 ? &(classCode: 6) => bytes .size 3 ? &(cacheLineSize: 7) => bytes .size 1 ? &(latencyTimer: 8) => bytes .size 1 ? &(headerType: 9) => bytes .size 1 ? &(BITS: 10) => bytes .size 1 } ]]>

Submodule Naming The namespace used for legacy PCIe submodules is "legacy-pcie". The name is any arbitrary string chosen by the implementation. For example, "legacy-pcie:0000:01:02.0" where "0000" is the domain, "01" the PCI bus id, "02" the device on the bus and "0" the device function.

DAT EAT Profile

Encoding A DAT is encoded in CBOR . The CBOR representation of a DAT MUST be "valid" according to the definition in . Only definite-length strings, arrays, and maps are allowed. Since a DAT emitter may be found in a constrained environment, it may not be able to emit CBOR preferred serializations (). Therefore, the Verifier MUST be a variation-tolerant CBOR decoder.

Cryptographic Protection Cryptographic protection can be obtained by wrapping the dat claims-set in a COSE Web Token (CWT) . In this case, the signature structure MUST be a tagged (18) COSE_Sign1. Alternatively, a DAT can be part of a Conceptual Message Wrapper (CMW) collection. In this case, the DAT claims-set can be a UCCS and the protection is provided by the signed CMW. The flexibility provided by the COSE format should be sufficient to adapt to the level of cryptographic agility required for specific use cases. It is RECOMMENDED that commonly adopted algorithms, such as those discussed in , are used. While receivers are expected to accept a wide range of algorithms, Attesters will produce DAT using only one such algorithm.

Use with Conceptual Message Wrappers When used in a CMW, the collector will wrap the serialised COSE_Sign1 or UCCS with the appropriate media type or CoAP Content-Format defined in .

Freshness Model DAT supports the freshness models for attestation Evidence based on nonces and epoch IDs (see Section and Section of ) using the eat_nonce claim to convey the nonce or epoch ID supplied by the Verifier. No further assumptions are made about the specific remote attestation protocol. Note that the use of epoch IDs is subject by the type restrictions imposed by the eat_nonce syntax. For use in DAT, the epoch ID MUST be encodable as an opaque binary string of between 8 and 64 octets; an Epoclet can be used for this purpose (see ).

Synopsis presents a concise view of the requirements described in the preceding sections. DAT Profile Synopsis

Issue	Profile Definition
CBOR/JSON	CBOR MUST be used
CBOR Encoding	Definite length maps and arrays MUST be used
CBOR Encoding	Definite length strings MUST be used
CBOR Serialization	Variant serialization MAY be used
COSE Protection	COSE_Sign1 MUST be used (directly or via CMW)
Algorithms	SHOULD be used
Detached EAT Bundle Usage	Detached EAT bundles MUST NOT be sent
Verification Key Identification	Any identification method listed in
Freshness	nonce or epoch ID based (Section and Section of )
Claims	Those defined in . As per general EAT rules, the receiver MUST NOT error out on claims it does not understand.

Extending the DAT Framework An extension to the DAT framework that introduces support for a new bus technology MUST provide the following information in a public document (e.g., an Internet-Draft):

• A precise definition of the new claims-set,
• A naming convention for the submod map entry,
• The registration of any new claims with IANA.

Claims-set Definition The new claims-set MUST be specified clearly and unambiguously, ideally using CDDL, with a separate prose description of each claim. The claims-set MUST include a suitable eat_profile value. See for the blueprint.

Naming Conventions for the submod Key A new claims-set MUST define a suitable naming convention for the submod keys associated with it. When creating this convention, ensure that it does not clash with any existing ones. See for the blueprint. The concrete name derived by the naming scheme is anticipated to be used to map the Attester to a corresponding CoRIM environment map. This map can then be used to locate matching Reference Values and Endorsements during the appraisal process. This type of "evidence transformation" is outside the scope of this document and will be covered by an associated CoRIM profile.

Claims Registrations A new claims-set can reuse any number of already registered claims. If the claims-set needs to define new claims to express the desired semantics, and if these claims have generally applicable semantics, they SHOULD be registered with IANA. See for the blueprint.

Collated CDDL "tag:linaro.org,2025:device#1.0.0", &(eat_nonce: 10) => bytes .size (8 .. 64), &(eat_submods: 266) => {+ device-name => $device-claims-set}, } device-name = text $device-claims-set /= spdm-claims / pcie-legacy-claims spdm-claims = { &(eat_profile: 265) => "tag:linaro.org,2025:device-spdm#1.0.0", spdm-artefacts, ? &(vca: 3804) => bytes, } spdm-artefacts //= (( &(measurements: 3802) => spdm-measurements, &(certificates: 3803) => spdm-certificates, ? &(challenge: 3807) => spdm-signature, ? &(device-interface-report: 3808) => tdisp-device-interface\ -report, ) // ( &(measurements: 3802) => spdm-measurements, ? &(device-interface-report: 3808) => tdisp-device-interface\ -report, ) // ( &(certificates: 3803) => spdm-certificates, ? &(challenge: 3807) => spdm-signature, ? &(device-interface-report: 3808) => tdisp-device-interface\ -report, )) spdm-measurement = { &(component-type: 1) => component-type, measurement, } measurement //= (&(digest-measurement: 2) => digest-measurement // &\ (raw-measurement: 3) => raw-measurement) component-type /= &(immutable-rom: 0) / &(mutable-firmware: 1) / &(\ hardware-config: 2) / &(firmware-config: 3) / &(freeform-measurement\ -manifest: 4) / &(device-mode: 5) / &(mutable-firmware-version: 6) \ / &(mutable-firmware-svn: 7) / &(hash-extend-measurement: 8) / &(\ informational: 9) / &(structured-measurement-manifest: 10) raw-measurement = bytes digest-measurement = digest digest = [ alg: uint / text, val: bytes, ] spdm-certificates = { default-cert-slot => cert-chain, ? aux-cert-slot-1 => cert-chain, ? aux-cert-slot-2 => cert-chain, ? aux-cert-slot-3 => cert-chain, ? aux-cert-slot-4 => cert-chain, ? aux-cert-slot-5 => cert-chain, ? aux-cert-slot-6 => cert-chain, ? aux-cert-slot-7 => cert-chain, } cert-chain = bytes default-cert-slot = 0 aux-cert-slot-1 = 1 aux-cert-slot-2 = 2 aux-cert-slot-3 = 3 aux-cert-slot-4 = 4 aux-cert-slot-5 = 5 aux-cert-slot-6 = 6 aux-cert-slot-7 = 7 spdm-measurements = { + block-id => spdm-measurement, ? "signature" => spdm-signature, } block-id = 1 .. 239 hash-algorithm-type /= &(tpm_alg_sha_256: 0) / &(tpm_alg_sha_384: 2\ ) / &(tpm_alg_sha_512: 4) / &(tpm_alg_sha3_256: 8) / &(\ tpm_alg_sha3_384: 16) / &(tpm_alg_sha3_512: 32) / &(tpm_alg_sm3_256\ : 64) spdm-signature = { &(slot: 1) => 0 .. 7, &(requester-nonce: 2) => bytes .size 32, &(responder-nonce: 3) => bytes .size 32, &(combined-spdm-prefix: 4) => bytes .size 100, &(IL1: 5) => bytes, &(base-hash-algo: 6) => hash-algorithm-type, &(signature: 7) => bytes, } pcie-legacy-claims = { &(eat_profile: 265) => "tag:linaro.org,2025:device-pcie-legacy#1.0\ .0", pcie-legacy-artefacts, ? $$pcie-legacy-claim-extension, } pcie-legacy-artefacts //= (( &(artefacts-text: 3805) => pcie-type-0-1-config-space-text, &(artefacts-bytes: 3806) => pcie-type-0-1-config-space-bytes, ) // &(artefacts-text: 3805) => pcie-type-0-1-config-space-\ text // &(artefacts-bytes: 3806) => pcie-type-0-1-config-space-bytes) pcie-type-0-1-config-space-bytes = bytes .size 256 pcie-type-0-1-config-space-text = { &(vendorID: 1) => bytes .size 2, &(deviceID: 2) => bytes .size 2, ? &(command: 3) => bytes .size 2, ? &(status: 4) => bytes .size 2, ? &(revisionID: 5) => bytes .size 1, ? &(classCode: 6) => bytes .size 3, ? &(cacheLineSize: 7) => bytes .size 1, ? &(latencyTimer: 8) => bytes .size 1, ? &(headerType: 9) => bytes .size 1, ? &(BITS: 10) => bytes .size 1, } tdisp-device-interface-report = non-empty<{ ? &(interface-info: 1) => interface-info-bits, ? &(msi-x-message-control: 2) => bytes .size 2, ? &(lnr-control: 3) => bytes .size 2, ? &(tph-control: 4) => bytes .size 4, ? &(mmio-ranges: 5) => mmio-ranges, ? &(device-specific-info: 6) => bytes, }> interface-info-bits = bytes .bits interface-info-flags interface-info-flags = &( bit0: 0, bit1: 1, bit2: 2, bit3: 3, bit4: 4, bit5: 5, ) mmio-ranges = {+ &(mmio-range: 1) => mmio-range} mmio-range = { &(first-4k-page: 1) => bytes .size 8, &(number-of-4k-pages: 2) => bytes .size 4, &(attributes: 3) => range-attributes, } range-attributes = { &(range-attribute-bits: 1) => range-attribute-bits, &(range-attribute-range-id: 2) => bytes .size 2, } range-attribute-bits = bytes .bits range-attributes-flags range-attributes-flags = &( bit0: 0, bit1: 1, bit2: 2, bit3: 3, ) non-empty = M .and ({+ any => any}) ]]>

Security Considerations As this specification reuses the EAT specification , it also reuses the CWT specification . The security and privacy considerations of these specifications therefore apply here too. In particular, the considerations discussed in Sections Claim Trustworthiness, Multiple EAT Consumers and Detached EAT Bundle Digest Security Considerations of apply fully. When DAT is an UCCS, the considerations in also apply. PCIe devices are assigned to a TVM via their physical or virtual functions. The hardware implementation of a device guarantees that functions are mutually exclusive; in other words, operations performed on one function do not affect other functions. The TDISP standard also guarantees that, while a device function is in the CONFIG_LOCK or RUN state, its characteristics cannot be modified by untrusted parties. However, faulty hardware or an inadequate implementation of the TDISP specification could be exploited by an attacker for side-channel attacks.

Privacy Considerations A DAT can include a great deal of detail about the execution environment associated with the TVM and, therefore, the workload being executed within it. This can provide insight into the type of computation being carried out by the workload. It can also enable tracking of a given workload across multiple TVM instances in both the temporal dimension (e.g., across reboots of the hosting hardware) and the spatial dimension (e.g., across migrations between hardware, either within or between data centres). A DAT is usually one component of a composite evidence payload. In such cases, multiple Verifiers may be involved in the appraisal process. The differential encryption considerations discussed in Section Multiple EAT Consumers of therefore apply.

IANA Considerations

New CWT Claims Registrations IANA is requested to register the following claims in the "CBOR Web Token (CWT) Claims" registry .

 SPDM Measurements Claim

• Claim Name: spdm-measurements
• Claim Description: SPDM Measurements
• JWT Claim Name: N/A
• Claim Key: 3802
• Claim Value Type(s): map
• Change Controller: IETF
• Specification Document(s): of RFCthis

 SPDM Certificates Claim

• Claim Name: spdm-certificates
• Claim Description: SPDM Certificates
• JWT Claim Name: N/A
• Claim Key: 3803
• Claim Value Type(s): map
• Change Controller: IETF
• Specification Document(s): of RFCthis

 SPDM VCA Claim

• Claim Name: spdm-vca
• Claim Description: SPDM Version, Capabilities and Algorithms
• JWT Claim Name: N/A
• Claim Key: 3804
• Claim Value Type(s): bytes
• Change Controller: IETF
• Specification Document(s): of RFCthis

 PCIe Legacy Device Text Claim

• Claim Name: pcie-legacy-device-text
• Claim Description: PCIe Legacy Device Textual Representation
• JWT Claim Name: N/A
• Claim Key: 3805
• Claim Value Type(s): map
• Change Controller: IETF
• Specification Document(s): of RFCthis

 PCIe Legacy Device Binary Claim

• Claim Name: pcie-legacy-device-binary
• Claim Description: PCIe Legacy Device Binary Representation
• JWT Claim Name: N/A
• Claim Key: 3806
• Claim Value Type(s): bytes
• Change Controller: IETF
• Specification Document(s): of RFCthis

 SPDM Challenge Claim

• Claim Name: spdm-challenge
• Claim Description: SPDM Challenge signature block
• JWT Claim Name: N/A
• Claim Key: 3807
• Claim Value Type(s): map
• Change Controller: IETF
• Specification Document(s): of RFCthis

 TDISP Device Interface Report

• Claim Name: tdisp-device-interface-report
• Claim Description: TDISP Device Interface Report
• JWT Claim Name: N/A
• Claim Key: 3808
• Claim Value Type(s): map
• Change Controller: IETF
• Specification Document(s): of RFCthis

References Normative References 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. 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 X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK] IANA 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. This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, Message Authentication Code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and its processing considerations. It also discusses security implications of using unprotected claims sets. 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). 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. 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. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. 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 CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like 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, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Fraunhofer SIT Linaro Huawei Technologies Arm Universität Bremen TZI This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. 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 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. DMTF PCI-SIG

Examples

Example Composite Device shows an example of the composite device described in within a confidential computing environment. In this setup, a Trusted Virtual Machine (TVM) executes on a Confidential Platform, which provides the confidential computing environment. One or more devices (e.g., a GPU) are assigned to the TVM. Within the TVM, a Lead Attester agent, e.g., a userland daemon, can collect Evidence from the Confidential Platform, as well as from all the assigned devices, using the relevant ABI offered by the guest OS kernel. When a challenger (i.e., a Verifier or a Relying Party) requests Evidence from the TVM, the Lead Attester broadcasts the received nonce to all the sub-Attesters, obtains Evidence from each of them and assembles the composite Evidence using a CMW Collection (Section 3.3 of ). It then signs the composite Evidence using its key material as shown in . The claims obtained by the assigned devices are repackaged into DAT submods, which are then signed as part of the CMW collection using the Lead Attester key.

Composite Attestation Evidence | Lead Attester | | | | | Evidence | | | | '---------------' | | | | | | .---------------. | nonce --+------->| Platform | | | | | Evidence | | .----------------------------. | | '---------------' | | eat_profile | | | | | eat_nonce | | | .---------------. | | submod { | '------->| DAT +- - -+ "spdm:A": { ... } | | '---------------' | | "legacy-pcie:B": { ... } | '---------------------' | "spdm:C": { ... } | | } | '----------------------------' ]]>

The Veraison project's ratsd daemon is an example of this behaviour.

Acknowledgments Thank you Basma El Gaabouri, Carl Wallace, Giri Mandyam, , James Bottomley, Jon Lange, Lukas Wunner, Michael Richardson, Ned Smith, Roksana Golizadeh Mojarad, Simon Frost, Yogesh Deshpande and Yousuf Sait for your comments and suggestions.