]> Nokia

kondtir@gmail.com

Independent

ietf@nritz.com

Independent

yaronf.ietf@gmail.com

Arm

ionut.mihalcea@arm.com

Security SEAT Working Group remote attestation TLS confidential computing RATS workload identity This document surveys how remote attestation for confidential computing is deployed by major cloud providers and derives the learnings. Based on these, it presents multiple options for establishing the identity of a confidential workload in attested TLS for further discussion. The list of options is not exhaustive, and additional options are welcome. The purpose of this document is to help the SEAT working group decide on an approach or approaches for the confidential computing use case. About This Document Status information for this document may be found at . Discussion of this document takes place on the SEAT Working Group mailing list (), which is archived at . Subscribe at .

Introduction Remote attestation lets a peer gain assurance about the state of a confidential workload before exchanging data with it. When attestation is combined with a secure channel such as TLS 1.3 , a further question arises: does the peer need to identify the specific workload instance on the connection, as opposed to confirming only that some genuine instance of the approved workload is running. This is the question of workload identity that this document examines. Confidential computing is already deployed at scale by major cloud providers, each of which has an established way of producing attestation Evidence, conveying it, and binding it to a workload. These deployments offer useful lessons for how attested TLS could establish workload identity. This document first surveys those deployments and derives the common learnings. It then presents options for establishing workload identity in attested TLS. The options are not exhaustive, and further options are welcome. The intent is to give the SEAT working group a basis for deciding on an approach or approaches for the confidential computing use case. This document describes deployments and options; it does not specify a protocol. The option the working group favours is expected to be reflected in its solution documents. This document does not limit "confidential computing" to the Confidential Computing Consortium's definition: protection of data in use inside a TEE, so that even the host kernel and hypervisor cannot inspect the protected data. In scope for the document are isolated and attested workloads. General-purpose hosts or VMs without this kind of isolation and attestation are out of scope.

Terminology This document uses the RATS terms defined in , including Attester, Attesting Environment, Target Environment, Verifier, Relying Party, Evidence, Endorsement, Attestation Result, and the Passport and Background-Check models. It uses the Entity Attestation Token (EAT) and its claims from . This document also uses the following terms:

• Attestation Key (AK): the key that signs Evidence, endorsed through a root-of-trust chain. How the AK is rooted is platform specific.
• Measurements: claims in the Evidence that represent the state of the Target Environment, and possibly that of the Attesting Environment.
• Workload: the confidential application whose identity is being established, used in the broad sense of (a logical, independently addressable and executable entity such as a container, VM, microservice, or serverless function), not necessarily a single running process.
• TLS authentication key: the key a peer uses to authenticate itself in the TLS handshake.
• Trusted Computing Base (TCB): see .

Deployment Models This section surveys how remote attestation is deployed by three major cloud providers. Each sub-section follows the same structure: how Evidence is produced and rooted, how the peer verifies it, and how workload identity and key binding are done.

AWS Nitro Enclaves How AWS describes it: AWS calls the Evidence an attestation document, generated and signed by the Nitro Hypervisor, containing platform configuration registers (PCRs) and additional information . The document is CBOR-encoded and COSE-signed, and its certificate chains to the AWS Nitro Attestation PKI, whose root certificate is published by AWS . The consumer, that is the Relying Party, supplies a cryptographic nonce in the attestation request; the Nitro Hypervisor includes it in the signed document, and the Relying Party checks the returned value matches the one it sent, which binds the document to that request and prevents replay of a previous document. The enclave can include a public key it generated, which a consumer such as a key-management service uses to encrypt data that only the enclave can decrypt. Evidence and root of trust: The confidential workload runs in an isolated environment whose measurements are recorded by the platform. On request, the platform's Attesting Environment produces signed Evidence containing those measurements. The Evidence is signed by an Attestation Key held in the platform's privileged firmware, and its certificate chains to a provider-operated root of trust that the Relying Party is expected to hold in advance. The workload does not control this key. How the peer verifies: The Relying Party consumes the Evidence directly (Background-Check model). It validates the certificate chain to the provider root, appraises the measurements against its Appraisal Policy, and checks a nonce for freshness. There is no Verifier in the connection path. Who provides the Verifier: There is no separate Verifier service; the Relying Party also acts as the Verifier, appraising the attestation document itself (Background-Check). Appraisal policy is therefore not absent, it is applied by the Relying Party. In the common deployment the Relying Party is AWS KMS, whose key policy can require the attestation document to report expected measurement values before the key is released, not merely that the document is a genuine Nitro attestation. When the policy is met, KMS encrypts the response under the public key from the document so only the enclave can decrypt it . Workload identity and key binding: Identity is the measurements recorded by the platform (including a measurement identifying the code signer); this is a type identity, not a per-instance one. To identify a specific instance, the enclave application generates a key pair and includes the public key in the attestation request; the Nitro Hypervisor returns a signed attestation document carrying that public key alongside the measurements . The private key is held by the workload. Because the public key is carried in the signed Evidence, the Relying Party can associate it with the attested workload.

GCP Confidential Space How GCP describes it: In Confidential Space, the workload runs as a container inside a Confidential VM. The boot chain and the container image are measured, and an attestation service verifies these measurements and, on success, issues an OpenID Connect (OIDC) attestation token whose claims describe the workload and the platform . Typical use case: multiple parties let a workload use their sensitive data together without revealing it to each other. Each party releases access to its data, for example a decryption key, only after the attestation token shows the approved workload is running. Evidence and root of trust: Google Cloud Confidential VMs provide two forms of Evidence :

• A quote from a Google-managed virtual TPM (vTPM), implemented in the hypervisor outside the hardware-enforced boundary of the Confidential VM. The vTPM records the boot and workload measurements. This Evidence is rooted in Google Cloud infrastructure.
• On AMD SEV-SNP and Intel TDX, hardware attestation.

Confidential Space attestation is based on the vTPM quote . How the peer verifies: The Verifier appraises the Evidence against reference measurements and issues a signed Attestation Result. The Relying Party validates the Attestation Result against the Verifier's key and appraises the claims in the Result against its Appraisal Policy. The Relying Party trusts the Verifier rather than appraising the Evidence itself. Who provides the Verifier: The Verifier is a separate service, Google Cloud Attestation, operated by the provider (Passport model). The workload operator may instead select a third-party Verifier; Confidential Space also supports Intel Trust Authority in this role . The Relying Party validates the issued token using the Verifier's public key and appraises the token's claims against its own Appraisal Policy. In the multi-party use case each data owner is a separate Relying Party. They can use the same Verifier, but each appraises the same Attestation Result against its own Appraisal Policy. Policy management therefore sits with each Relying Party, not with the Verifier. Workload identity and key binding: Identity is the measurements carried as claims in the Attestation Result (including a claim identifying the code signer); this is a type identity, not a per-instance one. To identify a specific instance to a peer, the workload binds the attestation to the TLS connection: the nonce in the Attestation Result is derived from the TLS exporter, and the Relying Party derives the same value from its side of the TLS connection and requires the two to match. The binding is therefore to the TLS connection rather than to a key carried in the Evidence.

Azure Confidential Computing How Azure describes it: A confidential VM runs on a hardware TEE with a virtual TPM. The confidential VM collects a platform report and a vTPM quote and sends it to Microsoft Azure Attestation (MAA). MAA validates the evidence against Microsoft's known-good baseline and issues a signed JSON Web Token (JWT) whose claims describe the platform and its state . Typical use case: a confidential VM proves its state so that a key service releases secrets to it. Azure Key Vault releases a key to the VM only when the attestation token satisfies the key's release policy, a mechanism Azure calls Secure Key Release . Evidence and root of trust: The confidential workload runs in a confidential VM containing a virtual TPM. The Attester is layered . The hardware Attesting Environment produces signed Evidence covering the provider-built guest paravisor, in which the virtual TPM runs, and carrying the virtual TPM's Attestation Key. The virtual TPM in turn produces signed Evidence covering the guest's measurements. Its Attestation Key is therefore rooted in the hardware root of trust through the layer below . How the peer verifies: As in , a Verifier issues an Attestation Result (Passport model), which the Relying Party validates using the Verifier's public key and appraises against its policy. Who provides the Verifier: The Verifier is Microsoft Azure Attestation (MAA), a service operated by the provider (Passport model). MAA appraises the Evidence and issues the JWT. The Relying Party, for example Azure Key Vault, then verifies the JWT's signature using MAA's public key and checks the JWT's claims against its own release policy . Workload identity and key binding: MAA's signed JWT carries claims about the platform and its state, such as which hardware TEE the VM runs on and whether the VM meets Microsoft's confidential-VM baseline. These describe that the VM is a genuine confidential VM in an approved state rather than identifying a particular workload instance. In the common deployment the Relying Party is Azure Key Vault. It appraises the JWT's claims against its Appraisal Policy and releases the key to the confidential VM only if they satisfy it. Azure refers to this key-release mechanism as Secure Key Release.

Learnings The three deployments structure the Attester differently. AWS Nitro Enclaves use a single Attesting Environment. GCP Confidential VMs provide a provider-managed virtual TPM outside the hardware-enforced boundary, and hardware attestation on AMD SEV-SNP and Intel TDX. Azure uses a layered Attester , where the hardware Evidence carries the virtual TPM's Attestation Key.

Workload Identity Measurements establish the type of a workload, not which running instance it is. Two instances of the same workload have identical measurements, and attestation cannot distinguish between two instances of the same workload. Where a distinguishing identity is needed, it is supplied by the workload: it generates an asymmetric key pair inside the attested environment, and the public key is conveyed in the attestation. This binds the connection to that specific key. The key itself is not a stable identifier, since keys are rotated periodically. Where a stable instance identity is needed, the key is certified in a PKI and the certificate carries a workload identifier that persists across key rotation . Where PKI is not available, the key is used without such an identifier . The workload presents this key in the TLS handshake, and the attestation binds it to the attested workload. The key may carry no identity of its own, presented as a self-signed certificate whose trust comes only from the attestation, or it may be certified by a PKI that binds it to a workload identity. Whether a per-instance identity is needed depends on the use case. Releasing a secret to any genuine instance of an approved image does not require knowing which instance, and the deployed measurements-and-Verifier model suffices. Attested TLS may instead need to reach one specific instance and distinguish it from another running the same image. The deployed model cannot make that distinction, so the working group has to decide whether attested TLS must identify a specific instance, and whether a key-based identity is sufficient. Authenticating an instance is distinct from authorization. Verifying the identity certificate and appraising the Evidence independently does not confirm that the measurements are authorized for that identity. An instance could hold a validly issued certificate while running a different, unapproved image; each check would pass on its own because neither looks at the other. Where this assurance is required, the Relying Party's Appraisal Policy must evaluate the identity and measurements jointly, rejecting the connection if there is a mismatch, as described in . Similarly, when no certificate is available, the measurements must reflect this intent, as described in . How the Evidence or Attestation Result is carried in a TLS extension is discussed in the SEAT solution documents, see and .

Option A: Attestation-Anchored Key The workload generates an asymmetric key pair inside the attested environment and conveys the public key in the Evidence. The Evidence is signed by the AK, so the AK vouches for the key. The workload presents the public key in the TLS handshake using one of two mechanisms: * As a Raw Public Key (RPK) or * As a self-signed X.509 certificate , which uses standard certificate structures but carries no validated PKI identity. The Relying Party checks that the public key presented in the TLS handshake matches the public key conveyed in the Evidence, appraises the Evidence and its measurements, and relies on the TLS handshake (CertificateVerify) for proof of possession. Authentication of the workload's key therefore rests on the AK signature over the Evidence, with the AK acting as the trusted party in place of a certification authority. This option requires no PKI. Its trust anchor is the attestation root of trust from which the AK is endorsed. The requirement that the key be generated in, and confined to, the attested environment is addressed in . Option A does not assign a workload identity. The workload is identified by its measurements and the attested key; there is no separate identifier. Whether this is sufficient depends on the use case (). The Relying Party should, as part of its appraisal policy, check that the workload described by the Evidence is expected and allowed to authenticate itself without a PKI-backed identity.

Option B: PKI-Anchored Certificate with Workload Identity The workload generates an asymmetric key pair inside the attested environment and obtains a WIMSE Workload Identity Certificate for the public key. The certificate binds the workload's identifier to the public key. The public key is also conveyed in the attestation Evidence, which binds the workload identity and the key to the attested workload. The workload presents the certificate in the TLS handshake. The Relying Party validates the certificate using the trust anchors for the workload's WIMSE trust domain and verifies proof of possession of the private key in the TLS handshake. Independently, it appraises the Evidence and verifies that the certificate's public key is bound to the attested workload. The PKI binds the workload identity to the key: the certificate names the workload and certifies its key. The attestation binds that same key to the attested environment, as described in . The key is the common element, so the certificate's name applies to the attested workload only because both refer to the same key. This transitive binding ensures the key is held by the attested environment, but it does not establish that the Target Environment is authorized to act under that workload identity. If the Relying Party validates the certificate and appraises the Evidence independently, an authorized key can be hosted in an authentic Target Environment whose measurements are not actually approved for that identity. Where the Relying Party requires assurance that a given identity runs only in an approved environment, its Appraisal Policy needs to evaluate the workload identity and platform measurements jointly, requiring the reported measurements to be authorized for the identity asserted in the certificate. The issuing certification authority may also appraise the attestation Evidence before issuing the certificate, for example by carrying Evidence in the certificate signing request . A Relying Party may be configured to trust a certification authority whose policy requires such appraisal. Even so, the Relying Party appraises the Evidence itself: the certification authority's appraisal is additional assurance, not a replacement for the Relying Party's own check. In all cases the requirement of holds. Confidential workloads are often short-lived, and certificate revocation (for example CRLs or OCSP) may be too slow to track rapid instance churn. Short-lived, automatically renewed certificates address this: the certificate's validity period is kept short and it is renewed while the workload runs, so a torn-down instance's certificate simply expires rather than requiring revocation. This contrasts with Option A, where the attested key is ephemeral and carries no certificate lifecycle to manage. Note: the certification authority may be hosted by the cloud service provider or by a third party. Confidential computing does not remove the entire provider from the trust boundary; it removes the host kernel and hypervisor from the workload's TCB , so a provider-hosted certification authority may still be relied upon.

Key Provenance The security of both options rests on one requirement: the Relying Party must have verifiable assurance that the key was generated for the workload, cannot be exported from it, and is stored securely during the lifetime of the workload. Conveying a public key in the Evidence, or certifying it with a PKI, does not establish this on its own. Neither shows where the private key was generated or whether it can leave the environment, and the equality check in and only ties the presented key to the key named in the Evidence. This assurance is provided by the key attestation defined in . It conveys the key in the Evidence together with key-attributes asserting that the key was locally generated and is non-exportable, and it relies on proof of possession from the surrounding protocol. Proof of possession and the key-attributes are not sufficient on their own to prove that a key has not been exfiltrated. Proof of possession shows only that some party currently holds the private key; it does not show that the key was never exported, and an exported key can still produce a valid proof of possession. The local-generation and non-exportable properties can be established in two ways:

• If the Attesting Environment is capable of also acting as a key store with key attestation capabilities, these properties are assertions made by the Attesting Environment. Relying on them therefore depends on trust in the Attesting Environment, which must not misreport the key-attributes.
• Alternatively, the Verifier may infer, based on endorsements made for Target Environment measurements, that the workload can be trusted to generate, store, and attest its own keys. In such cases, at least the key management software is expected to run within a TEE to benefit from its additional security guarantees. Under this model, the properties are thus asserted by the Verifier.

Security Considerations This document surveys deployment models and design options; it does not define a protocol. The following considerations apply. Key provenance: Both options depend on the key being generated in, and confined to, the attested environment (). Otherwise a key generated or held outside the environment could satisfy the checks in and without being protected by it. As noted in , proof of possession and the key-attributes do not by themselves prove a key has not been exfiltrated; the local-generation and non-exportable properties are assertions by the Attesting Environment and are only as trustworthy as that environment. For a disclosed key certified by a PKI, certificate revocation is the remedy. Attestation Key compromise: Both options rely on the AK that signs the Evidence. A compromised AK can sign Evidence for any key and any state, and no binding at the TLS layer detects this. Recovery is by no longer accepting Evidence signed by that AK at appraisal. Freshness: Evidence reflects the workload's state when it was produced, and a Relying Party requires assurance that this state is current for the connection being established. The workload's key may be ephemeral or long-lived, and the WIMSE certificate in Option B is a long-lived credential reused across connections. In both options, binding the Evidence to the TLS connection provides freshness: it makes the Evidence usable only on the connection it was produced for, so Evidence produced once cannot be replayed on a later connection. This is the same binding required to protect against relay. Connection binding: Workload identity and connection binding are separate properties. A binding between an attested workload and a TLS authentication key establishes that the key belongs to the attested workload. It does not by itself establish that the attestation Evidence applies to the particular TLS connection. To protect against relay, the attestation Evidence will have to be bound to the TLS connection. The mechanism for that binding is defined by the solution documents. Siloed appraisal and workload authorization: In Option B, evaluating identity certificates and platform Evidence independently can allow valid credentials to be hosted in an unauthorized Target Environment. Connection binding proves the private key resides in an authentic Target environment, but not that the environment is authorized for that specific workload identity. Where this assurance is required, the Relying Party's Appraisal Policy needs to evaluate the identity and platform measurements jointly, requiring the reported measurements to be authorized for the asserted identity.

References Normative References 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. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. Informative 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 Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. 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] Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates. Nokia University of the Bundeswehr Munich Linaro Arm Limited Fraunhofer SIT This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Cryptic Forest Software Siemens Fraunhofer SIT Independent Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. Intuit Arm Limited Arm Limited Linaro Nokia The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a TLS extension that enables the negotiation and binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. This extension has been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. TU Dresden Linaro Nokia Intuit University of the Bundeswehr Munich Arm Limited This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. The Linux Kernel documentation n.d. Amazon Web Services n.d. Amazon Web Services n.d. Amazon Web Services n.d. Google Cloud n.d. Google Cloud n.d. Google Cloud n.d. Microsoft n.d. Microsoft n.d. Microsoft n.d. Microsoft n.d. Google Cloud n.d. Microsoft n.d.

Acknowledgments The authors would like to thank the participants of the SEAT and RATS working groups for the discussions that helped shape this document.