]> TU Dresden

muhammad_usama.sardar@tu-dresden.de

Linaro

thomas.fossati@linaro.org

Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

Intuit

yaronf.ietf@gmail.com

University of the Bundeswehr Munich

Neubiberg Bavaria 85577 Germany hannes.tschofenig@gmx.net

Arm Limited

ionut.mihalcea@arm.com

Security SEAT Working Group Attestation TLS Exported Authenticators This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in . Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SEAT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction There is a growing need to demonstrate to a remote party that cryptographic keys are stored in a secure element, the device is in a known good state, secure boot has been enabled, and that low-level software and firmware have not been tampered with. Remote attestation provides this capability. More technically, an Attester produces a signed collection of Claims that constitute Evidence about its running environment(s). A Relying Party may consult an Attestation Result produced by a Verifier that has appraised the Evidence to make policy decisions regarding the trustworthiness of the Target Environment being assessed. This is, in essence, what defines. At the time of writing, several standard and proprietary remote attestation technologies are in use. This specification aims to remain as technology-agnostic as possible concerning implemented remote attestation technologies. To streamline attestation in TLS, this document introduces the cmw_attestation extension, which allows attestation credentials to be conveyed directly in the Certificate message during the Exported Authenticator-based post-handshake authentication. This eliminates reliance on real-time certificate issuance from a Certificate Authority (CA), reducing handshake delays while ensuring Evidence remains bound to the TLS connection. The extension supports both the passport and background check models from the RATS architecture, enhancing flexibility for different deployment scenarios. This document builds upon three foundational specifications:

• RATS (Remote Attestation Procedures) Architecture : It defines how remote attestation systems establish trust between parties by exchanging Evidence and Attestation Results. These interactions can follow different models, such as the passport or the background check model, depending on the order of data flow in the system.
• TLS Exported Authenticators : It offers bi-directional post-handshake authentication. Once a TLS connection is established, both peers can send an authenticator request message at any point after the handshake. This message from the server and the client uses the CertificateRequest and the ClientCertificateRequest messages, respectively. The peer receiving the authenticator request message can respond with an Authenticator consisting of Certificate, CertificateVerify, and Finished messages. These messages can then be validated by the other peer.
• RATS Conceptual Messages Wrapper (CMW) : CMW provides a structured encapsulation of Evidence and Attestation Result, abstracting the underlying attestation technology.

This specification introduces the cmw_attestation extension, enabling Evidence to be included directly in the Certificate message during the Exported Authenticator-based post-handshake authentication defined in .

Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals as shown here. The reader is assumed to be familiar with the vocabulary and concepts defined in and . "Remote attestation credentials", or "attestation credentials", is used to refer to both Evidence and attestation results, when no distinction needs to be made between them.

cmw_attestation Extension to the Authenticator's Certificate message This document introduces a new extension, called cmw_attestation, to the Authenticator's Certificate message. This extension allows Evidence or Attestation Results to be included in the extensions field of the end-entity certificate in the Authenticator's Certificate message. As defined in , the TLS Certificate message consists of a certificate_list, which is a sequence of CertificateEntry structures. Each CertificateEntry contains a certificate and a set of associated extensions. The cmw_attestation extension MUST appear only in the first CertificateEntry of the Certificate message and applies exclusively to the end-entity certificate. It MUST NOT be included in entries corresponding to intermediate or trust anchor certificates. This design ensures that attestation information is tightly bound to the entity being authenticated. The cmw_attestation extension is only included in the Certificate message during Exported Authenticator-based post-handshake authentication. This ensures that the attestation credentials are conveyed within the Certificate message, eliminating the need for modifications to the X.509 certificate structure. ; } CMWAttestation; ]]> cmw_data: Encapsulates the attestation credentials in CMW format . The cmw_data field is encoded using CBOR or JSON. This approach eliminates the need for real-time certificate issuance from a Certificate Authority (CA) and minimizes handshake delays. Typically, CAs require several seconds to minutes to issue a certificate due to verification steps such as validating subject identity, signing the certificate, and distributing it. These delays introduce latency into the TLS handshake, making real-time certificate generation impractical. The cmw_attestation extension circumvents this issue by embedding attestation data within the Certificate message itself, removing reliance on external certificate issuance processes.

Negotiation of the cmw_attestation Extension Negotiation of support cmw_attestation extension follows the model defined in . Endpoints that wish to receive attestation credentials using Exported Authenticators MUST indicate support by including an empty cmw_attestation extension in the CertificateRequest or ClientCertificateRequest message. The presence of this empty extension indicates that the requester understands this specification and is willing to process an attestation credential in the peer's Certificate message. An endpoint that supports this extension and receives a request containing it MAY include the cmw_attestation extension in its Certificate message, populated with attestation data. If the cmw_attestation extension appears in a Certificate message without it having been previously offered in the corresponding request, the receiver MUST abort the authenticator verification with an "unsupported_extension" alert. As specified in , endpoints that do not recognize the cmw_attestation extension in a CertificateRequest or ClientCertificateRequest MUST ignore it and continue processing the message as if the extension were absent.

Usage in Exported Authenticator-based Post-Handshake Authentication The cmw_attestation extension is designed to be used exclusively in Exported Authenticator-based post-handshake authentication as defined in . It allows attestation credentials to be transmitted in the Authenticator's Certificate message only in response to an Authenticator Request. This ensures that attestation credentials are provided on demand rather than being included in the initial TLS handshake. To maintain a cryptographic binding between the Evidence and the authentication request, the cmw_attestation extension MUST be associated with the certificate_request_context of the corresponding CertificateRequest or ClientCertificateRequest message (from the Server or Client, respectively). This association ensures that the Evidence is specific to the authentication event.

Ensuring Compatibility with X.509 Certificate Validation The cmw_attestation extension does not modify or replace X.509 certificate validation mechanisms. It serves as an additional source of authentication data rather than altering the trust model of PKI-based authentication. Specifically:

• Certificate validation (e.g., signature verification, revocation checks) MUST still be performed according to TLS and PKIX .
• The attestation credentials carried in cmw_attestation MUST NOT be used as a substitute for X.509 certificate validation but can be used alongside standard certificate validation for additional security assurances.
• Implementations MAY reject connections where the certificate is valid but the attestation credentials is missing or does not meet security policy.

Applicability to Client and Server Authentication The cmw_attestation extension is applicable to both client and server authentication in Exported Authenticator-based post-handshake authentication. In TLS, one party acts as the Relying Party, and the other party acts as the Attester. Either the client or the server may fulfill these roles depending on the authentication direction. The Attester may respond with either:

• Evidence (Background Check Model):
  • The Attester generates Evidence and includes it in the cmw_attestation extension to the Authenticator's Certificate message.
  • The Relying Party forwards the Evidence to an external Verifier for evaluation and waits for an Attestation Result.
  • The Relying Party grants or denies access, or continues or terminates the TLS connection, based on the Verifier's Attestation Result.
• Attestation Result (Passport Model):
  • The Attester sends Evidence to a Verifier beforehand.
  • The Verifier issues an Attestation Result to the Attester.
  • The Attester includes the Attestation Result in the cmw_attestation extension to the Authenticator's Certificate message and sends it to the Relying Party.
  • The Relying Party validates the Attestation Result directly without needing to contact an external Verifier.

By allowing both Evidence and Attestation Results to be conveyed within cmw_attestation, this mechanism supports flexible attestation workflows depending on the chosen trust model.

Architecture The cmw_attestation extension enables attestation credentials to be included in the Certificate message during Exported Authenticator-based post-handshake authentication, ensuring that attestation remains bound to the TLS connection. However, applications using this mechanism still need to negotiate the encoding format (e.g., JOSE or COSE) and specify how attestation credentials are processed. This negotiation can be done via application-layer signaling or predefined profiles. Future specifications may define mechanisms to streamline this negotiation. Upon receipt of a Certificate message containing the cmw_attestation extension, an endpoint MUST take the following steps to validate the attestation credentials:

• Background Check Model:
  • Verify Integrity and Authenticity: The Evidence must be cryptographically verified against a known trust anchor, typically provided by the hardware manufacturer.
  • Verify Certificate Request Binding and Freshness: The Evidence must be bound to the active TLS connection by verifying that the exporter value in the Evidence matches the exporter value computed using the label "Attestation Binding" and the certificate_request_context as the exporter context. This verification ensures correct connection binding, provides freshness, and prevents replay.
  • Evaluate Security Policy Compliance: The Evidence must be evaluated against the Relying Party's security policies to determine if the attesting device and the private key storage meet the required criteria.
• Passport Model:
  • Verify the Attestation Result: The Relying Party MUST check that the Attestation Result is correctly signed by the issuing authority and that it meets the Relying Party’s security requirements.

By integrating cmw_attestation directly into the Certificate message during Exported Authenticator-based post-handshake authentication, this approach reduces latency and complexity while maintaining strong security guarantees. In the following examples, the server possesses an identity certificate, while the client is not authenticated during the initial TLS exchange.

Client as Attester

Passport Model shows the passport model.

Passport Model with Client as Attester | | | | | | ... time passes ... | | | | | | Authenticator Request | | | (CertificateReq) | | |<-----------------------| | | | | | Sends Evidence | |------------------------------------------------->| | Gets Attestation result | |<-------------------------------------------------| | Exported Authenticator(| | | Certificate with | | | cmw_attestation, | | | CertificateVerify, | | | Finished) | | |----------------------->| | ]]>

Background-check Model shows an example using the background-check model, where TE represents the Target Environment and AE represents the Attesting Environment. The TLS Client within TE establishes a TLS connection with the Server. At a later time, the Server triggers an Authenticator Request. The TE requests Evidence from the AE. The Evidence produced includes the TE's TCB measurements, including those relating to the TLS Client code and configuration. The TE embeds this Evidence into an Exported Authenticator and sends it to the Server. The Server forwards the Evidence to a Verifier for appraisal and receives an Attestation Result.

Background Check Model with Client as Attester | | | | | | | ... time passes ... | | | | | | | Authenticator Request (CertificateReq) | | |<-------------------------------------------| | | | | | | Request Evidence | | | |------------------>| | | | Attestation | | | | Evidence | | | |<------------------| | | | Exported Authenticator(Certificate with | | | cmw_attestation, | | | CertificateVerify, | | | Finished) | | |------------------------------------------->| | | | | Send Evidence | | | |----------------->| | | | Attestation | | | | Result | | | |<-----------------| | | | | ]]>

Server as Attester The flow for the Server as Attester is analogous, except that it uses a ClientCertificateRequest instead of CertificateRequest.

API Requirements for Attestation Support To enable attestation workflows, implementations of the Exported Authenticator API MUST support the following:

1. Authenticator Generation
   • The API MUST support the inclusion of attestation credentials within the Certificate message provided as input.
2. Authenticator Validation
   • The API MUST support verification that the Evidence in the Certificate message is cryptographically valid and correctly bound to the TLS connection and the associated certificate_request_context.

Cryptographic Binding of the Evidence to the TLS Connection The cryptographic operations defined in this section bind attestation Evidence to a specific TLS connection. 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 connection in which it is conveyed. Attestation Evidence is 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 an attestation challenge that ensures freshness and binds the attestation to a specific TLS connection.
• A claim generated by the TEE itself, such as a hash of the AIK public key, which ensures that the attested environment controls the AIK private key used for TLS authentication.

Attestation Binder The attester binds the attestation Evidence to the active TLS connection. To do so, the attester derives a binding value using the TLS exporter. The exporter invocation uses:

• the label "Attestation", and
• the certificate_request_context from the CertificateRequest message as the context_value (as defined in Section 7.5 of ). In a Background Check model, this value contains the Verifier-provided nonce; and
• a key_length set to 256-bit (32 bytes).

The binding value is defined as: where exported_value is the output of the TLS exporter and public_key is the public key corresponding to the end-entity certificate used for authentication. The Hash function is the hash algorithm associated with the negotiated TLS 1.3 cipher suite (i.e., the HKDF hash). This binding value is included as an attestation challenge (or nonce) in the attestation Evidence. It binds the Evidence to the specific TLS connection and to the associated certificate_request_context, thereby providing freshness and preventing replay across TLS sessions. The TLS endpoint that receives the attestation Evidence computes the binding value using the same exporter and hash function invocation described for the attester. The endpoint either verifies the exporter binding itself or delegates this check to the Verifier. If it performs the check locally and the values do not match, the attestation Evidence is rejected. If the check is delegated, the endpoint conveys the computed binding value to the Verifier so that the comparison can be carried out during attestation validation.

Binding the Authenticator Identity Key (AIK) to the TEE This specification assumes that the private key corresponding to the end-entity certificate carried in the exported authenticator referred to as the Authenticator Identity Key (AIK) is generated inside a TEE and never leaves it. A platform could instead generate the AIK 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 AIK private key used by the TLS endpoint was generated, is stored, or is controlled by the TEE. To address this risk, the Evidence MUST include the hash of the AIK public key (AIK_pub_hash). The AIK public key MUST be hashed using the hash algorithm associated with the negotiated TLS cipher suite for the TLS connection in which the Evidence is conveyed. The Relying Party MUST compute the hash of the AIK public key extracted from the TLS end-entity certificate using the same hash algorithm and verify that it matches the AIK_pub_hash included in the Evidence. Successful verification binds the attestation Evidence to the TLS identity used for authentication.

Operational Overview This specification follows the Exported Authenticator model defined in Section 7 of . In this model, the TLS stack creates and validates post-handshake authentication messages, while the application triggers the exchange and conveys the Authenticator Request and Authenticator messages between peers. Whenever attestation is required, the application initiates Exported Authenticator–based post-handshake authentication. The TLS stack constructs an Authenticator Request, using either a CertificateRequest or ClientCertificateRequest message, and indicates support for attestation by including an empty cmw_attestation extension. On the attesting side, the platform generates RATS conceptual message, either in the form of Evidence or an Attestation Result, depending on the deployment model. The TLS stack embeds the RATS conceptual message in the cmw_attestation extension and completes the Exported Authenticator by generating the corresponding CertificateVerify and Finished messages. The application then conveys the resulting Authenticator to the peer, as defined in . Upon receipt, the application delivers the Authenticator to the TLS stack for processing. The TLS stack validates the certificate chain, the CertificateVerify signature, and the Finished message, and extracts the cmw_attestation extension. The TLS stack treats the contents of the cmw_attestation extension as opaque. If the cmw_attestation extension carries Evidence, the application acting as the Relying Party forwards it to a Verifier to obtain an Attestation Result. If the extension carries an Attestation Result, the application validates it directly. Based on the outcome of this processing, the application determines whether to continue using the TLS connection. While it is technically possible to create or validate Authenticator Requests and Authenticators at the application layer, Section 7 of recommends that their creation and validation be handled within the TLS library.

Security Considerations This document inherits the security considerations of and . The integrity of the exported authenticators must be guaranteed, and any failure in validating Evidence SHOULD be treated as a fatal error in the communication channel. Additionally, in order to benefit from remote attestation, Evidence MUST be protected using dedicated attestation keys chaining back to a trust anchor. This trust anchor will typically be provided by the hardware manufacturer. This specification assumes that the Hardware Security Module (HSM) or Trusted Execution Environment (TEE) is responsible for generating the Authenticator Identity Key (AIK) key pair and producing either Evidence or Attestation Results. The Evidence or Attestation Results MAY be included in a Certificate Signing Request (CSR), as defined in , enabling the CA to verify that the AIK private key is securely generated and stored and that the platform meets the required security standards before issuing a certificate.

Security Guarantees Note that as a pure cryptographic protocol, attested TLS as-is only guarantees that the identity key used for TLS handshake is known by the confidential environment, such as confidential virtual machine. 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 used for TLS handshake is generated within the trustworthy environment, such as Trusted Platform Module (TPM) or TEE.
• The identity key used for TLS handshake is never exported or leaked outside the trustworthy environment.
• For confidential computing use cases, the TLS protocol is implemented within the confidential environment, and is implemented correctly, e.g., it does not leak any session key material.
• The TLS stack including the code that performs the post-handshake phase must be measured.
• There must be no other way to initiate generation of evidence except from signed code.

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.

Using the TLS Connection Remote attestation in this document occurs within the context of a TLS handshake, and the TLS connection remains valid after this process. Care must be taken when handling this TLS connection, as both the client and server must agree that remote attestation was successfully completed before exchanging data with the attested party. Session resumption presents special challenges since it happens at the TLS level, which is not aware of the application-level Authenticator: a resumed session could be used before attestation completes, and race conditions between resumption and post-handshake attestation are possible. To avoid this, this document prohibits session resumption and 0-RTT data entirely for TLS connections in scope of this specification:

• A TLS server MUST NOT send a NewSessionTicket message on any connection for which it requires remote attestation using this specification.
• A TLS client MUST NOT offer 0-RTT (early_data) on such a connection.
• As defense in depth against a non-conformant server, a TLS client that receives a NewSessionTicket message on such a connection MUST discard it and MUST NOT attempt to use it for resumption.

Because these connections are therefore established via a full handshake or the certificate-with-external-PSK handshake, both of which include a fresh key exchange, the freshness argument in holds.

Timing for Remote Attestation Remote attestation MUST be completed before sending any application data to the peer. For use cases that require only a one-time attestation for the lifetime of a TLS connection, remote attestation can be performed immediately after the TLS handshake completes.

Evidence Freshness The Evidence carried in cmw_attestation does not require an additional freshness mechanism (such as a nonce or a timestamp). Freshness is already ensured by the exporter value derived using the certificate_request_context, as described in . Because this value is bound to the active TLS connection, and because session resumption and 0-RTT data are prohibited for such connections (see ), the Evidence is guaranteed to be fresh for the connection in which it is generated. The Evidence presented in this protocol is valid only at the time it is generated and presented. To ensure that the attested peer continues to operate in a secure state, remote attestation may be re-initiated periodically. In this protocol, this can be accomplished by initiating a new Exported-Authenticator–based post-handshake authentication exchange, which results in a new certificate_request_context and therefore a newly derived exporter value to maintain freshness.

Privacy Considerations

Client as Attester 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 model, 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 (i.e., the RP) with whom the secure channel establishment is attempted . The privacy implications are similar to OCSP . 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:

• Attester-side redaction of privacy-sensitive evidence claims,
• Using selective disclosure (e.g., SD-JWT with EAT ),
• Co-locating the Verifier role with the RP,
• Utilizing privacy-preserving attestation schemes (e.g., DAA ), or
• Utilizing Attesters manufactured with group identities (e.g., Requirement 4.1 of ).

The last two also have the property of hiding the peer's identity from the RP. Note that the equivalent of OCSP "stapling" involves using a passport topology where the Verifier's involvement is unrelated to the TLS connection.

Server as Attester For the case of the TLS server as the Attester, the server can ask for client authentication and only send the Evidence after successful client authentication. This limits the exposure of server's hardware-level Claims to be revealed only to authorized clients.

IANA Considerations // Note to RFC Editor: in this section, please replace RFCthis with the RFC number assigned to this document and remove this note.

TLS Extension Type Registration IANA is requested to register the following new extension type in the "TLS ExtensionType Values" registry :

Value	Extension Name	TLS 1.3	DTLS-Only	Recommended	Reference
TBD	cmw_attestation	CT	N	Yes	RFCthis

References Normative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Vigil Security, LLC This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC (once approved) obsoletes RFC 8773, which was an Experimental RFC. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] IANA Informative References Cryptic Forest Software Siemens Fraunhofer SIT Independent Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. Faculty of Computer Science, Technical University of Dresden, Dresden, Germany Huawei Technologies Oy, Helsinki, Finland Department of Computer Science, University of Applied Sciences Bonn-Rhein-Sieg and Siemens, Sankt Augustin, Germany Linaro, Lausanne, Switzerland Institute of Electrical and Electronics Engineers (IEEE) TU Dresden, Dresden, Germany Aalto University, Espoo, Finland Aalto University, Espoo, Finland ACM An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. Fraunhofer SIT University of Surrey University of Surrey Ubitech Microsoft This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro 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 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 protocol extensions to the TLS 1.3 handshake that enables 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 mutually.

Acknowledgements We would like to thank Chris Patton for his proposal to explore RFC 9261 for attested TLS. We would also like to thank Eric Rescorla, Paul Howard, and Yogesh Deshpande for their input.

Appendix

Post-handshake vs. Intra-handshake Privacy From the view of the TLS server, post-handshake attestation offers better privacy than intra-handshake attestation when the server acts as the Attester. In intra-handshake attestation, due to the inherent asymmetry of the TLS protocol, a malicious TLS client could potentially retrieve sensitive information from the Evidence without the client's trustworthiness first being established by the server. In post-handshake attestation, the server can ask for client authentication and only send the Evidence after successful client authentication.

Post-handshake vs. Intra-handshake Security Intra-handshake attestation proposal is vulnerable to diversion attacks . It also does not bind the Evidence to the application traffic secrets, resulting in relay attacks . Formal analysis of post-handshake attestation is a work-in-progress.

Document History -00

• Expanded security considerations, in particular added security guarantees
• Added privacy considerations
• Corrected

-01

• Added channel binding
• Added security analysis of intra-handshake attestation in Appendix

-02

• Security considerations: Race conditions
• Security considerations: Timing of remote attestation
• Updated Client as Attester
• Added Server as Attester
• Added operational overview

-03

• Prohibited session resumption and 0-RTT data.