SEAT Working Group T. Reddy Internet-Draft Nokia Intended status: Informational N. Ritz Expires: 1 May 2027 Y. Sheffer Independent I. Mihalcea Arm 28 October 2026 Workload Identity Options for Attested TLS in Confidential Computing draft-reddy-seat-cc-workload-identity-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-reddy-seat-cc-workload- identity/. Discussion of this document takes place on the SEAT Working Group mailing list (mailto:seat@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/seat/. Subscribe at https://www.ietf.org/mailman/listinfo/seat/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Reddy, et al. Expires 1 May 2027 [Page 1] Internet-Draft CC Workload Identity for Attested TLS October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 4 3.1. AWS Nitro Enclaves . . . . . . . . . . . . . . . . . . . 4 3.2. GCP Confidential Space . . . . . . . . . . . . . . . . . 5 3.3. Azure Confidential Computing . . . . . . . . . . . . . . 6 3.4. Learnings . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Workload Identity . . . . . . . . . . . . . . . . . . . . . . 8 5. Option A: Attestation-Anchored Key . . . . . . . . . . . . . 9 6. Option B: PKI-Anchored Certificate with Workload Identity . . 9 7. Key Provenance . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Reddy, et al. Expires 1 May 2027 [Page 2] Internet-Draft CC Workload Identity for Attested TLS October 2026 1. 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 [RFC9846], 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. 2. Terminology This document uses the RATS terms defined in [RFC9334], 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 [RFC9711]. 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. Reddy, et al. Expires 1 May 2027 [Page 3] Internet-Draft CC Workload Identity for Attested TLS October 2026 * 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 [I-D.ietf-wimse-arch] (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 [RFC4949]. 3. 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. 3.1. 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 [AWS-NITRO-CONCEPTS]. 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 [AWS-NITRO-VALIDATE]. 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. Reddy, et al. Expires 1 May 2027 [Page 4] Internet-Draft CC Workload Identity for Attested TLS October 2026 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 [AWS-KMS-NITRO]. 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 [AWS-KMS-NITRO]. 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. 3.2. 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 [GCP-ATTEST] [GCP-CS-SEC]. 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 [GCP-CVM-ATTEST]: Reddy, et al. Expires 1 May 2027 [Page 5] Internet-Draft CC Workload Identity for Attested TLS October 2026 * 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 [GCP-CS-SEC]. 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 [GCP-CS-OVERVIEW]. 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. 3.3. 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 [AZ-ATTEST] [AZ-CVM-GA]. Typical use case: a Reddy, et al. Expires 1 May 2027 [Page 6] Internet-Draft CC Workload Identity for Attested TLS October 2026 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 [AZ-SKR]. Evidence and root of trust: The confidential workload runs in a confidential VM containing a virtual TPM. The Attester is layered [RFC9334]. 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 [AZ-ATTEST-DESIGN]. How the peer verifies: As in Section 3.2, 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 [AZ-ATTEST-CONCEPTS]. 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. 3.4. 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 [RFC9334], where the hardware Evidence carries the virtual TPM's Attestation Key. Reddy, et al. Expires 1 May 2027 [Page 7] Internet-Draft CC Workload Identity for Attested TLS October 2026 4. 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 Section 6. Where PKI is not available, the key is used without such an identifier Section 5. 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 Section 6. Similarly, when no certificate is available, the measurements must reflect this intent, as described in Section 5. How the Evidence or Attestation Result is carried in a TLS extension is discussed in the SEAT solution documents, see [I-D.fossati-seat-early-attestation] and [I-D.fossati-seat-expat]. Reddy, et al. Expires 1 May 2027 [Page 8] Internet-Draft CC Workload Identity for Attested TLS October 2026 5. 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) [RFC7250] or * As a self-signed X.509 certificate [RFC5280], 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 Section 7. 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 (Section 4). 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. 6. 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 [I-D.ietf-wimse-workload-creds] for the public key. The certificate binds the workload's identifier [I-D.ietf-wimse-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. Reddy, et al. Expires 1 May 2027 [Page 9] Internet-Draft CC Workload Identity for Attested TLS October 2026 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 Section 7. 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 [I-D.ietf-lamps-csr-attestation]. 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 Section 7 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 [RFC8739] 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 [SNP-TDX-TM], so a provider-hosted certification authority may still be relied upon. Reddy, et al. Expires 1 May 2027 [Page 10] Internet-Draft CC Workload Identity for Attested TLS October 2026 7. 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 Section 5 and Section 6 only ties the presented key to the key named in the Evidence. This assurance is provided by the key attestation defined in [I-D.reddy-rats-key-binding]. 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. 8. Security Considerations This document surveys deployment models and design options; it does not define a protocol. The following considerations apply. Reddy, et al. Expires 1 May 2027 [Page 11] Internet-Draft CC Workload Identity for Attested TLS October 2026 Key provenance: Both options depend on the key being generated in, and confined to, the attested environment (Section 7). Otherwise a key generated or held outside the environment could satisfy the checks in Section 5 and Section 6 without being protected by it. As noted in Section 7, 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. 9. References 9.1. Normative References Reddy, et al. Expires 1 May 2027 [Page 12] Internet-Draft CC Workload Identity for Attested TLS October 2026 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . 9.2. Informative References [AWS-KMS-NITRO] Amazon Web Services, "Cryptographic attestation for AWS Nitro Enclaves", n.d., . [AWS-NITRO-CONCEPTS] Amazon Web Services, "AWS Nitro Enclaves concepts", n.d., . [AWS-NITRO-VALIDATE] Amazon Web Services, "Validating the attestation document and the AWS Nitro Attestation PKI", n.d., . [AZ-ATTEST] Microsoft, "Microsoft Azure Attestation overview", n.d., . [AZ-ATTEST-CONCEPTS] Microsoft, "Azure Attestation basic concepts", n.d., . Reddy, et al. Expires 1 May 2027 [Page 13] Internet-Draft CC Workload Identity for Attested TLS October 2026 [AZ-ATTEST-DESIGN] Microsoft, "Confidential VM Guest Attestation Design Detail", n.d., . [AZ-CVM-GA] Microsoft, "Guest attestation for confidential VMs", n.d., . [AZ-SKR] Microsoft, "Secure Key Release with Azure Key Vault and confidential VMs", n.d., . [GCP-ATTEST] Google Cloud, "Google Cloud Attestation", n.d., . [GCP-CS-OVERVIEW] Google Cloud, "Confidential Space overview", n.d., . [GCP-CS-SEC] Google Cloud, "Confidential Space security overview", n.d., . [GCP-CVM-ATTEST] Google Cloud, "Confidential VM attestation", n.d., . [I-D.fossati-seat-early-attestation] Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and T. Reddy.K, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-seat-early- attestation-08, 14 October 2026, . [I-D.fossati-seat-expat] Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Reddy, et al. Expires 1 May 2027 [Page 14] Internet-Draft CC Workload Identity for Attested TLS October 2026 Exported Authenticators", Work in Progress, Internet- Draft, draft-fossati-seat-expat-04, 19 September 2026, . [I-D.ietf-lamps-csr-attestation] Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-32, 22 October 2026, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.ietf-wimse-identifier] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-04, 23 October 2026, . [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-02, 2 July 2026, . [I-D.reddy-rats-key-binding] Reddy.K, T., Tschofenig, H., Fossati, T., Mihalcea, I., and H. Birkholz, "Key Attestation for Entity Attestation Tokens (EAT)", Work in Progress, Internet-Draft, draft- reddy-rats-key-binding-02, 15 August 2026, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . Reddy, et al. Expires 1 May 2027 [Page 15] Internet-Draft CC Workload Identity for Attested TLS October 2026 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, March 2020, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [SNP-TDX-TM] The Linux Kernel documentation, "Confidential Computing Threat Model and its Security Objectives (AMD SEV-SNP and Intel TDX)", 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. Authors' Addresses Tirumaleswar Reddy Nokia Email: kondtir@gmail.com Nathanael Ritz Independent Email: ietf@nritz.com Yaron Sheffer Independent Email: yaronf.ietf@gmail.com Ionuț Mihalcea Arm Reddy, et al. Expires 1 May 2027 [Page 16] Internet-Draft CC Workload Identity for Attested TLS October 2026 Email: ionut.mihalcea@arm.com Reddy, et al. Expires 1 May 2027 [Page 17]