]> 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 and 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. 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 devices. 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 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.

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.

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 device claim is the combination of a device name and a standard claims format 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 semicolon: 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 condideration 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 64 ; same as realm nonce &(eat_submods: 266) => { + device-name => $device-claims-set } } device-name = text $device-claims-set /= spdm-claims $device-claims-set /= cxl-claims $device-claims-set /= chi-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. 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 There can be up to 239 measurements per device with the entire measurement log 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. 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. 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. It 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. interface-info-bits ? &(msi-x-message-control: 2) => bytes .size 2 ? &(lnr-control: 2) => bytes .size 2 ? &(tph-control: 3) => bytes .size 4 ? &(mmio-ranges: 4) => mmio-ranges ? &(device-specific-info: 5) => 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 The definition of a device claims set for PCIe legacy devices that do not implement the extensions needed to attest for their provenance and configuration is provided, making it is possible to keep using current assets as secures 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.

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 64, &(eat_submods: 266) => {+ device-name => $device-claims-set}, } device-name = text $device-claims-set /= spdm-claims / cxl-claims / chi-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, } cxl-claims = {&(eat_profile: 265) => "tag:linaro.org,2025:device-cxl\ #1.0.0"} chi-claims = {&(eat_profile: 265) => "tag:linaro.org,2025:device-chi\ #1.0.0"} 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 = { ? &(interface-info: 1) => interface-info-bits, ? &(msi-x-message-control: 2) => bytes .size 2, ? &(lnr-control: 2) => bytes .size 2, ? &(tph-control: 3) => bytes .size 4, ? &(mmio-ranges: 4) => mmio-ranges, ? &(device-specific-info: 5) => 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, ) ]]>

Security Considerations TODO Security

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 DMTF

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.

Confidential VM with Trusted Device(s)

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, James Bottomley, Jon Lange, Lukas Wunner, Roksana Golizadeh Mojarad, Simon Frost and Yousuf Sait for your comments and suggestions.