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

Internet-Draft	Attestation in TLS/DTLS	March 2026
Sheffer, et al.	Expires 2 September 2026	[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 series of TLS extensions that enable the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually.¶

1. Introduction

Remote Attestation (RA) [RFC9334] is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. This document describes a series of extensions to the TLS handshake that enable the binding of the TLS connection and its authentication key to a remote attestation session. This enables an attester, such as a confidential workload running in a Trusted Execution Environment (TEE) [I-D.ietf-teep-architecture], 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, in turn, allows for the implementation of authorization policies at the relying parties that are based on stronger security signals.¶

Given the variety of deployed and emerging attestation technologies (e.g., [TPM1.2], [TPM2.0], [I-D.ietf-rats-eat]) these extensions have been explicitly designed to be agnostic to the attestation formats. This is achieved by reusing the generic encapsulation defined in [I-D.ietf-rats-msg-wrap] for transporting Evidence and Attestation Results payloads in the attestation extension.¶

This specification provides both one-way (server-only) and mutual (client and server) authentication using traditional TLS authentication combined with attestation, and allows the attestation topologies at each peer to be independent of each other. The proposed design supports both background-check and passport topologies, as described in Sections 5.2 and 5.1 of [RFC9334]. This is detailed in Section 6.1 and Section 6.2.¶

The protocol we propose is implemented completely at the TLS level, resulting in several related advantages:¶

Implementation is within a single system component.¶
Security does not depend on application-level code, which tends to be less secure than widely shared infrastructure components.¶
It is easier to reason about the application's security, since the peers' identities and security postures are known as soon as the handshake completes and the TLS connection is established.¶
Application code does not need to change. At most, some configuration is needed, similar to the current use of certificate trust stores.¶

This document does not mandate any particular attestation technology.¶

3. Overview

The basic functional goal is to link the authenticated key exchange of TLS with an interleaved remote attestation session in such a way that the key used to sign the handshake can be proven to be residing within the boundaries of an attested TEE. The requirement is that the attester can provide Evidence containing the security status of both the signing key and the platform that is hosting it. The associated security goal is to obtain such binding so that no replay, relay or splicing from an adversary is possible.¶

The protocol's security relies on the verifiable binding between the TLS Identity Key, the specific TLS session and the platform state through attestation Evidence or Attestation Results conveyed in the CMW (Conceptual Message Wrapper) [I-D.ietf-rats-msg-wrap] payload.¶

3.1. Authentication vs. Attestation

The protocol combines platform attestation with X.509 certificate authentication.¶

Attestation when used alone is vulnerable to identity spoofing attacks, in particular when zero-day attacks exist for a class of hardware. (TODO: reference). Therefore it needs to be combined with traditional authentication, which in the case of TLS takes the form of CA-signed certificates.¶

We RECOMMEND that regular applications use authentication and attestation in tandem, to gain the full security guarantees of an authenticated TLS handshake (for the peer/peers being authenticated) as well as guarantees of platform integrity.¶

3.2. Integration into the TLS Handshake

The lightweight integration of attestation into the TLS handshake is designed to have minimal impact on the existing TLS security properties. The changes consist of:¶

Negotiation extensions: New TLS extensions are added to ClientHello and EncryptedExtensions messages to negotiate the use of attestation and indicate supported attestation formats and verifiers. A new Attestation extension is introduced to the Certificate message. This extension carries attestation Evidence or Attestation Results.¶
Independent key derivation: Binder derivation for attestation (see Section 5.1) is completely independent of the regular TLS key schedule. Attestation processing does not affect the standard TLS key derivation and security properties.¶

This minimal integration approach provides an intuitive explanation of why the addition of attestation does not adversely affect TLS security. The attestation components operate independently, leaving the core TLS handshake protocol and key derivation mechanisms unmodified. Nevertheless, formal validation of these security properties is still required.¶

4. Attestation Extensions

As typical with new features in TLS, the client indicates support for the new extension in the ClientHello message. The newly introduced extensions allow attestation Evidence or Attestation Results to be exchanged. Freshness of the exchanged Evidence is guaranteed through an Attestation Binder mechanism (see Section 5.1) when the Background Check Model is in use. In the Passport Model, freshness expectations are more relaxed and are governed by the lifetime of the signed Attestation Results.¶

When either the Evidence or the Attestation Results extension is successfully negotiated, attestation Evidence or Attestation Results are conveyed in an attestation extension (see Section 4.1). The CMW payload in the Attestation extension contains the attestation Evidence or Attestation Results encoded according to [I-D.ietf-rats-msg-wrap].¶

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, or the Verifier's signature over AttestationResults within the CMW 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.¶

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 remote Attestation Results obtained by the attester from its trusted Verifier can be cached and used for any number of subsequent TLS handshakes, as long as the freshness policy requirements are satisfied.¶

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, its public component and a short generated binder are ever 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.1 for more details.¶

4.1. Attestation Extension

As defined in Section 4.4.2 of [I-D.ietf-tls-rfc8446bis], the TLS Certificate message contains a certificate_list, which is a sequence of CertificateEntry structures.¶

When attestation is negotiated via the extensions defined in this document, the attestation 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 attestation 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 [I-D.ietf-rats-msg-wrap].¶

The attestation extension structure is defined as follows:¶

    struct {
        opaque cmw_payload<1..2^24-1>;
    } Attestation;

Figure 1: Attestation Extension Structure.

The cmw_payload field contains a CMW structure as defined in [I-D.ietf-rats-msg-wrap]. 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. The TEE's signature over the Evidence or AttestationResults within the CMW MUST include a binder ensuring that the attestation 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).¶

This binding ensures that the attested key is the one used in the TLS handshake and provides freshness guarantees 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 attestation is carried in the Attestation extension within that peer's Certificate message. This section describes how the attestation is produced, bound to the TLS handshake and verified by the recipient.¶

5.1. Cryptographic Operations

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

The attestation Evidence or Attestation Results are generated by a TEE and signed using an attestation key. The signed Evidence includes inputs originating from different trust domains.¶

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 Section 4.4.1 and 7.1 of [I-D.ietf-tls-rfc8446bis].¶

c_attest_base = Derive-Secret(0, "c attestation base",
                              ClientHello...Server-Finished)
s_attest_base = Derive-Secret(0, "s attestation base",
                              ClientHello...EncryptedExtensions)

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

We note that despite the use of the Derive-Secret primitive, none of these values are secret. Similarly we do not call HKDF-Extract which would not be effective.¶

5.1.2. Verification

Upon receipt of an attestation extension, the peer MUST compute the attestation binder.¶

Depending on the architecture (see also Section 5.3), either the peer verifies the binding 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 or signed Attestation Results. If the values do not match, the peer MUST treat the attestation as invalid and abort the handshake.¶
In the latter case, the RP MUST convey the binder to the Verifier. The Verifier MUST verify that the conveyed binder is identical to the one that was signed in the Evidence or Attestation Results.¶

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.¶

5.1.3. Security Properties

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

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

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 verified, ensures that relay attacks are prevented.¶

An active MiTM attacker cannot mount a successful attack because the attestation binder is derived from the TLS handshake transcript, including encrypted handshake messages that are not visible to eavesdroppers. An active attacker also cannot replay or relay attestation Evidence across TLS connections, since the attestation binder is bound to the specific TLS handshake transcript and the TLS identity key. Any attempt to reuse valid Evidence in a different TLS connection results in a binder mismatch and verification failure.¶

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).¶

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.¶

Without this binding, a non-TEE TLS endpoint can obtain Evidence from a separate TLS endpoint that genuinely runs inside a TEE 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 TEE, 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.1 for a further discussion.¶

5.3. The TLS Stack's Interface to the TEE

When the TEE signs the Evidence or Attestation Results, it also binds them to the TLS Identity public key and the TLS session. 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

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/AR generation APIs SHOULD reflect identifiers for the calling contexts into the generated credential. These identifiers can be reflected as separate claims in the credential, or can be measured as part of more generic claims. 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 require updated assurance that the peer continues to operate in a trustworthy state.¶

This section discusses design options for handling attestation freshness.¶

5.4.1. Option 1: Carrying Attestation in Extended Key Update

One possible approach is to extend the Extended Key Update (EKU) mechanism by introducing a new ExtendedKeyUpdate message subtype to carry attestation Evidence or Attestation Results.¶

However, this approach tightly couples attestation to EKU, even though the two serve different purposes.¶

5.4.2. Option 2: No Reattestation (Reconnect for Freshness)

Another approach is to not support reattestation within an established TLS connection. When fresh attestation is required, the client and server terminate the existing TLS session and establish a new one, during which fresh Evidence or Attestation Results are exchanged as part of the handshake.¶

This approach keeps the TLS protocol unchanged and avoids introducing post-handshake mechanisms. However, it will be disruptive for long-lived TLS connections.¶

5.4.3. Option 3: Post-Handshake Reattestation Using CertificateUpdate

In this design, reattestation is supported using the CertificateUpdate message defined in [I-D.rosomakho-tls-cert-update]. Under this approach, the attester sends a CertificateUpdate message carrying a new Certificate message with updated attestation information. The refreshed attestation is bound to the existing TLS session using post-handshake TLS context.¶

6. Negotiating This Protocol

This section defines the TLS extensions used to negotiate the use of attestation in the TLS handshake. Two models are supported: the Background Check Model, where Evidence is exchanged and verified during the handshake, and the Passport Model, where pre-verified Evidence in the form of Attestation Results are presented. The extensions defined here allow peers to indicate their support for attestation and negotiate which attestation format and Verifier to use.¶

Can we simplify this structure: remove the dual request/proposal, and unify the evidence+AR to a single negotiation extension. But also express Passport mode with and without freshness.¶

6.1. Evidence Extensions (Background Check Model)

The EvidenceType structure contains an indicator for the type of Evidence expected in the Attestation extension. The Evidence contained in the CMW payload is sent in the Attestation extension (see Section 4.1).¶

    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 {
        select(Handshake.msg_type) {
            case client_hello:
                EvidenceType supported_evidence_types<1..2^8-1>;
            case server_hello:
            case encrypted_extensions:
                EvidenceType selected_evidence_type;
        }
    } evidenceRequestTypeExtension;

    struct {
        select(Handshake.msg_type) {
            case client_hello:
                EvidenceType supported_evidence_types<1..2^8-1>;
            case server_hello:
            case encrypted_extensions:
                EvidenceType selected_evidence_type;
        }
    } evidenceProposalTypeExtension;

Figure 3: TLS Extension Structure for Evidence.

Values for media_type are defined in [iana-media-types]. Values for content_format are defined in [iana-content-formats].¶

6.2. Attestation Results Extensions (Passport Model)

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

    struct {
        select(Handshake.msg_type) {
            case client_hello:
                VerifierIdentityType trusted_verifiers<1..2^8-1>;

            case server_hello:
            case encrypted_extensions:
                VerifierIdentityType selected_verifier;
        }
    } resultsRequestTypeExtension;

    struct {
        select(Handshake.msg_type) {
            case client_hello:
                VerifierIdentityType trusted_verifiers<1..2^8-1>;

            case server_hello:
            case encrypted_extensions:
                VerifierIdentityType selected_verifier;
        }
    } resultsProposalTypeExtension;

Figure 4: TLS Extension Structure for Attestation Results.

In the Passport Model, Attestation Results are sent in an Attestation extension (see Section 4.1) containing a CMW structure. The CMW structure is defined in [I-D.ietf-rats-msg-wrap].¶

7. TLS Client and Server Handshake Behavior

The high-level message exchange in Figure 5 shows the evidence_proposal, evidence_request, results_proposal, and results_request extensions added to the ClientHello and the EncryptedExtensions messages.¶

       Client                                           Server

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

Figure 5: Early Attestation Handshake Overview

7.1. Background Check Model

7.1.1. Client Hello

To indicate the support for passing Evidence in TLS following the Background Check Model, clients include the evidence_proposal and/or the evidence_request extensions in the ClientHello.¶

The evidence_proposal extension in the ClientHello message indicates the Evidence types the client is able to provide to the server.¶

The evidence_request extension in the ClientHello message indicates the Evidence types the client challenges the server to provide in an attestation extension.¶

The evidence_proposal and evidence_request extensions sent in the ClientHello each carry a list of supported Evidence types, sorted by preference. When the client supports only one Evidence type, it is a list containing a single element.¶

The client MUST omit Evidence types from the evidence_proposal extension in the ClientHello if it cannot respond to a request from the server to present a proposed Evidence type, or if the client is not configured to use the proposed Evidence type with the given server. If the client has no Evidence types to send in the ClientHello it MUST omit the evidence_proposal extension in the ClientHello.¶

The client MUST omit Evidence types from the evidence_request extension in the ClientHello if it is not able to pass the indicated verification type to a Verifier. If the client does not act as a relying party with regards to Evidence processing (as defined in the RATS architecture) then the client MUST omit the evidence_request extension from the ClientHello.¶

7.1.2. Server Hello

If the server receives a ClientHello that contains the evidence_proposal extension and/or the evidence_request extension, then three outcomes are possible:¶

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

The evidence_proposal extension in the ClientHello indicates the Evidence types the client is able to provide to the server. If the server wants to request Evidence from the client, it MUST include the evidence_proposal extension in the EncryptedExtensions. This evidence_proposal extension in the EncryptedExtensions then indicates what Evidence format the client is requested to provide in an Attestation extension in the Certificate message. 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. The value conveyed in the evidence_proposal extension by the server MUST be selected from one of the values provided in the evidence_proposal extension sent in the ClientHello.¶

If none of the Evidence types supported by the client (as indicated in the evidence_proposal extension in the ClientHello) match the server-supported Evidence types, then the evidence_proposal extension in the ServerHello MUST be omitted.¶

The evidence_request extension in the ClientHello indicates what types of Evidence the client can challenge the server to return in an Attestation extension. With the evidence_request extension in the EncryptedExtensions, the server indicates the Evidence type carried in the Attestation extension sent after the CertificateVerify by the server. 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. The Evidence type in the evidence_request extension MUST contain a single value selected from the evidence_request extension in the ClientHello.¶

7.2. Passport Model

The results_proposal and results_request extensions are used to negotiate the protocol defined in this document, and in particular to negotiate the Verifier identities supported by each peer. These extensions are included in the ClientHello and ServerHello messages.¶

7.2.1. Client Hello

To indicate the support for passing Attestation Results in TLS following the Passport Model, clients include the results_proposal and/or the results_request extensions in the ClientHello message.¶

The results_proposal extension in the ClientHello message indicates the Verifier identities from which the client can relay Attestation Results. The client sends the Attestation Results in an Attestation extension in the Certificate message.¶

The results_request extension in the ClientHello message indicates the Verifier identities from which the client expects the server to provide Attestation Results in an Attestation extension in the Certificate message.¶

The results_proposal and results_request extensions sent in the ClientHello each carry a list of supported Verifier identities, sorted by preference. When the client supports only one Verifier, it is a list containing a single element.¶

The client MUST omit Verifier identities from the results_proposal extension in the ClientHello if it cannot respond to a request from the server to present Attestation Results from a proposed Verifier, or if the client is not configured to relay the Results from the proposed Verifier with the given server. If the client has no Verifier identities to send in the ClientHello it MUST omit the results_proposal extension in the ClientHello.¶

The client MUST omit Verifier identities from the results_request extension in the ClientHello if it is not configured to trust Attestation Results issued by said verifiers. If the client does not act as a relying party with regards to the processing of Attestation Results (as defined in the RATS architecture) then the client MUST omit the results_request extension from the ClientHello.¶

7.2.2. Server Hello

If the server receives a ClientHello that contains the results_proposal extension and/or the results_request extension, then three outcomes are possible:¶

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

The results_proposal extension in the ClientHello indicates the Verifier identities from which the client is able to provide Attestation Results to the server. If the server wants to request Attestation Results from the client, it MUST include the results_proposal extension in the EncryptedExtensions. This results_proposal extension in the EncryptedExtensions then indicates what Verifier the client is requested to provide Attestation Results from in an Attestation extension in the Certificate message. The value conveyed in the results_proposal extension by the server MUST be selected from one of the values provided in the results_proposal extension sent in the ClientHello.¶

If none of the Verifier identities proposed by the client (as indicated in the results_proposal extension in the ClientHello) match the server-trusted Verifiers, then the results_proposal extension in the ServerHello MUST be omitted.¶

The results_request extension in the ClientHello indicates what Verifiers the client trusts as issuers of Attestation Results for the server. With the results_request extension in the EncryptedExtensions, the server indicates the identity of the Verifier who issued the Attestation Results carried in the Attestation extension sent in the Certificate by the server. The Verifier identity in the results_request extension MUST contain a single value selected from the results_request extension in the ClientHello.¶

12. References

12.1. Normative References

[I-D.ietf-rats-msg-wrap]: Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23, 11 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-23>.
[I-D.ietf-tls-rfc8446bis]: Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-rfc8446bis-14, 13 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-14>.
[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>.

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-09, 30 April 2025, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-09>.
[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-08, 3 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-daa-08>.
[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-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.rosomakho-tls-cert-update]: Rosomakho, Y. and T. Reddy.K, "Certificate Update in TLS 1.3", Work in Progress, Internet-Draft, draft-rosomakho-tls-cert-update-01, 21 December 2025, <https://datatracker.ietf.org/doc/html/draft-rosomakho-tls-cert-update-01>.
[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>.
[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-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.2. 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.3. draft-fossati-seat-early-attestation-01

(Submitted by mistake.)¶

A.4. 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¶