Workload Identity Options for Attested TLS in Confidential Computing
draft-reddy-seat-cc-workload-identity-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Nathanael Ritz , Yaron Sheffer , Ionuț Mihalcea | ||
| Last updated | 2026-10-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reddy-seat-cc-workload-identity-00
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, <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
9.2. Informative References
[AWS-KMS-NITRO]
Amazon Web Services, "Cryptographic attestation for AWS
Nitro Enclaves", n.d.,
<https://docs.aws.amazon.com/kms/latest/developerguide/
services-nitro-enclaves.html>.
[AWS-NITRO-CONCEPTS]
Amazon Web Services, "AWS Nitro Enclaves concepts", n.d.,
<https://docs.aws.amazon.com/enclaves/latest/user/nitro-
enclave-concepts.html>.
[AWS-NITRO-VALIDATE]
Amazon Web Services, "Validating the attestation document
and the AWS Nitro Attestation PKI", n.d.,
<https://docs.aws.amazon.com/enclaves/latest/user/verify-
root.html>.
[AZ-ATTEST]
Microsoft, "Microsoft Azure Attestation overview", n.d.,
<https://learn.microsoft.com/en-us/azure/attestation/
overview>.
[AZ-ATTEST-CONCEPTS]
Microsoft, "Azure Attestation basic concepts", n.d.,
<https://learn.microsoft.com/en-us/azure/attestation/
basic-concepts>.
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., <https://learn.microsoft.com/en-us/azure/
confidential-computing/guest-attestation-confidential-
virtual-machines-design>.
[AZ-CVM-GA]
Microsoft, "Guest attestation for confidential VMs", n.d.,
<https://learn.microsoft.com/en-us/azure/confidential-
computing/guest-attestation-confidential-vms>.
[AZ-SKR] Microsoft, "Secure Key Release with Azure Key Vault and
confidential VMs", n.d., <https://learn.microsoft.com/en-
us/azure/confidential-computing/skr-flow-confidential-vm-
sev-snp>.
[GCP-ATTEST]
Google Cloud, "Google Cloud Attestation", n.d.,
<https://docs.cloud.google.com/confidential-
computing/docs/attestation>.
[GCP-CS-OVERVIEW]
Google Cloud, "Confidential Space overview", n.d.,
<https://docs.cloud.google.com/confidential-computing/
confidential-space/docs/confidential-space-overview>.
[GCP-CS-SEC]
Google Cloud, "Confidential Space security overview",
n.d., <https://docs.cloud.google.com/docs/security/
confidential-space>.
[GCP-CVM-ATTEST]
Google Cloud, "Confidential VM attestation", n.d.,
<https://docs.cloud.google.com/confidential-computing/
confidential-vm/docs/attestation>.
[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,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
early-attestation-08>.
[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,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
expat-04>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-csr-attestation-32>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
identifier-04>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-reddy-rats-
key-binding-02>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>.
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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[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,
<https://www.rfc-editor.org/rfc/rfc8739>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
[SNP-TDX-TM]
The Linux Kernel documentation, "Confidential Computing
Threat Model and its Security Objectives (AMD SEV-SNP and
Intel TDX)", n.d., <https://docs.kernel.org/security/snp-
tdx-threat-model.html>.
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]