Application-Layer Transport for Exported Authenticators and Attestation

Internet-Draft	ALTEA	June 2026
Reddy & Tschofenig	Expires 25 December 2026	[Page]

Abstract

This document defines a binary, application-layer transport protocol for exchanging Exported Authenticator messages between two peers over TLS. It provides the signaling required to initiate and complete post-handshake authentication exchanges at the application layer, without requiring modifications to the TLS layer itself.¶

While primarily intended to support attestation exchange, the transport is generic and can be used independently for any Exported Authenticator exchange.¶

The document further specifies how protocol messages are conveyed as Capsules over an HTTP connection established using the Extended CONNECT method, with support for both HTTP/2 and HTTP/3. In addition, it defines how the protocol can operate directly over TLS or DTLS 1.3 without an HTTP binding, using a so-called "Shim Mode".¶

1. Introduction

TLS Exported Authenticators [RFC9261] provide a mechanism for post-handshake authentication over an established TLS 1.3 connection. Either peer may request an Exported Authenticator from the other after the TLS handshake has completed. However, [RFC9261] defines only the authenticator mechanism itself; it does not define how authenticator requests, responses, or errors are signaled between peers. Each application protocol is therefore responsible for defining its own transport and signaling mechanism.¶

[I-D.fossati-seat-expat] extends Exported Authenticators to carry attestation Evidence and Attestation Results, enabling attestation to be performed after the TLS handshake. As with [RFC9261], it defines the semantics and content of the messages, but not the application-layer transport used to carry them.¶

This document defines such a transport. It specifies a binary application-layer protocol for exchanging Exported Authenticator messages between two peers over an established TLS connection. The protocol is generic: although it is primarily motivated by attestation exchange, it can be used for any Exported Authenticator exchange.¶

The specification defines:¶

Binary message structures, using the presentation language of [RFC8446], for carrying Exported Authenticator requests, responses, and errors.¶
A capability negotiation mechanism that allows peers to determine the supported attestation message patterns and Conceptual Message Wrapper (CMW) encoding formats before exchanging Exported Authenticator messages.¶
An HTTP binding in which protocol messages are carried as Capsules [RFC9297] over an HTTP connection established using the Extended CONNECT method [RFC8441] [RFC9220].¶
A direct TLS and DTLS 1.3 binding, referred to as Shim Mode, for use cases where the protocol is run directly over the secure transport without an HTTP binding.¶

In the HTTP binding, the client sends an Extended CONNECT request using the upgrade token "exported-authenticator". Once the connection has been established, both peers exchange protocol messages as Capsules on the resulting HTTP stream. This design supports both HTTP/2 and HTTP/3 and allows the Exported Authenticator exchange to be multiplexed with other application traffic.¶

The protocol supports re-attestation on an HTTPS connection. Either peer may request a fresh Exported Authenticator at any time. However, re-attestation is not supported in Shim Mode.¶

1.1. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

"TLS" refers to TLS 1.3 and DTLS 1.3 unless otherwise specified. References to TLS connections, exporters, and Exported Authenticators apply equally to DTLS as defined in [RFC9261]. In the context of Shim Mode (Section 7), "TLS" also encompasses DTLS.¶
The term "terminate the connection" refers to closing the underlying secure transport connection carrying this protocol.¶

2. Protocol Overview

The client initiates the protocol using one of the two bindings defined in this document:¶

In the TLS binding (Section 7), the client establishes a TLS connection with the server. The attestation exchange begins immediately after the TLS handshake completes, with no additional connection setup step.¶
In the HTTP binding (Section 4), the client sends an Extended CONNECT request with the HTTP upgrade token "exported-authenticator" and the Capsule-Protocol header field set to true. The server signals acceptance with a 2xx response that also includes the Capsule-Protocol header field.¶

If attestation features are used, once the connection is established, the server sends an auth_capabilities (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) message advertising its supported attestation models and CMW types. The client replies with an auth_capabilities message containing its selected attestation model and CMW type chosen from the server's advertised list. If no common attestation model or CMW type exists, the client sends an auth_error (EXPAT_AUTH_ERROR Capsule in the HTTP binding) message and terminates the connection.¶

Once capabilities are exchanged successfully, either peer may act as Initiator and send an auth_request (EXPAT_AUTH_REQUEST Capsule in the HTTP binding) message at any time. The other peer (the Responder) replies with either an authenticator (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) message or an auth_error (EXPAT_AUTH_ERROR Capsule in the HTTP binding) message.¶

Server                                   Client
  |                                        |
  | [TLS binding]                          |
  |<===TLS Handshake======================>|
  |                                        |
  |   [if attestation features are used]   |
  |                                        |
  +----auth_capabilities------------------>|
  |<---auth_capabilities-------------------+
  |                                        |
  |   [either peer may now initiate]       |
  |                                        |
  |<---auth_request(id=1) -----------------+
  +----authenticator(id=1) --------------->|
  |                                        |
  +----auth_request(id=0x8001) ----------->|
  |<---authenticator(id=0x8001) -----------+

Figure 1: Protocol overview: TLS binding (Shim Mode)

Server                                   Client
  |                                        |
  | [HTTP binding]                         |
  |<---Extended CONNECT (upgrade token)----+
  +----200 OK (Capsule-Protocol: ?1)------>|
  |                                        |
  |   [if attestation features are used]   |
  |                                        |
  +----EXPAT_AUTH_CAPABILITIES Capsule---->|
  |<---EXPAT_AUTH_CAPABILITIES Capsule-----+
  |                                        |
  |   [either peer may now initiate]       |
  |                                        |
  |<---EXPAT_AUTH_REQUEST(id=1) -----------+
  +----EXPAT_AUTHENTICATOR(id=1) --------->|
  |                                        |
  +----EXPAT_AUTH_REQUEST(id=0x8001) ----->|
  |<---EXPAT_AUTHENTICATOR(id=0x8001) -----+

Figure 2: Protocol overview: HTTP binding

3. Message Definitions

All structures use the presentation language of TLS 1.3 [RFC8446]. All multi-byte integers are in network byte order.¶

A peer MUST NOT have more than one outstanding AuthenticatorRequest in each direction at any time. A peer awaiting a response MUST be prepared to receive and process an AuthenticatorRequest from the other peer. A peer MUST treat any message that does not conform to the sequencing and matching rules defined in this document, or that does not match an outstanding request where required, as a protocol_error.¶

3.1. AuthMessageType

enum {
    auth_request(1),
    authenticator(2),
    auth_error(3),
    auth_capabilities(4),
    (255)
} AuthMessageType;

Values 5-254 are unassigned and available for future assignment via the IANA registry defined in Section 9.4. The AuthMessageType enum applies to the Shim Mode framing (Section 7) and DTLS binding (Section 6); in the HTTP binding, message type discrimination is performed by the Capsule Type field instead (see Section 9.2).¶

3.2. AuthCapabilities

enum {
    background_check(1),
    passport(2),
    (255)
} AttestationModel;

opaque cmw_type<1..255>;

struct {
    AuthMessageType  msg_type;             /* auth_capabilities(4)  */
    AttestationModel models<1..255>;       /* RATS models           */
    cmw_type         cmw_types<1..2^16-1>; /* CMW media types       */
} AuthCapabilities;

If attestation-related features defined in [I-D.fossati-seat-expat] are to be used, the server MUST send an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) immediately after accepting the Extended CONNECT request (i.e., after sending the 2xx response) in the HTTP binding, or immediately after the TLS handshake completes in Shim Mode, before any other message. The client MUST reply with its own AuthCapabilities message before sending any other message.¶

Whether attestation features are used on a given connection is determined by the TLS-layer negotiation defined in [I-D.fossati-seat-expat], specifically via the TLS flag registered in that document. A server MUST NOT send an AuthCapabilities message on a connection where that TLS flag was not negotiated during the TLS handshake.¶

Both fields MUST be non-empty. A peer that receives an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) with an empty models or cmw_types field MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection.¶

The cmw_types field contains a vector of UTF-8 media type strings (e.g., "application/cmw+cbor"), each individually length-prefixed as defined by the cmw_type type above.¶

The AuthCapabilities message sent by the client conveys the selected attestation model and CMW type for the connection. The client MUST select a single attestation model and a single CMW type from the server's advertised lists and include only the selected values in its AuthCapabilities message.¶

If the client does not support any attestation model or CMW type advertised by the server, it MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection.¶

If the client selects an attestation model or CMW type that was not advertised by the server, the server MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection.¶

A peer that sends an AuthCapabilities message and does not receive a corresponding response MUST treat this as a protocol_error and terminate the connection. This rule applies to the HTTP binding and Shim Mode over TLS 1.3; the analogous behaviour for Shim Mode over DTLS 1.3 is described in Section 6.¶

If the AuthCapabilities exchange is omitted, peers MUST NOT use attestation-related features defined in [I-D.fossati-seat-expat].¶

A peer that receives an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) outside of the initial capability exchange MUST treat it as a protocol_error.¶

A client that requires attestation and does not receive an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) as the first message from the server MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection. When determining whether an AuthCapabilities message was received as the first message, unknown Capsule Types that are silently ignored per [RFC9297] MUST NOT be counted.¶

3.3. AuthenticatorRequest

struct {
    AuthMessageType msg_type;          /* auth_request(1)     */
    uint16          request_id;        /* request identifier  */
    opaque          authenticator_request<1..2^24-1>;
                                       /* certificate request */
} AuthenticatorRequest;

The authenticator_request field contains a CertificateRequest or ClientCertificateRequest message encoded as a TLS handshake message, as defined in [RFC9261].¶

The request_id is used to correlate protocol messages, while the certificate_request_context contained within authenticator_request is used by [RFC9261] for binding the resulting Authenticator.¶

3.3.1. Request ID

The request_id namespace is split on the high bit to avoid collision when both peers initiate requests concurrently:¶

Client-initiated requests: 0x0001 to 0x7FFF¶
Server-initiated requests: 0x8001 to 0xFFFF¶
0x0000 and 0x8000 are reserved for use in AuthError messages (EXPAT_AUTH_ERROR Capsules in the HTTP binding) when no specific request is implicated. A Client MUST use 0x0000 and a Server MUST use 0x8000 for these messages. Any AuthError message received during the AuthCapabilities exchange MUST use these reserved values.¶

A receiver that receives an AuthError message with a reserved request_id that does not correspond to the sender's role (i.e., 0x0000 from the server or 0x8000 from the client) MUST treat it as a protocol_error and terminate the connection.¶

The Initiator MUST NOT reuse a request_id that is currently pending, except when retransmitting a request over DTLS 1.3 as described in Section 6. When the maximum value in its range is reached, the Initiator wraps around within its assigned range and MUST select the next request_id that is not currently in use by a pending request.¶

3.4. AuthenticatorResponse

struct {
   AuthMessageType msg_type;                      /* authenticator(2) */
   uint16          request_id;
   opaque          authenticator_blob<1..2^24-1>; /* RFC 9261         */
                                                  /* Authenticator    */
} AuthenticatorResponse;

The request_id MUST match the corresponding AuthenticatorRequest.¶

The authenticator_blob contains the Authenticator structure. When used with [I-D.fossati-seat-expat], the Certificate message within the Authenticator carries the cmw_attestation extension.¶

A receiver that receives an AuthenticatorResponse message (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) when no request is outstanding, or with a request_id that does not match any outstanding request, MUST treat it as a protocol_error.¶

A receiver that receives more than one AuthenticatorResponse message (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) for the same request_id MUST treat it as a protocol_error.¶

The Initiator MUST verify the Authenticator as specified in [RFC9261] and abort the request if verification fails.¶

3.5. AuthError

enum {
    protocol_error(1),
    authenticator_failed(2),
    request_id_conflict(3),
    internal_error(4),
    attestation_service_unavailable(5),
    attestation_validation_failed(6),
    attestation_policy_violation(7),
    (255)
} AuthErrorCode;

struct {
    AuthMessageType msg_type;    /* auth_error(3)                        */
    uint16          request_id;  /* 0x0000 (client) or 0x8000 (server)  */
                                 /* if no request is implicated          */
    AuthErrorCode   error_code;
} AuthError;

AuthError messages (EXPAT_AUTH_ERROR Capsules in the HTTP binding) are bidirectional: either peer may send one at any time.¶

Error code semantics:¶

protocol_error(1):: A message was malformed, received out of sequence, or violated a requirement of this specification (including capability mismatch at session setup).¶
authenticator_failed(2):: The sender was unable to produce a valid Authenticator because the required attestation Evidence could not be collected.¶
request_id_conflict(3):: The received request_id is already in use for an outstanding request (e.g., due to protocol violation or peer misbehavior).¶
internal_error(4):: An unrecoverable internal error occurred that prevents further processing of the protocol.¶
attestation_service_unavailable(5):: The attestation service (TEE or Verifier) is unreachable or timed out.¶
attestation_validation_failed(6):: A cryptographic check on the received Authenticator failed (e.g., signature invalid or Attestation Binder mismatch).¶
attestation_policy_violation(7):: The Authenticator is cryptographically valid but does not satisfy the Relying Party's attestation policy.¶

Upon sending or receiving an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with any error_code other than attestation_service_unavailable(5), the peer MUST terminate the connection immediately.¶

If the error_code is attestation_service_unavailable(5), the connection MAY remain open as the failure is transient. The initiator MUST retry with a new AuthenticatorRequest message (EXPAT_AUTH_REQUEST Capsule in the HTTP binding) using a new request_id. The initiator MUST apply an exponential backoff strategy between retries to avoid overwhelming the attestation service.¶

A receiver that receives an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with a request_id that does not correspond to any outstanding request and is not a reserved value (0x0000 or 0x8000) MUST terminate the connection immediately. Any AuthError message sent with a reserved request_id (0x0000 or 0x8000) MUST be treated as a session-level error and results in immediate termination.¶

4. HTTP Binding

4.1. HTTP Upgrade Token

The HTTP upgrade token defined by this document is:¶

exported-authenticator

This token is registered in the "HTTP Upgrade Token Registry" as defined in Section 9.1.¶

4.2. Connection Establishment

The client initiates the protocol by sending an Extended CONNECT request [RFC8441][RFC9220] with the following pseudo-header fields and header fields:¶

:method    = CONNECT
:protocol  = exported-authenticator
:scheme    = https
:path      = <configured path, e.g. /.well-known/expat/>
:authority = <server authority>
Capsule-Protocol: ?1

The server MUST respond with a 2xx (successful) response that also includes:¶

Capsule-Protocol: ?1

If the server does not support the "exported-authenticator" upgrade token, it MUST respond with a 4xx or 5xx response. The client MUST treat any non-2xx response as a failure and MUST NOT send any Capsules on the stream.¶

Once a 2xx response has been received, both client and server switch to the Capsule Protocol [RFC9297] on the HTTP stream. All subsequent bytes on that stream are Capsules as defined in Section 3.2 of [RFC9297].¶

4.3. Capsule Framing

Each protocol message defined in Section 3 MUST be sent as exactly one Capsule. The Capsule Type field identifies the message type as specified in Section 9.2. The Capsule Value field contains the body of the message: all fields of the relevant struct from Section 3, excluding the msg_type field, which is replaced by the Capsule Type.¶

Unknown Capsule Types MUST be silently ignored per Section 3.2 of [RFC9297]. This provides forward compatibility: future extensions MAY define new Capsule Types without requiring version negotiation.¶

4.4. Capsule Type to Message Mapping

The following table maps Capsule Type names to the protocol messages defined in Section 3:¶

Table 1
Capsule Type Name	Protocol Message
EXPAT_AUTH_REQUEST	AuthenticatorRequest
EXPAT_AUTHENTICATOR	AuthenticatorResponse
EXPAT_AUTH_ERROR	AuthError
EXPAT_AUTH_CAPABILITIES	AuthCapabilities

Capsule Type values are assigned in the IANA registry defined in Section 9.2.¶

4.5. Bidirectionality

After the connection is established, both client and server MAY send any Capsule Type at any time, subject to the sequencing and request_id rules in Section 3. Either peer MAY initiate an EXPAT_AUTH_REQUEST Capsule, consistent with the request_id namespace split defined in Section 3.¶

4.6. TLS Requirement

This protocol MUST be used only over TLS 1.3 or later versions. When operating over HTTP/3, TLS 1.3 is used internally by QUIC as specified in [RFC9001], satisfying this requirement. DTLS is not applicable to the HTTP transport; DTLS 1.3 is supported only for the Shim Mode defined in this document.¶

4.7. Operation over HTTP/2 and HTTP/3

When operating over HTTP/2 [RFC9113] or HTTP/3 [RFC9114], the Extended CONNECT mechanism is used as defined in [RFC8441] and [RFC9220], respectively. In both cases, the server MUST advertise the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with value 1 before the client MAY send an Extended CONNECT request with the "exported-authenticator" upgrade token.¶

4.8. Path Configuration

The path is carried in the :path pseudo-header field of the Extended CONNECT request. This document registers the well-known URI suffix "expat" (see Section 9.3), yielding the default path /.well-known/expat/.¶

6. DTLS 1.3 Considerations

When this protocol is used in Shim Mode over DTLS 1.3 [RFC9147], message loss and reordering may occur. In such environments, retransmission of messages may be required. The Capsule Protocol and the HTTP binding are not used over DTLS; all references in this section are to the Shim Mode framing defined in Section 7.¶

If a peer does not receive a response to an AuthCapabilities message, it MUST retransmit using the same exponential backoff and timeout mechanism as the DTLS handshake retransmission defined in [RFC9147]. If no response is received after the retransmission timeout expires, the peer MUST treat it as a protocol_error and terminate the connection.¶

If a peer does not receive a response (AuthenticatorResponse or AuthError) for an outstanding AuthenticatorRequest within an implementation-defined timeout, it MAY retransmit the request.¶

A retransmitted AuthenticatorRequest MUST use the same request_id and authenticator_request value as the original.¶

A receiver that receives a duplicate AuthenticatorRequest with the same request_id and identical authenticator_request value MUST treat it as a retransmission and MAY resend the corresponding AuthenticatorResponse.¶

A receiver that receives duplicate AuthenticatorResponse messages for the same request_id and identical authenticator_blob MUST treat them as retransmissions and ignore duplicates.¶

A receiver MUST ensure that retransmission does not result in multiple distinct cryptographic operations for the same request_id. To achieve this, the receiver SHOULD cache the generated AuthenticatorResponse for a period sufficient to handle potential retransmissions. If a duplicate AuthenticatorRequest is received, the cached AuthenticatorResponse SHOULD be returned.¶

Fatal AuthError messages require best-effort coordinated termination. A peer that receives a fatal AuthError MUST stop sending application data and SHOULD send a close_notify alert. The sender of a fatal AuthError MAY retransmit the error if it continues to receive any records from the peer. If no records are received for a period exceeding the retransmission timeout, the sender SHOULD assume the peer has terminated and terminate the connection locally.¶

9. IANA Considerations

9.1. HTTP Upgrade Token Registration

IANA is requested to register the following entry in the "HTTP Upgrade Token Registry" defined in Section 16.7 of [RFC9110]:¶

Value:: exported-authenticator¶
Description:: Exported Authenticator Transport¶
Expected Version Tokens:: None¶
Reference:: This document¶

9.2. HTTP Capsule Types

IANA is requested to register the following entries in the "HTTP Capsule Types" registry defined in Section 5.4 of [RFC9297].¶

Registration policy: Specification Required.¶

Table 2
Value	Capsule Type Name	Reference
TBD1	EXPAT_AUTH_REQUEST	This document
TBD2	EXPAT_AUTHENTICATOR	This document
TBD3	EXPAT_AUTH_ERROR	This document
TBD4	EXPAT_AUTH_CAPABILITIES	This document

9.3. Well-Known URI Registration

IANA is requested to register the following Well-Known URI in the "Well-Known URIs" registry defined in [RFC8615]:¶

URI Suffix:: expat¶
Change Controller:: IETF¶
Specification Document:: This document¶
Related Information:: For use with the "exported-authenticator" HTTP upgrade token.¶

9.4. AuthMessageType Registry

IANA is requested to create a new registry "Transport Message Types" under a new "Exported Authenticator Transport" registry group.¶

This registry maps conceptual message type names to their struct definitions, for use in the Shim Mode framing (Section 7) and DTLS binding (Section 6). In the HTTP binding, message type discrimination is performed by the Capsule Type field; see Section 9.2.¶

Registration policy: Specification Required for values 5-254.¶

Table 3
Value	Name	Reference
0	Reserved	This document
1	auth_request	This document
2	authenticator	This document
3	auth_error	This document
4	auth_capabilities	This document
5-254	Unassigned
255	Reserved	This document

9.5. AuthErrorCode Registry

IANA is requested to create a new registry "Error Codes" under the same registry group.¶

Registration policy: Specification Required for values 8-191; Private Use for 192-254.¶

Table 4
Value	Name	Reference
0	Reserved	This document
1	protocol_error	This document
2	authenticator_failed	This document
3	request_id_conflict	This document
4	internal_error	This document
5	attestation_service_unavailable	This document
6	attestation_validation_failed	This document
7	attestation_policy_violation	This document
8-191	Unassigned (Specification Required)
192-254	Private Use
255	Reserved	This document

9.6. Attestation Model Registry

IANA is requested to create a new registry "Attestation Models" under the same registry group.¶

Registration policy: Specification Required for values 3-254.¶

Table 5
Value	Name	Reference
0	Reserved	This document
1	background_check	This document
2	passport	This document
3-254	Unassigned (Specification Required)
255	Reserved	This document

References

Normative References

[I-D.fossati-seat-expat]: Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Exported Authenticators", Work in Progress, Internet-Draft, draft-fossati-seat-expat-02, 26 February 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-seat-expat-02>.
[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>.
[RFC8441]: McManus, P., "Bootstrapping WebSockets with HTTP/2", RFC 8441, DOI 10.17487/RFC8441, September 2018, <https://www.rfc-editor.org/rfc/rfc8441>.
[RFC8446]: Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8615]: Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9001]: Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9113]: Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/rfc/rfc9113>.
[RFC9114]: Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
[RFC9147]: Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9220]: Hamilton, R., "Bootstrapping WebSockets with HTTP/3", RFC 9220, DOI 10.17487/RFC9220, June 2022, <https://www.rfc-editor.org/rfc/rfc9220>.
[RFC9261]: Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 2022, <https://www.rfc-editor.org/rfc/rfc9261>.
[RFC9297]: Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, <https://www.rfc-editor.org/rfc/rfc9297>.

Informative References

[I-D.draft-ietf-httpbis-secondary-server-certs]: Gorbaty, E. and M. Bishop, "Secondary Certificate Authentication of HTTP Servers", Work in Progress, Internet-Draft, draft-ietf-httpbis-secondary-server-certs-02, 17 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-secondary-server-certs-02>.
[STET]: Google LLC, "STET: Split-Trust Encryption Tool", n.d., <https://github.com/GoogleCloudPlatform/stet>.