Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Internet-Draft	Attestation in TLS/DTLS	November 2026
Sheffer, et al.	Expires 5 May 2027	[Page]

Abstract

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 of remote attestation and binds the TLS authentication key to the attested platform state. 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.¶

4. Attestation Extension

As typical with new features in TLS, the client indicates support for the new extension in the ClientHello message. The newly introduced extension allows attestation Evidence or Attestation Results to be exchanged. Freshness of both exchanged Evidence or Attestation Results is provided through an Attestation Binder mechanism (see Section 5.1).¶

When the extension is successfully negotiated, attestation Evidence or Attestation Results are conveyed in a remoteAttestation extension (see Section 4.1). The CMW payload in the Attestation extension contains the attestation Evidence or Attestation Results encoded according to [RFC9999].¶

The attestation payload MUST contain assertions relating to the attester's TLS Identity Key (TIK-C for client attester, TIK-S for server attester), which associate the private key with the attestation information. The TEE's signature over the Evidence MUST include an attestation binder derived from the message transcript (see Section 5.1) and the attester's TLS identity public key, as specified in Section 4.1. In the Passport Model, the Verifier MUST include the binder it extracts from the Evidence in its signed Attestation Result.¶

The relying party can obtain and appraise the remote Attestation Results either directly from the Attestation extension (in the Passport Model), or by relaying the Evidence from the Attestation extension to the Verifier and receiving the Attestation Results. Subsequent verification of possession of the attested key in the CertificateVerify message remains unchanged from baseline TLS.¶

When using the Passport Model, the attester MUST obtain Attestation Results from its trusted Verifier for the current TLS handshake, after the ClientHello...ServerHello transcript checkpoint is available and before sending its Certificate message. These Results MUST be bound to both the TIK and the current TLS connection using the attestation binder. Attestation Results from a previous TLS handshake MUST NOT be presented in a subsequent handshake, even if their validity period has not expired. For Passport Model, the Attester-Verifier exchange happens before the attester can send its Certificate message; timeout and failure handling are specified in Section 7.5.¶

This protocol supports both monolithic and split implementations. In a monolithic implementation, the TLS stack is completely embedded within the TEE. In a split implementation, the TLS stack is located outside the TEE, but any private keys (and in particular, the TIK) only exist within the TEE. In order to support both options, only the TIK's identity and public component, plus a short generated binder for either model, are passed between the Client or Server TLS stack and its Attestation Service. While the two types of implementations offer identical functionality, their security properties often differ, see Section 8.6 for more details.¶

4.1. Remote Attestation Extension

As defined in Section 4.5.1 of [RFC9846], the TLS Certificate message contains a certificate_list, which is a sequence of CertificateEntry structures.¶

When attestation is negotiated via the extension defined in this document, the remoteAttestation extension defined in this document MUST appear only in the first CertificateEntry of the Certificate message and applies exclusively to the end-entity certificate.¶

The extension MUST NOT appear in any other CertificateEntry.¶

If the remoteAttestation extension is received in any other position, the receiver MUST abort the handshake with a fatal illegal_parameter alert.¶

This message carries a CMW (Conceptual Message Wrapper) payload as defined in [RFC9999].¶

The remoteAttestation extension structure is defined in Figure 1. As per Section 4.3 of [RFC9846], a single extension is used across the entire handshake. The extension is used in ClientHello, EncryptedExtensions, and CertificateRequest messages for protocol negotiation (see Section 6). The extension is used in Certificate messages for carrying attestation credentials.¶

    enum { CONTENT_FORMAT(0), MEDIA_TYPE(1) } typeEncoding;

    struct {
        typeEncoding type_encoding;
        select (EvidenceType.type_encoding) {
            case CONTENT_FORMAT: uint16 content_format;
            case MEDIA_TYPE: opaque media_type<0..2^16-1>;
        };
    } EvidenceType;

    struct {
        opaque verifier_identity<0..2^16-1>;
    } VerifierIdentityType;

    enum { evidence(0), result(1), (255) } AttestationMechanism;

    struct {
        AttestationMechanism mechanism;
        select (mechanism) {
            case evidence: EvidenceType;
            case result:   VerifierIdentityType;
        } argument;
    } AttestationScheme;

    struct {
        select (Handshake.msg_type) {
            case client_hello:
                AttestationScheme server_attester_schemes<0..2^16-1>;

                AttestationScheme client_attester_schemes<0..2^16-1>;

            case encrypted_extensions:
                AttestationScheme chosen_server_scheme;

            case certificate_request:
                AttestationScheme chosen_client_scheme;

            case certificate:
                opaque cmw_payload<1..2^24-1>;
        };
    } remoteAttestation;

Figure 1: TLS Extension Structure for Remote Attestation negotiation.

The cmw_payload field contains a CMW structure as defined in [RFC9999]. Both JSON and CBOR serializations are allowed in CMW, with the emitter choosing which serialization to use.¶

The CMW payload MUST contain attestation Evidence (in Background Check Model) or Attestation Results (in Passport Model) that binds the TLS Identity Key (TIK) to the platform and workload state. In the Background Check Model, the TEE's signature over the Evidence within the CMW MUST include a binder ensuring that the Evidence is associated with this particular TLS connection, as well as the attester's TLS identity public key (TIK-C for client attester, TIK-S for server attester). In the Passport Model, the Verifier-signed Attestation Results MUST identify the attested TIK public key (TIK-C or TIK-S) and MUST include the attestation binder from the appraised, TEE-signed Evidence.¶

NOTE: A new claim, `eat_transport_identity_key`, is being added to EAT Attestation Result (EAR, defined in draft-ietf-rats-ear) with the goal of supporting attested TLS as a use-case. This claim would carry the required information to allow Relying Parties to identify an attested public key.¶

The TIK binding ensures that the attested key is the one used in the TLS handshake. In both models, the binder additionally provides freshness through derivation from both peers' randomness. See Section 5.1 for details.¶

5. Use of Attestation in the TLS Handshake

For both the Passport Model (described in Section 5.1 of [RFC9334]) and Background Check Model (described in Section 5.2 of [RFC9334]) the following modes of operation are allowed when used with TLS, namely:¶

TLS client is the attester,¶
TLS server is the attester, and¶
TLS client and server mutually attest towards each other.¶

As noted, each peer's Evidence or Attestation Results are carried in the remoteAttestation extension within that peer's Certificate message. This section describes how Evidence and Attestation Results are bound to the TLS handshake and the TIK, and how each is verified by the recipient.¶

5.1. Cryptographic Operations

The cryptographic operations defined in this section bind attestation Evidence and Attestation Results to a specific TLS handshake. This binding prevents replay and relay of attestation credentials across different TLS connections, and ensures that the attestation presented during a handshake corresponds to the authenticated TLS session in which it is conveyed.¶

The attestation Evidence is generated by a TEE and signed using an attestation key. In both models, Attestation Results are signed by the Verifier that appraises the Evidence. In the Passport Model, the Verifier extracts the binder from the appraised Evidence as a Verifier-added claim and includes it in the signed Attestation Results.¶

The attestation binder is provided by the TLS stack and serves as a nonce that ensures freshness and binding to a specific TLS handshake, as well as binding to the attester's TLS public key.¶

5.1.1. Attestation Binder Definition

The attestation binder is computed using primitives defined in Sections 4.1 and 7.1 of [RFC9846].¶

During the initial handshake, both peers derive a common cryptographic value (the attestation base) from the same transcript checkpoint through ServerHello. For reattestation, both peers use the updated EKU transcript as specified in Section 5.4.¶

For the initial handshake, the transcript MUST be computed as Transcript-Hash through ServerHello, as defined in Section 4.1 of [RFC9846]. When the handshake includes a HelloRetryRequest, the first ClientHello is not hashed as sent; the transcript uses the synthetic message_hash message specified in that section instead.¶

The client and server each have a tailored binder derived from the attestation base, which they can use to bind their Evidence or Attestation Results. Both peers are then also able to derive each-other's binder in order to appraise the Attestation Results. The peer-specific binder mixes in the public part of that peer's authentication key.¶

attest_base = HKDF-Expand-Label(0, "attestation base",
                    Transcript-Hash(ClientHello...ServerHello), Hash.length)

c_attest_binder = HKDF-Expand-Label(attest_base, "attestation",
                                    Hash(TLS_Client_Public_Key), Hash.length)
s_attest_binder = HKDF-Expand-Label(attest_base, "attestation",
                                    Hash(TLS_Server_Public_Key), Hash.length)

TLS_Client_Public_Key and TLS_Server_Public_Key denote the DER-encoded SubjectPublicKeyInfo of the peer's end-entity certificate. Hash is the cipher suite hash function for the handshake (Section 7.1 of [RFC9846]).¶

We note that HKDF-Expand-Label is used to produce binding values rather than keying material. HKDF-Extract is not invoked, as there is no input key material to combine. The "0" parameter denotes a byte string of Hash.length zeroes.¶

HKDF-Expand-Label is defined in Section 7.1 of [RFC9846], which builds on the HKDF construction [RFC5869]; its use here does not modify the TLS protocol or the TLS key schedule.¶

5.1.2. Verification

Upon receipt of a remoteAttestation extension carrying Evidence or Attestation Results, the peer MUST compute the attestation binder using the handshake transcript and the public key in the peer's TLS end-entity certificate, as defined in Section 5.1.1.¶

If the peer's Evidence or Attestation Result is rejected (missing or mismatched binder, expired Results, failed appraisal, or malformed CMW), the receiver MUST send an attestation_failed fatal alert and abort the handshake (see Section 10.2).¶

For Evidence, depending on the architecture (see also Section 5.3), either the peer verifies the binder or else it delegates this responsibility to an external Verifier.¶

In the former case, the peer MUST compare the computed binder value to the attestation binder included in the signed Evidence. If the values do not match, the peer MUST treat the attestation as invalid.¶
In the latter case, the RP MUST convey the binder to the Verifier. The Verifier MUST appraise that the conveyed binder is identical to the one that was signed in the Evidence. If appraisal fails, the receiver MUST treat the attestation as invalid.¶

For Attestation Results, the Relying Party MUST verify the Verifier's signature and the Results against its local policy, including the Results' freshness and the Verifier's identity. It MUST check that the TIK public key identified by the signed Results matches the public key in the peer's TLS end-entity certificate. The Relying Party MUST compare the computed binder with the binder included in the Verifier-signed Attestation Results. A missing binder or a mismatch MUST cause the attestation to be considered invalid. If any of these checks fails, the Relying Party MUST abort the connection with a fatal attestation_failed alert TLS CertificateVerify proves possession of the matching TIK in this handshake.¶

The Relying Party MUST reject Attestation Results whose validity period has expired, even when the binder and TIK match the current connection. This requirement applies both to Results presented by the attester in the Passport Model and to Results obtained from a Verifier in the Background Check Model, during both the initial handshake and reattestation.¶

TODO: define a way to transport the binder to a remote Verifier. Possibly as a (new) conceptual message (CM) within a collection. This would provide the Verifier whatever information it cannot compute on its own, while not forcing the TLS stack to parse the Evidence. The same conveyance is needed when the Evidence is encrypted to the Verifier and the RP cannot read it (see {{attcreds-privacy}}).¶

5.1.3. Security Properties

Binding attestation Evidence and Attestation Results to the TLS handshake transcript hash provides the following security properties:¶

Replay protection: Evidence or Attestation Results generated for a previous handshake cannot be reused in a later handshake.¶
Relay protection: Evidence or Attestation Results obtained from one TLS connection cannot be successfully presented in a different TLS connection, even in the presence of a MiTM attacker.¶

In the Passport Model, the Verifier preserves the binder from the appraised Evidence in its signed Attestation Results. The Relying Party checks this binder against the current handshake as well as checking the signed TIK binding against the TLS certificate. Because of this check, results from another connection would be rejected even when that connection used the same TIK and the Results have not expired.¶

In typical deployments where the TLS handshake executes outside the TEE, a compromised host can execute the TLS handshake in the rich operating system and use the TEE as a signing oracle by presenting the attestation binder value to obtain valid-looking attestation Evidence.¶

However an endorsed TEE (one that is operating as required by this protocol) is required to verify the binder against the TLS public key associated with the private key that it holds. This verification, in conjunction with the TEE's endorsement being appraised, ensures that relay attacks are prevented.¶

The attestation binder prevents replay of Evidence across TLS connections. The binding to the TLS identity key ensures that Evidence produced by one endpoint cannot be replayed in a TLS connection involving a different endpoint, as the verifier checks that the binder matches the public key presented in the current TLS connection. The additional binding to the transcript through ClientHello and ServerHello ensures that Evidence cannot be replayed across TLS connections, as ClientHello.random and ServerHello.random are independently generated by each peer for every TLS connection.¶

5.2. Binding the TIK to the TEE

This specification assumes that the TIK private key corresponding to the end-entity certificate used in the TLS handshake is generated inside a TEE and never leaves it. A platform could instead generate the TIK private key outside the TEE and compute the CertificateVerify signature using that external key. A relying party cannot detect this attack unless additional safeguards are in place.¶

This risk is particularly relevant in split deployments, where the TLS stack does not reside inside the TEE. In such architectures, attesting the TEE alone does not prove that the TIK private key used by the TLS endpoint was generated, is stored, or is controlled by the TEE.¶

To address this, the signed Evidence MUST include an Attestation Binder generated using the hash of the TIK public key (TIK_pub_hash) (see Section 5.1).¶

For Evidence, the Relying Party MUST compute the hash of the TIK public key extracted from the TLS end-entity certificate using the same hash algorithm and verify that it matches the TIK_pub_hash included in the Evidence. Successful verification binds the attestation Evidence to the TLS identity used for authentication. This verification is performed by the Relying Party, as the Verifier may not be co-located with the Relying Party and may not have access to the TLS handshake or the TLS end-entity certificate, consistent with the RATS architecture. Alternatively, in deployments where the Verifier is not co-located with the Relying Party, the Relying Party MAY supply the Verifier with the hash of the TIK public key. The Verifier then compares this value with the TIK public key hash included in the Evidence. If the values do not match, the attestation MUST be considered invalid.¶

For Attestation Results, the Verifier MUST include the attested TIK public key or its hash among the signed claims. The Relying Party MUST compare this claim with the public key in the TLS end-entity certificate, hashing the latter with the algorithm identified by the Results when needed. A mismatch MUST cause the attestation to be considered invalid. The Relying Party MUST also verify the connection-specific binder as specified in Section 5.1; matching the TIK alone is insufficient.¶

Without this binding, a non-Target-Environment TLS endpoint can obtain Evidence from a separate TLS endpoint that runs inside a Target Environment and relay that Evidence to the relying party while executing the TLS handshake itself. If the Evidence only attests that a TLS stack is running in a Target Environment, the relying party cannot determine whether the attested TLS stack is the one that actually performed the handshake. Binding the Evidence to the TIK public key prevents this relay attack.¶

The proposed binding ensures that the relying party does not establish a TLS session with a TLS endpoint whose TIK is not generated and controlled by the TEE. It does not - in and of itself - ensure security of the TLS stack when the stack is outside the TEE, and see Section 8.6 for a further discussion.¶

5.3. The TLS Stack's Interface to the TEE

When the TEE signs Evidence for either model, it binds the Evidence to the TLS Identity public key and the TLS connection. TEE implementations differ, and some only allow a single user-provided challenge value to be added to the Evidence with no associated checks.¶

Architecturally we propose to add a thin shim between the traditional TLS stack and the TEE as shown in Figure 2. Implementations will choose whether to incorporate the shim into the TEE (making for a "smarter" TEE and better protection for the remote attestation protocol), or in case of a legacy TEE that cannot be modified, the shim can be added to the TLS stack.¶

Figure 2: TLS Stack Interface with the TEE

The TEE returns signed Evidence to the shim in both models. In the Passport Model, the shim also obtains Verifier-signed Attestation Results from that Evidence before returning the CMW to the TLS stack. This exchange with the Verifier is omitted from the diagram.¶

We adopt a defense-in-depth approach:¶

Separate attesting applications within the same TEE SHOULD NOT be capable of impersonating each other via Evidence or Attestation Results. Therefore, if multiple applications are expected to use attestation credentials, Evidence generation APIs SHOULD reflect identifiers for the calling contexts into the generated Evidence. These identifiers can be reflected as separate claims in the Evidence, or can be measured as part of more generic claims. The Verifier SHOULD preserve the distinction between these calling contexts in its Attestation Results. A Relying Party SHOULD be capable of differentiating between the attesting applications based on their credentials.¶
The RP SHOULD NOT base its trust decision only on the Attester's trust root. It SHOULD also ensure that the entire attested software stack is endorsed.¶
The TEE itself, when possible, SHOULD generate the attestation secret by running the derivation operations defined in Section 5.1, and, if it holds the TIK, SHOULD validate the public key. The attestation secret can be generated by the TEE only if TLS is running inside the TEE.¶
As shown in the diagram, the TEE itself as well as the TLS stack and the shim SHOULD all be measured and reported as part of the platform's remote attestation.¶

5.4. Reattestation

Attestation Evidence or Attestation Results may become stale over time. For long-lived TLS connections, a relying party may need fresh Evidence or Attestation Results to reassess the trustworthiness of the peer. In both models, each completed EKU exchange triggers reattestation bound to the updated transcript.¶

Similarly to the initial handshake, Early Attestation implements reattestation at the TLS layer, using Extended Key Update (EKU) [I-D.ietf-tls-extended-key-update]. This document defines a new ExtendedKeyUpdate subtype, attestation_update, which carries a cmw_payload as defined in Section 4.1. Reattestation is available only when EKU is also negotiated and supports both the Background Check Model and the Passport Model.¶

Either peer MAY initiate EKU per its own policy. Each completed EKU exchange triggers reattestation: a peer that attested in the handshake MUST send attestation_update, using the scheme chosen in the handshake. A peer that negotiated an evidence scheme MUST send fresh Evidence; a peer that negotiated a result scheme MUST obtain and send fresh Verifier-signed Attestation Results. In both cases, the credential MUST include the new binder derived below. A peer that did not attest during the handshake MUST NOT send attestation_update.¶

Each peer waits for attestation_update only from a peer that attested in the handshake. If both peers attested, the two attestation_update messages are independent; no order between them is required.¶

This document extends ExtendedKeyUpdateType and ExtendedKeyUpdate (Section 4 of [I-D.ietf-tls-extended-key-update]) as follows:¶

enum {
    attestation_update(TBD4),
    (255)
} ExtendedKeyUpdateType;

struct {
    ExtendedKeyUpdateType eku_type;
    select (eku_type) {
        case attestation_update: {
            opaque cmw_payload<1..2^24-1>;
        }
    };
} ExtendedKeyUpdate;

Initiator                                        Responder

[EKU(key_update_request)]N      -------->
                                <--------  [EKU(key_update_response)]N
[EKU(key_update_finish)]N       -------->
                 (EKU complete, N+1 in use)
[EKU(attestation_update)]N+1*   -------->
                                <--------  [EKU(attestation_update)]N+1*

* Sent only by a peer that attested in the handshake,
  using the scheme negotiated for that peer.

Figure 3: Reattestation after EKU (DTLS ACKs omitted)

The attester sends attestation_update after the EKU exchange completes (Sections 5 and 6 of [I-D.ietf-tls-extended-key-update]), under the N+1 application traffic secrets, not the old keys (Section 7 of [I-D.ietf-tls-extended-key-update]). After the EKU exchange completes, a relying party expects attestation_update from each peer that attested in the handshake, whether using an evidence or a result scheme. Such a relying party MUST set a bounded timeout, per local policy, for receiving attestation_update. On expiry, it MUST abort with a fatal attestation_required alert. If appraisal fails, it aborts with a fatal attestation_failed alert, as in Section 5.1. No message is sent on success.¶

A peer that receives attestation_update from a peer that did not attest in the handshake, or before the EKU exchange completes, MUST abort with an unexpected_message alert.¶

Reattestation does not block application data while the previous successful appraisal remains valid. Until the relying party completes appraisal of attestation_update or aborts with an alert, it continues to rely on that previous outcome. It MUST NOT extend the validity of the previous appraisal because reattestation is pending.¶

In the Passport Model, an attester waiting for a slow Verifier MUST defer attestation_update until fresh Results for the current EKU generation are available. It MUST apply the bounded timeout and failure handling in Section 7.5. It MUST NOT send an empty update, reuse earlier Results, or fall back to an evidence scheme. Waiting for the Verifier does not suspend the relying party's timeout or refresh its previous appraisal. If the connection closes while the attester is waiting, the attester MUST discard any Results subsequently returned for that connection.¶

While reattestation is in progress, a peer MUST NOT initiate another EKU exchange or post-handshake client authentication (Section 4.7.2 of [RFC9846]). Reattestation completes at the attester when it sends attestation_update (TLS) or receives the ACK for it (DTLS), and at the relying party when appraisal completes. If both peers are attesters, reattestation completes after both independent exchanges have completed. A relying party that receives key_update_request or CertificateRequest before its appraisal completes defers its response until appraisal completes (Sections 5 and 6 of [I-D.ietf-tls-extended-key-update], Section 4.7.2 of [RFC9846]). An attester that receives key_update_request or CertificateRequest before it has sent attestation_update MUST abort with an unexpected_message alert.¶

For both Evidence and Attestation Results, the binder MUST be derived as in Section 5.1, with Transcript-Hash(ClientHello...ServerHello) replaced by transcript_hash_N+1 (Section 7 of [I-D.ietf-tls-extended-key-update]):¶

attest_base_N+1 = HKDF-Expand-Label(0, "attestation base",
                      transcript_hash_N+1, Hash.length)

c_attest_binder_N+1 = HKDF-Expand-Label(attest_base_N+1, "attestation",
                      Hash(TLS_Client_Public_Key), Hash.length)
s_attest_binder_N+1 = HKDF-Expand-Label(attest_base_N+1, "attestation",
                      Hash(TLS_Server_Public_Key), Hash.length)

transcript_hash_N+1 covers the initial handshake, all prior EKU exchanges, and the key shares of the current exchange. Each reattestation therefore uses a fresh binder.¶

After the EKU exchange completes, the attester MUST generate fresh Evidence containing the new binder. In the Passport Model, it MUST submit this Evidence to the Verifier and obtain fresh Attestation Results that include the same binder and the attested TIK. Results from the initial handshake or an earlier EKU generation MUST NOT be used for this reattestation.¶

The Relying Party MUST apply the verification and appraisal checks in Section 5.1 to the received Evidence or Attestation Results, using the binder derived from transcript_hash_N+1 and the peer's TIK from the TLS end-entity certificate. A missing binder or a mismatch MUST cause rejection with a fatal attestation_failed alert. Successful appraisal of the fresh Evidence or Results replaces the previous appraisal outcome; completing EKU alone does not extend the validity of an earlier appraisal.¶

5.5. Session Resumption

This specification targets long-lived TLS connections that use post-handshake mechanisms, in particular Extended Key Update and reattestation (Section 5.4). Session resumption (including early data) is not supported with this protocol: [I-D.ietf-tls-extended-key-update] requires endpoints that enable EKU to disable resumption using PSKs established via NewSessionTicket, and reattestation depends on EKU.¶

Endpoints that negotiate remoteAttestation as defined in this document MUST NOT offer or accept session resumption for the connection. Fresh attestation on a new connection requires a full handshake as in Figure 4. Establishing an initial connection with a pre-shared key alone, without that certificate-based attestation exchange, is not supported.¶

7. TLS Client and Server Handshake Behavior

The high-level message exchange in Figure 4 shows the remoteAttestation extension added to the ClientHello, the EncryptedExtensions, the CertificateRequest, and the Certificate messages.¶

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     | + pre_shared_key*
     v + remoteAttestation*
     -------->
                                                  ServerHello ^ Key
                                                 + key_share* | Exch
                                            + pre_shared_key* v
                                        {EncryptedExtensions} ^ Server
                                         + remoteAttestation* | Params
                                        {CertificateRequest*} |
                                         + remoteAttestation* v
                                               {Certificate*} ^
                                        + remoteAttestation*  |
                                         {CertificateVerify*} | Auth
                                                   {Finished} v
                               <--------  [Application Data*]
     ^ {Certificate*}
     | + remoteAttestation*
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

Figure 4: Early Attestation Handshake Overview

7.1. Client Hello

The remoteAttestation extension defined in Section 6 enables the two peers to use either the Background Check Model or the Passport Model for remote attestation.¶

To indicate support for either Evidence (for Background Check) or Attestation Results (for Passport), the client includes schemes with either evidence or result as the AttestationMechanism in the ClientHello extension. For Evidence, the scheme indicates the expected Evidence type. For Attestation Results, the scheme indicates the identity of the Verifier from which results can be relayed. In both cases, whether the scheme is sent as server_attester_schemes or client_attester_schemes indicates which peer is expected to produce the attestation credential.¶

The remoteAttestation extension carries a list of supported schemes, sorted by preference. If the client only supports one attestation credential type, it is a list containing a single element.¶

The client MUST omit schemes from the client_attester_schemes field in the extension if it cannot respond to a request from the server to present an attestation credential of the proposed type, or if the client is not configured to use the proposed scheme with the given server. If the client chooses to include client_attester_schemes, it MUST be capable of authenticating itself with a certificate.¶

For the Background Check Model, the client MUST omit Evidence types from the server_attester_schemes field in the extension if it is not able to pass the Evidence type to a Verifier.¶

7.2. Server Hello

If the server receives a ClientHello that contains the remoteAttestation extension, then three outcomes are possible:¶

The server does not support the extension defined in this document. In this case, the server returns the EncryptedExtensions without the remoteAttestation extension.¶
The server supports the extension defined in this document, but it does not have any remote attestation scheme in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_attestation_schemes".¶
The server supports the extension defined in this document and has at least one remote attestation scheme in common with the client. In this case, the processing rules described below are followed.¶

The remoteAttestation extension in the ClientHello indicates the attestation schemes for both peers to act as relying parties. For schemes conveyed under server_attester_schemes the server is expected to act as an attester, while the client is the relying party. For schemes conveyed under client_attester_schemes the server is expected to act as a relying party, while the client is the attester.¶

If the server chooses to attest itself, it MUST select one of the schemes provided by the client in server_attester_schemes. The server MUST then also include the remoteAttestation extension in the EncryptedExtensions message, and MUST include the chosen attestation scheme in the chosen_server_scheme. The server MUST populate the Certificate message extension according to its chosen scheme. If the server has chosen an evidence scheme, the signed Evidence contained in the CMW payload MUST include an Attestation Binder as a nonce value (see Section 5.1) in the TEE's signature. If the server has chosen a result scheme, the Verifier-signed Attestation Results contained in the CMW payload MUST include the server's attestation binder from the appraised Evidence (see Section 5.1).¶

Both schemes selected for chosen_server_scheme and chosen_client_scheme MUST be selected from the schemes provided in the remoteAttestation extension sent in the ClientHello.¶

If both server_attester_schemes and client_attester_schemes are empty, or if the server does not want to proceed with remote attestation, the server MUST terminate the session as described above, with a fatal alert of type "unsupported_attestation_schemes".¶

7.3. Certificate Request

If the server chooses to request that the client attests itself, it MUST select one of the schemes provided by the client in client_attester_schemes. The server MUST then also send a CertificateRequest message that includes the remoteAttestation extension (see Figure 1), and MUST include the chosen attestation scheme in chosen_client_scheme.¶

7.4. Following Server Hello

Upon receipt of the EncryptedExtensions and potentially of the CertificateRequest messages, the client can verify that the server's choices are valid. The client MUST check that at least one remote attestation scheme was returned, and that the returned schemes were among the corresponding proposed lists. If the server has rejected that one peer act as an attester by not selecting a corresponding scheme, and the client's policy demands that the remote attestation take place, the client MUST terminate the session with a fatal alert of type "attestation_required".¶

If the server has selected a valid chosen_client_scheme, the client MUST populate the Certificate message extension according to that scheme. If the server has chosen an evidence scheme for the client, the signed Evidence contained in the CMW payload MUST include an Attestation Binder as a nonce value (see Section 5.1) in the TEE's signature. If the server has chosen a result scheme for the client, the Verifier-signed Attestation Results contained in the CMW payload MUST include the client's attestation binder from the appraised Evidence (see Section 5.1).¶

7.5. Verifier Availability

In the Passport Model, the attester cannot send its Certificate message until it has obtained connection-bound Attestation Results from the Verifier. The attester MUST set a bounded timeout, according to local policy, for this exchange. Retries MUST NOT extend this timeout or any overall handshake timeout. If the Verifier is unreachable or the timeout expires before Results are obtained, the attester MUST abort the connection with a fatal internal_error alert (Section 6.2 of [RFC9846]). It MUST NOT continue the handshake without the negotiated attestation credential, substitute Results from another handshake, or switch to a different attestation scheme.¶

The same timeout and failure handling apply when the attester obtains Results for reattestation, and when a Relying Party contacts a Verifier in the Background Check Model. A Verifier availability failure is distinct from rejection of Evidence or Results, which is reported with attestation_failed, and from failure to receive a required attestation_update, which is reported with attestation_required (see Section 5.4).¶

8. Security Considerations

8.1. Denial of Service Through Verifier Requests

In the Passport Model, an unauthenticated client can cause a server acting as an attester to generate Evidence and contact its Verifier by initiating a handshake that negotiates a result scheme. The server must obtain Results before sending its Certificate message, so the client need not authenticate or complete the handshake to trigger this work. Connection-bound Results cannot be cached for use in other handshakes. Repeated connection attempts can therefore exhaust resources at both the server and the Verifier, or incur costs for the server. Requesting client certificate authentication does not prevent this attack because it occurs later in the handshake.¶

Servers and Verifiers SHOULD rate-limit attestation requests and bound the number of concurrent requests and the resources retained for pending requests. Deployments SHOULD apply admission controls before starting expensive attestation work. The timeouts in Section 7.5 bound individual waits but do not by themselves prevent request flooding. Deployments also need to account for repeated EKU exchanges triggering Verifier work on established connections, including connections without client authentication, and for Background Check requests induced by peer-supplied Evidence.¶

8.2. Relay Resistance

A relay attack succeeds when Evidence produced in one TLS connection can be presented by a different party in another TLS connection. Preventing it requires that Evidence be bound to a value that is unique to the TLS connection in which it is conveyed, so that Evidence generated in any one connection cannot be replayed in any other.¶

This mechanism meets that requirement by binding Evidence to the handshake transcript checkpoint ClientHello...ServerHello (see Section 5.1), a value that is unique to each connection. The binding does not rely on the application traffic secrets, nor on any value exported from the completed handshake such as the Exported Keying Material (EKM; Section 7.5 of [RFC9846]). EKM is an equally valid per-connection anchor; the remainder of this section shows that binding to the transcript checkpoint and binding to EKM provide equivalent relay resistance.¶

The two approaches differ only in which connection-unique value the Evidence is anchored to:¶

A post-handshake binding anchors Evidence to EKM, a value that becomes available only after the handshake completes.¶
The mechanism in this document anchors Evidence to Transcript-Hash(ClientHello...ServerHello).¶

Both anchors are unique per connection. The transcript checkpoint commits to both peers' fresh ephemeral key-exchange contributions, that is, the client's and server's key_share entries in the transcript (whether (EC)DHE public keys or a PQC KEM public key and ciphertext), as well as ClientHello.random and ServerHello.random. After a HelloRetryRequest, these are the values from the updated ClientHello and the ServerHello, as included in Transcript-Hash (Section 4.1 of [RFC9846]).¶

Because each peer independently contributes fresh material, neither peer alone controls the transcript, and the resulting binder is unique to the specific connection (two-sided uniqueness).¶

The two constructions therefore offer equal relay resistance.¶

The relay resistance of this mechanism does not depend on the transcript being secret. It relies instead on the attestation binder, which is unique to the connection and bound to the attester's TLS identity key, being carried in Evidence signed by the TEE (see Section 5.1 and Section 5.2); the confidentiality of ClientHello and ServerHello is not required.¶

In the Passport Model, the Verifier appraises the TEE-signed Evidence and includes the same binder and attested TIK in its signed Attestation Results. The Relying Party verifies both against the current handshake. This preserves the connection binding through the Verifier and prevents replay or relay of Results across connections, including connections using the same TIK.¶

Although ClientHello and ServerHello are visible to an on-path observer, an eavesdropper cannot reuse them to complete a new TLS connection, as it does not know the ephemeral private keys behind the key shares they carry. Nor can the client or server reproduce an earlier transcript: each contributes fresh key-exchange material to every handshake, so every connection yields a different transcript, and therefore a different binder.¶

The rationale for anchoring to the transcript rather than to an exporter value is given in Appendix B.¶

8.2.1. Worked Example: Relay Attempt Under Handshake-Secret Compromise

The server holds a TLS authentication key (the TIK), certified by a CA. The client truststore has the CA and verifies the end-entity certificate chains to it. The client checks that the public key in the end-entity certificate matches the TIK and relies on CertificateVerify for proof of possession. Each handshake also uses a fresh ephemeral (EC)DHE key share, carried in ClientHello/ServerHello, from which the connection secrets are derived.¶

This example is deliberately generic; it will be updated in future revisions based on the outcome of confidential-computing-specific discussions.¶

Suppose an attacker obtains a connection's handshake secret (or the ephemeral private key from which it is derived). The attacker can then derive that connection's handshake traffic secrets and decrypt the handshake, including the Evidence carried in the encrypted Certificate message. This compromises the confidentiality of that single connection. It does not let the attacker replay the Evidence in a different TLS session: the Evidence is bound to this connection's ClientHello...ServerHello transcript and to the TIK, and any other TLS connection uses fresh key shares, yielding a different transcript and a different binder. The exposed Evidence therefore does not match any other connection and is rejected. Consistent with TLS 1.3 forward secrecy, the impact is confined to the compromised session. Figure 5 illustrates this case.¶

Legend:  CR = ClientHello.random    SR = ServerHello.random
         cks = client key_share     sks = server key_share
         T = Transcript-Hash(ClientHello...ServerHello)
         E = Evidence signed by the Attesting Environment, bound to T

   Client                     Server                        Attacker
      |                              |                            |
      |== Connection 1 : Client <-> Server =======================|
      |  CH_1 { CR_1, cks_1 } ------>|                            |
      |<----- SH_1 { SR_1, sks_1 }   |                            |
      |        T1 = Hash(CH_1..SH_1) |                            |
      |<----- {Certificate: E}       |                            |
      |        E bound to T1         |                            |
      |                              |   attacker has obtained    |
      |                              |   connection 1's handshake |
      |                              |   secret: decrypts conn 1  |
      |                              |   and reads Evidence E     |
      |                              |                            |
      |== Connection 2 : Client <-> Attacker (posing as server) ==|
      |  CH_2 { CR_2, cks_2 } ----------------------------------->|
      |     CR_2 != CR_1 , cks_2 != cks_1                         |
      |     (client contributes fresh values; attacker            |
      |      cannot control them)                                 |
      |                                                           |
      |<---------------------- SH_2 { SR_1, sks_1 }               |
      |     attacker replays connection 1's server values         |
      |     to try to reproduce T1                                |
      |<-------------------- {Certificate: replayed E (bound T1)} |
      |                                                           |
      |  T2 = Hash(CH_2..SH_2)                                    |
      |  CH_2 != CH_1  =>  T2 != T1                               |
      |  client computes binder over T2 ;                         |
      |  E is bound to T1  =>  binder mismatch                    |
      |                                                           |
      |<-------------------- >> attestation_failed <<             |
      |                        handshake aborted                  |
      |                                                           |

Figure 5: Even having read the Evidence from connection 1, the attacker cannot reproduce connection 1's transcript on connection 2: the client contributes fresh randomness and key share, so the binder does not match and the handshake is aborted

8.3. Key Substitution Resistance

A peer may hold an authentication private key that was generated and protected within an Attesting Environment, but has since been compromised via a side-channel attack and imported into a second Attesting Environment. Channel binding as defined in Section 8.2 does not prevent this, since it is not relay or replay of Evidence across connections, but Evidence from an Attesting Environment vouching for a key it did not generate.¶

Preventing this requires Evidence to assert that the TIK was generated within the Attesting Environment, has never existed outside it, and is non-exportable, not merely that it is currently protected. [I-D.reddy-rats-key-binding] defines this key-provenance property via the local and never-extractable key-attributes conveyed alongside the Subject Public Key, and it applies equally to intra-handshake and post-handshake attestation. These attributes are therefore only as trustworthy as that environment itself, as established by appraisal against applicable reference values and endorsements and by the trust anchor for the Attestation Key ([RFC9334]).¶

A summary of the security properties this mechanism provides is given in Appendix E.¶

8.4. Evidence Confidentiality After Compromise

The relay-resistance analysis in Section 8.2 shows that Evidence or Attestation Results exposed by a handshake-secret compromise cannot be relayed on a different connection. It says nothing about Evidence or Results sent later on that same connection.¶

Suppose an attacker obtains a connection's handshake secret, as in Section 8.2.1, and new Evidence or Attestation Results are subsequently carried on that same connection (see Section 5.4). If they are protected under a compromised handshake secret, the attacker decrypts them too.¶

Preventing this requires Post-Compromise Security (PCS): new Evidence or Attestation Results are sent only after the connection has moved to fresh traffic secrets, independent of the compromised one. [I-D.ietf-tls-extended-key-update] provides this via Extended Key Update (EKU). Reattestation (Section 5.4) sends new Evidence or Results only after EKU completes.¶

8.5. Reattestation Freshness

Each reattestation is bound to transcript_hash_N+1 of the EKU exchange that precedes it (see Section 5.4). Evidence or Attestation Results generated for the initial handshake or an earlier EKU generation do not match the current binder and MUST be rejected. In the Passport Model, the attester MUST obtain fresh Verifier-signed Results derived from fresh Evidence containing the new binder. The Relying Party MUST verify this binder and appraise the new Results, including their freshness, under its local policy. Completing EKU alone does not renew the validity of earlier Results.¶

8.6. Security Guarantees

We note that as a pure cryptographic protocol, attested TLS as-is only guarantees that the Identity Key is known by the TEE. A number of additional guarantees must be provided by the platform and/or the TLS stack, and the overall security level depends on their existence and quality of assurance:¶

The Identity Key is generated by the TEE.¶
The Identity Key is never exported or leaked outside the TEE.¶
The TLS protocol, whether implemented by the TEE or outside the TEE, is implemented correctly and (for example) does not leak any session key material.¶

These properties may be explicitly promised ("attested") by the platform, or they can be assured in other ways such as by providing source code, reproducible builds, formal verification etc. The exact mechanisms are out of scope of this document.¶

8.7. Freshness Guarantees

Evidence appraised at handshake time reflects the Target Environment's state at that moment. Cases that can cause that appraisal to go stale without the Relying Party being aware include:¶

The connection remains open and continues to carry data after the Target Environment's state has changed and no reattestation has occurred.¶
Some Claims describe configuration state that can change at runtime without a reboot. If the Attesting Environment does not re-collect such a Claim before each attestation, it keeps asserting a stale value even after reattestation.¶

The Relying Party cannot observe the Target Environment directly and so has no way to detect that its state has changed. A Relying Party that needs assurance about current state applies local policy for how long an appraisal remains acceptable. To avoid interruption, it initiates reattestation using the mechanism in Section 5.4 early enough for the Verifier exchange and appraisal to complete before the current appraisal ceases to be valid. Session resumption is not used to carry forward an appraisal to a new connection (see Section 5.5).¶

9. Privacy Considerations

In this section, we are assuming that the Attester is a TLS client, representing an individual person. We are concerned about the potential leakage of privacy sensitive information about that person, such as the correlation of different connections initiated by them.¶

In background-check mode, the Verifier not only has access to detailed information about the Attester's TCB through Evidence, but it also knows the exact time and the party with whom the secure channel establishment is attempted (i.e., the RP). The privacy implications are similar to online OCSP [RFC6960]. While the RP may trust the Verifier not to disclose any information it receives, the same cannot be assumed for the Attester, which generally has no prior relationship with the Verifier. Some ways to address this include:¶

Client-side redaction of privacy-sensitive evidence claims,¶
Using selective disclosure (e.g., SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] with EAT [I-D.ietf-rats-eat]),¶
Co-locating the Verifier role with the RP,¶
Utilizing privacy-preserving attestation schemes (e.g., DAA [I-D.ietf-rats-daa]), or¶
Utilizing Attesters manufactured with group identities (e.g., [FIDO-REQS]).¶

The latter two can hide attestation-specific identifiers from the RP, but do not by themselves prevent correlation through the TLS identity key (see Section 9.1).¶

In the Passport Model, the attester contacts the Verifier during each TLS handshake and each reattestation to obtain connection-bound Attestation Results. The Verifier therefore learns when handshakes and reattestations occur and how frequently the attester attempts them, although it need not learn the Relying Party's identity. This timing information can reveal activity patterns and can be correlated with other observations even when the disclosed Claims are minimized. This differs from OCSP "stapling", where a previously obtained response can be presented without contacting the responder during each handshake.¶

9.1. Linkability Through the TLS Identity Key

A stable TIK provides a correlation handle across connections. Relying Parties that observe the same public key in TLS end-entity certificates, and Verifiers that observe that key or its hash in Evidence, can link those connections. The TIK binding in Attestation Results also permits correlation by recipients of those Results. Fresh binders prevent replay but do not hide the TIK or make repeated use of it unlinkable. Selective disclosure of other Claims, DAA, or group attestation identities do not remove this correlation handle.¶

Where authentication policy permits, deployments concerned about linkability can use different TIKs and corresponding certificates for different Relying Parties or rotate them over time. Such deployments also need to consider other stable identifiers in certificates, Evidence, and Attestation Results; rotating the TIK alone does not guarantee unlinkability.¶

9.2. Server Attestation to Unauthenticated Clients

Due to the inherent asymmetry of the TLS handshake, when the Attester acts as the TLS server it produces attestation before the client has authenticated. As a result, any unauthenticated client that completes the handshake can read the Claims carried in the server's Evidence, without its own trustworthiness first being established by the server. The following considerations bound the impact of this exposure and offer mitigations.¶

Passport model with selective disclosure: In the Passport topology (Section 5.1 of [RFC9334]), the server presents a Verifier-signed Attestation Result instead of the Evidence, so the Evidence never reaches the client. As the signer, the Verifier can issue this result in selectively-disclosable form (SD-CWT [I-D.ietf-spice-sd-cwt] or SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt]), letting the server reveal only a subset of Claims. The disclosed Claims MUST include the attestation binder and the attested TIK public key or its hash, so that the client can perform the checks in Section 5.1.¶

See [I-D.ounsworth-rats-privacy-framework] for a broader treatment of privacy in the RATS context.¶

9.3. No Expectation of Privacy for Attestation Credentials

This document does not provide confidentiality or privacy for attestation credentials (i.e., Evidence and Attestation Results) with respect to the peer or to the network. Specifically:¶

Attestation credentials are carried in the handshake and are available to the peer, whether or not that peer has authenticated.¶
Attestation credentials are encrypted under the handshake traffic keys, so a passive on-path attacker cannot read them, unless the handshake secret is compromised (Section 8.4). An active on-path attacker, however, can obtain the server's credential, because a server attests before the client authenticates. It can either complete the handshake as a client, or interpose itself in the key exchange, in which case the handshake fails, but only after the credential has been exposed.¶
The same holds for reattestation (Section 5.4): the client need not authenticate to read the server's new attestation credential. An active attacker holding the current traffic keys can also read it by substituting the EKU key shares. The relying party detects this through the binder mismatch, but only after the credential has been exposed.¶

Authenticating the peer does not by itself solve the problem: an authenticated peer can still disclose the Claims it receives. Deployments should not assume Claims remain confidential, and should send only Claims that are acceptable to disclose to any party able to complete (or observe) the handshake.¶

Attesters that need to convey privacy-sensitive Claims should limit what the peer acting as RP learns. For Evidence, the extreme case is to hide all the Claims: the Evidence is encrypted to the Verifier, independently of the TLS handshake keys, using a public key that the Attester learns out of band (Section 4.2 of [I-D.ounsworth-rats-privacy-framework]). If the RP cannot read the Evidence, it cannot check the binder or the TIK hash itself: it conveys them to the Verifier, and checks that the signed Attestation Results carry the matching values. For Attestation Results, the Verifier can reveal only the Claims that the RP's policy needs, using minimization, selective disclosure, or zero-knowledge proofs (Sections 4.3, 4.4 and 4.5 of [I-D.ounsworth-rats-privacy-framework]). In both cases the protection can be applied in either direction. Encrypting to a key learned out of band requires work to define how such a key is published and bound to the intended recipient, which is out of scope for this document.¶

12. References

12.1. Normative References

[I-D.ietf-tls-extended-key-update]: Tschofenig, H., Tüxen, M., Reddy.K, T., Fries, S., and Y. Rosomakho, "Extended Key Update for Transport Layer Security (TLS) 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-extended-key-update-13, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-extended-key-update-13>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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>.
[RFC9999]: Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig, "Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026, <https://www.rfc-editor.org/rfc/rfc9999>.

12.2. Informative References

[DICE-Layering]: Trusted Computing Group, "DICE Layering Architecture Version 1.00 Revision 0.19", July 2020, <https://trustedcomputinggroup.org/resource/dice-layering-architecture/>.
[FIDO-REQS]: Peirani, B. and J. Verrept, "FIDO Authenticator Security Requirements", November 2021, <https://fidoalliance.org/specs/fido-security-requirements/>.
[I-D.acme-device-attest]: Weeks, B., Mallaya, G., and S. Rajala, "Automated Certificate Management Environment (ACME) Device Attestation Extension", Work in Progress, Internet-Draft, draft-acme-device-attest-08, 7 December 2025, <https://datatracker.ietf.org/doc/html/draft-acme-device-attest-08>.
[I-D.fossati-tls-attestation]: Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-10, 23 July 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-10>.
[I-D.ietf-oauth-selective-disclosure-jwt]: Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-22, 29 May 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-22>.
[I-D.ietf-rats-daa]: Birkholz, H., Newton, C., Chen, L., Giannetsos, T., and D. Thaler, "Direct Anonymous Attestation for the Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-daa-09, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-daa-09>.
[I-D.ietf-rats-eat]: Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-31, 6 September 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-31>.
[I-D.ietf-spice-sd-cwt]: Prorock, M., Steele, O., Birkholz, H., and R. Mahy, "Selective Disclosure CBOR Web Tokens (SD-CWT)", Work in Progress, Internet-Draft, draft-ietf-spice-sd-cwt-09, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-spice-sd-cwt-09>.
[I-D.ietf-teep-architecture]: Pei, M., Tschofenig, H., Thaler, D., and D. M. Wheeler, "Trusted Execution Environment Provisioning (TEEP) Architecture", Work in Progress, Internet-Draft, draft-ietf-teep-architecture-19, 24 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teep-architecture-19>.
[I-D.ounsworth-rats-privacy-framework]: Ounsworth, M., Tschofenig, H., and G. Lehmann, "Privacy Framework for Remote ATtestation procedureS", Work in Progress, Internet-Draft, draft-ounsworth-rats-privacy-framework-00, 18 June 2026, <https://datatracker.ietf.org/doc/html/draft-ounsworth-rats-privacy-framework-00>.
[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>.
[iana-content-formats]: IANA, "CoAP Content-Formats", <https://www.iana.org/assignments/core-parameters>.
[iana-media-types]: IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[RA-TLS]: Knauth, T., Steiner, M., Chakrabarti, S., Lei, L., Xing, C., and M. Vij, "Integrating Remote Attestation with Transport Layer Security", January 2018, <https://arxiv.org/abs/1801.05863>.
[RFC5869]: Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC6960]: Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/rfc/rfc6960>.
[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>.
[TLS-Ext-Registry]: IANA, "Transport Layer Security (TLS) Extensions", <https://www.iana.org/assignments/tls-extensiontype-values>.
[TLS-Param-Registry]: IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters>.
[TPM1.2]: Trusted Computing Group, "TPM Main Specification Level 2 Version 1.2, Revision 116", March 2011, <https://trustedcomputinggroup.org/resource/tpm-main-specification/>.
[TPM2.0]: Trusted Computing Group, "Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59", November 2019, <https://trustedcomputinggroup.org/resource/tpm-library-specification/>.

Appendix A. Document History

A.1. draft-fossati-seat-early-attestation-09

Added a Privacy Considerations subsection stating that there is no expectation of privacy for attestation credentials, and pointing to possible mitigations ([I-D.ounsworth-rats-privacy-framework]).¶
Bound Passport Model Attestation Results to the current handshake or EKU generation through the binder and attested TIK; clarified that the TEE signs Evidence and the Verifier signs Results.¶
Specified bounded Verifier waits and failure handling during the handshake and reattestation, and required rejection of expired Results.¶
Added considerations for unauthenticated clients triggering Verifier calls, disclosure of handshake timing to Verifiers, and linkability through a stable TIK.¶

A.2. draft-fossati-seat-early-attestation-08

Defined reattestation using Extended Key Update; removed other reattestation options. Appraisal failure is signalled with the attestation_failed alert.¶
Defined attestation_update wire format and message flow; reattestation does not block application data.¶
Added Appendix C.¶
Added Section 5.5: session resumption (and early data) not supported since it conflicts with EKU.¶

A.3. draft-fossati-seat-early-attestation-07

Added relay resistance and key substitution resistance into separate sections.¶
Added Section 8.4 (Post-Compromise Security via EKU).¶
Added Section 8.5.¶
Filled in Section 8.7 (was a TODO).¶
Added Section 6.1.¶
Adopted RFC 9334 terminology (Attesting Environment).¶
Scoped Section 6.1 to certificate-based auth; corrected to CertificateVerify.¶
Reframed Section 8.5.¶

A.4. draft-fossati-seat-early-attestation-06

Add a Security Considerations subsection on relay resistance, showing that transcript binding (ClientHello...ServerHello) and EKM binding offer equal relay resistance (see Section 8.2).¶
Expand Privacy Considerations to cover server attestation to unauthenticated clients, with mitigations (selective disclosure via SD-CWT, and the Passport model) (see Section 9.2).¶
Add an appendix with the design rationale for anchoring the binder to the transcript rather than to an exporter secret (see Appendix B).¶
Add an appendix noting that the ClientHello...ServerHello transcript can be computed using existing TLS-stack APIs, requiring no new interface (see Appendix D).¶
Clarify that HKDF-Expand-Label is the TLS 1.3 wrapper over HKDF-Expand ([RFC5869]) and that its use does not modify the TLS protocol or the key schedule.¶

A.5. draft-fossati-seat-early-attestation-05

Change extension model to a single remoteAttestation extension that covers all handshake messages which need extending.¶

A.6. draft-fossati-seat-early-attestation-04

Register the attestation_failed alert for Evidence verification failure after the attestation extension is processed; clarify roles of the three attestation-related alerts in Section 10.2.¶
Hash TLS public keys in HKDF-Expand-Label context so HkdfLabel stays within the 255-octet limit (post-quantum public keys); see Section 5.1.¶
Simplify attestation binder derivation to a single shared transcript checkpoint (ClientHello...ServerHello) for both peers (see Section 5.1).¶
Replaced Derive-Secret with HKDF-Expand-Label¶

A.7. draft-fossati-seat-early-attestation-03

Replace the Attestation message by an Attestation (certificate) extension, to bring this protocol within the requirements of the SEAT charter.¶
Define the attestation binder and decouple it from the TLS key schedule.¶
List multiple design options for reattestation.¶
Add architecture diagram for TLS stack interface with the TEE.¶
Add defense-in-depth guidance for measuring TEE, TLS stack, and shim.¶
Remove various outdated sections.¶

A.8. draft-fossati-seat-early-attestation-02

Fix typo in key schedule. Clarify (again) that this is only adding to the schedule, not modifying any existing key derivations.¶

A.9. draft-fossati-seat-early-attestation-01

(Submitted by mistake.)¶

A.10. draft-fossati-seat-early-attestation-00

Initial version of draft-fossati-seat-early-attestation.¶

This version represents a major architectural change from [I-D.fossati-tls-attestation]. The key changes include:¶

Removed certificate extension mechanism for conveying attestation Evidence¶
Introduced new Attestation handshake message for carrying CMW (Conceptual Message Wrapper) payload¶
Attestation message sent after CertificateVerify when server is attester¶
Attestation message sent after CertificateVerify message when client is attester¶
Removed use cases section¶
Removed KAT (Key Attestation Token) and PAT (Platform Attestation Token) references, using CMW directly¶
Nonces (client and server) and attester's TLS identity public key are included in TEE-signed Evidence/AttestationResults within CMW¶
CertificateVerify remains unchanged from baseline TLS (no proof-of-possession needed)¶
Added session resumption discussion (resumption MUST be rejected if reattestation is required per local policy)¶
Added reattestation¶