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

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

• Independent handshake message: A new Attestation handshake message is introduced that carries attestation Evidence or Attestation Results. This message is completely independent of the standard TLS handshake flow and does not interfere with existing handshake messages or their processing.¶

• Independent key derivation: Key derivation for attestation (see Section 5.6) ensures independence of the regular TLS key schedule. As a result, 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.1. Attestation Handshake Message

When attestation is negotiated via the extensions defined in this document, attestation Evidence or Attestation Results are conveyed in a new handshake message type: Attestation. This message carries a CMW (Conceptual Message Wrapper) payload as defined in [I-D.ietf-rats-msg-wrap].¶

The Attestation message structure is defined as follows:¶

    enum {
        /* other handshake message types defined in {{I-D.ietf-tls-rfc8446bis}} */
        attestation(TBD),
        (255)
    } HandshakeType;

    struct {
        HandshakeType msg_type;    /* handshake type */
        uint24 length;             /* bytes in message */
        select (Handshake.msg_type) {
            case attestation:
                Attestation;
            /* other handshake message types */
        };
    } Handshake;

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

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 derived from the TLS main secret and the message transcript, up to ServerHello, ensuring freshness of the attestation.¶

• 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 secret derivation. See Section 5.6 for details.¶

5.1. Handshake Overview

The handshake defined here is analogous to certificate-based authentication in a regular TLS handshake. The peer being attested first proves possession of the private key using the CertificateVerify message, which remains unchanged from baseline TLS. Following that, the TLS Identity Key (TIK) is bound by the TEE to the attestation credential being carried in a new Attestation handshake message (see Section 4.1).¶

The attestation Evidence or Attestation Results are conveyed in an Attestation handshake message (see Section 4.1), which carries a CMW payload as defined in [I-D.ietf-rats-msg-wrap].¶

5.2. TLS Client Authenticating Using Evidence

In this use case, the TLS server (acting as a relying party) challenges the TLS client (as the attester) to provide Evidence. A session-specific value is derived (see Section 5.6) which incorporates randomness from both client and server, and this value is fed into the generation of the Evidence. The client sends the Evidence in an Attestation handshake message after the CertificateVerify message. The TLS server, when receiving the Evidence, will have to contact the Verifier (which is not shown in the diagram).¶

An example of this flow can be found in device onboarding where the client initiates the communication with cloud infrastructure to get credentials, firmware and other configuration data provisioned to the device. For the server to consider the device genuine it needs to present Evidence.¶

       Client                                           Server

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

5.3. TLS Server Authenticating Using Evidence

In this use case the TLS client challenges the TLS server to present Evidence. The TLS server acts as an attester while the TLS client is the relying party. The server sends the Evidence in an Attestation handshake message after the CertificateVerify message. The TLS client, when receiving the Evidence, will have to contact the Verifier (which is not shown in the diagram).¶

An example of this flow can be found in confidential computing where a compute workload is only submitted to the server infrastructure once the client/user is assured that the confidential computing platform is genuine.¶

       Client                                           Server

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

5.4. TLS Client Authenticating Using Attestation Results

In this use case the TLS client, as the attester, provides Attestation Results to the TLS server. The TLS client is the attester and the TLS server acts as a relying party. Prior to delivering its Certificate message, the client must contact the Verifier (not shown in the diagram) to receive the Attestation Results that it will use as credentials. The client sends the Attestation Results in an Attestation handshake message after the CertificateVerify message.¶

       Client                                           Server

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

5.5. TLS Server Authenticating Using Attestation Results

In this use case the TLS client, as the relying party, requests Attestation Results from the TLS server. Prior to delivering its Certificate message, the server must contact the Verifier (not shown in the diagram) to receive the Attestation Results that it will use as credentials. The server sends the Attestation Results in an Attestation handshake message after the CertificateVerify message.¶

       Client                                           Server

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

5.6. Cryptographic Operations

This section defines the key derivation for attestation, which operates independently from the regular TLS key schedule as described in Section 7.1 of [I-D.ietf-tls-rfc8446bis].¶

The attestation key derivation uses HKDF Section 7.1 of [I-D.ietf-tls-rfc8446bis] to derive attestation-specific secrets from the TLS main secret. Two attestation main secrets are derived: one for the client (c_attest_main) and one for the server (s_attest_main).¶

The key derivation follows this structure:¶

The attestation main secrets (c_attest_main and s_attest_main) are derived from the TLS main secret using Derive-Secret as defined in Section 7.1 of [I-D.ietf-tls-rfc8446bis], with the labels "c attestation main" and "s attestation main" respectively, and the handshake transcript up to and including ServerHello as the context.¶

The client's attestation binder (c_attest_binder) that will be signed by the TEE is derived by applying HKDF-Expand-Label to c_attest_main with the label "attestation" and the client's TLS public key as the context:¶

c_attest_binder = HKDF-Expand-Label(c_attest_main, "attestation",
                                    TLS_Client_Public_Key, Hash.length)

Similarly, the server's attestation binder (s_attest_binder) is derived from s_attest_main:¶

s_attest_binder = HKDF-Expand-Label(s_attest_main, "attestation",
                                    TLS_Server_Public_Key, Hash.length)

The attestation binder is derived independently by both the attester and the peer. The attester incorporates this attestation binder into the Evidence. Upon receipt of the Attestation handshake message, the peer will have to derive the expected attestation binder using the same inputs and verify that the computed attestation binder matches the one in the Evidence. If this verification fails, the peer will treat the attestation as invalid. This verification ensures that the Evidence is bound to the specific TLS session and TLS public key being attested.¶

5.7. 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 Evidence MUST include the TIK public key (TIK_pub). The relying party MUST verify that the TIK_pub included in the Evidence matches the public key presented in the TLS Certificate message. This binds the attestation Evidence to the TLS identity used for authentication.¶

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 attempt to protect the confidentiality of the TLS main secret in split deployments, where the TLS stack executes in the rich OS and remains susceptible to compromise.¶

5.8. 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. Therefore 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.6, 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.¶

7.1. Session Resumption

TLS 1.3 supports session resumption using Pre-Shared Keys (PSK) as defined in Section 4.6 of [I-D.ietf-tls-rfc8446bis]. When using attestation, session resumption works normally when reattestation is not required.¶

If client reattestation is required according to local policy (e.g., based on timing since the last attestation or changes in attestation state), session resumption MUST be rejected. The decision to reject resumption is per local policy and may depend on the timing of the resumption attempt relative to the required reattestation period. When resumption is rejected, the client MUST initiate a full handshake with attestation to obtain fresh attestation Evidence or Attestation Results.¶

The rationale for rejecting resumption when reattestation is required is that attestation state may have changed since the original handshake, and fresh verification is needed to ensure the peer's platform and workload remain in a trustworthy state. If the client wishes to retain a long-running connection, it SHOULD perform reattestation Section 7.2 periodically, as per local policy.¶

7.2. Reattestation

Over time, attestation Evidence or Attestation Results may become stale and require refresh. Long-lived TLS connections require updated assurance that the peer continues to operate in a trustworthy state. This document therefore supports reattestation, in which either peer MAY request fresh Evidence at any time post-handshake. The attester MUST generate evidence using a freshly derived attestation_binder.¶

Reattestation is tied to the completion of an Extended Key Update (EKU) exchange [I-D.ietf-tls-extended-key-update]. TLS peers that require reattestation MUST support EKU, since reattestation depends on the key schedule update defined in the EKU draft. The first two messages of an EKU exchange introduce fresh key-exchange input and make Main Secret N+1 available to both peers.¶

The Attestation message MUST be sent immediately before the attestor sends its EKU(new_key_update) message. Once Main Secret N+1 is available (after the first two EKU messages), the attester derives a new attestation_binder from Main Secret N+1, using the concatenation of the EKU request and response messages and its TLS identity public key as context.¶

The receiving peer, however, MUST NOT process the Attestation until the EKU exchange and the authenticated transition step have completed. This ensures that attestation bound to Main Secret N+1 is accepted only after both peers have confirmed that they share the same updated key state.¶

For a client attester:¶

client_attestation_binder =
      Derive-Secret(Main Secret N+1,
                    "reattestation",
                    EKU(request) ||
                    EKU(response) ||
                    TLS_Client_Public_Key)

For a server attester:¶

server_attestation_binder =
      Derive-Secret(Main Secret N+1,
                    "reattestation",
                    EKU(request) ||
                    EKU(response) ||
                    TLS_Server_Public_Key)

Including the EKU request and response messages ensures that the resulting attestation binder is bound to the specific EKU exchange and therefore reflects fresh key-exchange entropy introduced by EKU.¶

After deriving the fresh attestation_binder, the attester:¶

1. generates fresh Evidence using the new attestation_binder and¶

2. sends a new Attestation handshake message containing the updated CMW payload.¶

The TLS peer validates the attestation by deriving and verifying the attestation binder as specified in Section 5.6.¶

Reattestation uses the Attestation formats that were negotiated during the initial handshake, there is no re-negotiation at this stage.¶

The decision to initiate reattestation is per local policy and may be based on factors such as elapsed time since the last attestation, changes in platform state, or security policy requirements.¶

8.1. Evidence Extensions (Background Check Model)

The EvidenceType structure contains an indicator for the type of Evidence expected in the Attestation handshake message. The Evidence contained in the CMW payload is sent in the Attestation handshake message (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;

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

8.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;

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

9.1. Background Check Model

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

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

10.2. Freshness Guarantees

TODO: Discuss freshness guarantees provided by secret derivation from the TLS main secret and message transcript. Differences between Background Check and Passport mode. ¶

10.3. Security of Reattestation After Extended Key Update

Reattestation relies on the assumption that both peers have derived the same Main Secret N+1 during the preceding EKU exchange. EKU by itself does not guarantee that the peers transitioned to a consistent key state in the presence of an active attacker. Deployments that require stronger guarantees will have use an authenticated transition mechanism discussed in [I-D.ietf-tls-extended-key-update] (e.g., post-handshake client authentication or Exported Authenticators) to detect key-schedule divergence before relying on reattestation results.¶

12.1. TLS Extensions

IANA is asked to allocate four new TLS extensions, evidence_request, evidence_proposal, results_request, results_proposal, from the "TLS ExtensionType Values" subregistry of the "Transport Layer Security (TLS) Extensions" registry [TLS-Ext-Registry]. These extensions are used in the ClientHello and the EncryptedExtensions messages. The values carried in these extensions are taken from TBD.¶

12.2. TLS Alerts

IANA is requested to allocate a value in the "TLS Alerts" subregistry of the "Transport Layer Security (TLS) Parameters" registry [TLS-Param-Registry] and populate it with the following entries:¶

• Value: TBD1¶

• Description: unsupported_evidence¶

• DTLS-OK: Y¶

• Reference: [This document]¶

• Comment:¶

• Value: TBD2¶

• Description: unsupported_verifiers¶

• DTLS-OK: Y¶

• Reference: [This document]¶

• Comment:¶

12.3. TLS Handshake Message Types

IANA is requested to allocate a new value in the "TLS HandshakeType" registry of the "Transport Layer Security (TLS) Parameters" registry [TLS-Param-Registry], as follows:¶

• Value: TBD¶

• Description: attestation¶

• DTLS-OK: Y¶

• Reference: [This document]¶

• Comment: Used to carry attestation Evidence or Attestation Results in the TLS handshake¶

14.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-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-07, 1 November 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-extended-key-update-07>.

[I-D.ietf-tls-pake]

Bauman, L., Benjamin, D., Menon, S., and C. A. Wood, "A Password Authenticated Key Exchange Extension for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-pake-00, 4 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-pake-00>.

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

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

[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/>.

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

B.1. Requires Certificate Authentication

TLS 1.3 supports authentication modes where no Certificate message is sent:¶

• PSK-based authentication¶

• PAKE-based authentication [I-D.ietf-tls-pake]¶

A design that relies on a Certificate message extension cannot operate in these cases. In contrast, a dedicated Attestation handshake message works regardless of authentication mode, making it compatible with the full TLS authentication spectrum.¶

B.2. Reattestation Not Fully Supported

TLS allows Post-Handshake client authentication Section 4.2.6 of [I-D.ietf-tls-rfc8446bis] but provides no mechanism for Post-Handshake server authentication. As a result, a design that embeds attestation inside the Certificate message would allow only the client and not the server to refresh its attestation. This is insufficient for deployments that require periodic server reattestation.¶