Summary

  • TLS 1.3 uses certificate_request_context to associate a client's authentication block with a particular CertificateRequest, especially when post-handshake responses can arrive out of order. Connection-scoped uniqueness and unpredictability protect that protocol exchange; they do not define an application's authorization scope.
  • A defensible authentication receipt joins the TLS context and proof-of-possession result to separately attributable certificate-path policy, application principal, resource, decision, expiry and revocation evidence. The join must not allow the opaque context to stand in for those decisions.

Suppose a service sends two post-handshake certificate requests over a long-lived connection. Its implementation labels one request “billing” and the other “administration” in local memory, then puts the same opaque values into certificate_request_context. The client answers both. Months later, an audit log contains only the context and a successful TLS result. Can a reviewer conclude that the holder was authorized to administer the service? No. The log can show which cryptographic response belonged to which request; the application labels and the policy decision have disappeared.

RFC 9846, the July 2026 Proposed Standard for TLS 1.3, gives the field a specific protocol role. A CertificateRequest contains an opaque certificate_request_context followed by extensions describing the requested authentication parameters. The client echoes that context in its Certificate response. The value lets the server match a response to the request that produced it.

The field can contain up to 255 octets. Within one connection, each context must be unique. That rule prevents a client CertificateVerify from being replayed as the answer to another request on the same connection. In the main handshake the context is required to be empty. A non-empty value belongs to the post-handshake authentication use described by the standard.

For a post-handshake request, the server should also make the context unpredictable to the client. Random generation is the obvious example. The purpose is again cryptographic: an attacker with temporary access to the client's private key should not be able to prepare valid CertificateVerify messages in advance for predictable future requests. Unpredictability protects the response binding; it does not make the random bytes a secret capability or a business permission.

The distinction matters because opaque values invite local meaning. A team can choose to associate a context with a workflow step in volatile state, but that association is outside TLS. Another deployment could generate the same length of random value and use it for a completely different request. Uniqueness is scoped to the connection, not to an organization, account, resource or lifetime. Nothing in the field declares a tenant, role, purpose or sensitivity label.

The request's extensions carry TLS parameters. signature_algorithms is mandatory. Other extensions can communicate acceptable certificate authorities, object-identifier filters or certificate signature constraints. These shape what authentication material the peer may return. Even a richly constrained request is not an application access policy. Selecting an acceptable signature scheme or issuer is not the same decision as permitting a named operation on a named resource.

The client's response has its own ordered authentication block. If the client chooses to authenticate after a permitted post-handshake request, it sends Certificate, CertificateVerify and Finished. CertificateVerify proves possession of the private key corresponding to the certificate and protects the relevant handshake transcript. Finished confirms the authentication block under the TLS state. These are strong facts, but their strength does not expand their subject matter.

A client can also decline by sending an empty Certificate followed by Finished. That response is unambiguous at the TLS layer: the client supplied no certificate for this request. It is not automatically an application logout, refusal of consent or durable denial of access. The application protocol must decide whether anonymous operation is allowed, whether another credential can be used, or whether the connection should be closed.

Post-handshake timing explains why correlation is necessary. The client might need to prompt a person or contact a credential device, so the server must tolerate delay and unrelated messages. A client receiving several requests in quick succession can answer them in a different order. The unique context allows the server to disambiguate the responses without treating wire order as identity.

The capability is conditional. A server may request post-handshake certificate authentication only when the client advertised the empty post_handshake_auth extension. If it did not, the request is an unexpected message and causes a fatal alert. Yet even a valid capability advertisement is not permission from every higher protocol to use the feature.

RFC 9113 makes the separation concrete. HTTP/2 servers must not send post-handshake TLS 1.3 CertificateRequest, and clients treat one as a connection error. The prohibition applies even when the client offered post_handshake_auth, because that capability can have been advertised independently for other application protocols. A TLS possibility does not override HTTP/2's connection and multiplexing rules.

Certificate validity is another independent layer. RFC 5280 describes path validation as verifying a binding between a subject name or alternative name and a public key, subject to certificate constraints, a chosen trust anchor and relying-party inputs. Trust-anchor selection is policy, and an application can further restrict otherwise valid paths. Echoing the correct request context does not perform those local choices by itself.

Possession, identity and authorization should therefore remain separate predicates. CertificateVerify can establish that the responding endpoint controls a private key. Path processing can establish that a selected trust framework binds that key to a certified name under specified constraints. An application can then map that result to a principal and decide what that principal may do. Failure at any later predicate cannot be repaired by the earlier context match.

RFC 9525 illustrates how application protocols have to define service-identity verification when using TLS. Its principal subject is server identity, not a universal client authorization model. The broader lesson is structural: TLS offers authentication mechanisms, while the usage profile specifies the identity reference and the consequences of a match.

OAuth mutual TLS provides an application example without changing the TLS rule. RFC 8705 distinguishes mutual-TLS client authentication from certificate-bound access tokens. An authorization server applies policy for a registered client_id, checks the presented certificate against expected credentials, and can bind a token to proof of possession. At a resource server, the token remains the vehicle for the authorization decision. The TLS certificate alone need not define the permitted resource.

That framework also shows why scope must not be smuggled into the context. RFC 6749 defines authorization grants, access tokens and scope in the OAuth layer. RFC 7662 defines introspection information, including whether a token is active. A request context does not carry the token's audience, privileges, expiry or current active state.

The context is equally unsuited to session duration. A successful post-handshake authentication occurs at a point on one TLS connection. Whether an application starts a session, elevates it, applies the result only to future requests, revisits previous requests or expires the elevation after a minute are application choices. Reusing the context as a session identifier obscures when the permission began, what it covered and how it ended.

Multiplexing makes that ambiguity dangerous. Several application operations can be in flight while one post-handshake authentication is pending. The TLS request is connection-level. Without an explicit application rule, a server cannot infer which streams or requests may benefit from the later identity result. HTTP/2 avoids the problem by prohibiting the exchange; another protocol that permits it must supply its own transition boundary.

Revocation and freshness cannot be inferred either. A certificate path may be acceptable at validation time, but local policy decides what revocation evidence to consult. An access token can become inactive before its nominal expiry. A cached principal mapping can change. The opaque context records none of these clocks, and its connection-scoped uniqueness does not make old policy current.

RFC 9325 provides recommendations for secure TLS use and deployment. Such guidance can improve protocol configuration, but it does not define a universal business authorization model. The IANA TLS Parameters registry likewise assigns vocabulary and code points; registry presence does not certify how a deployment maps a certificate to access.

For version provenance, the RFC 9846 publication record identifies the current standard and the RFC 9846 errata page is the place to check later corrections. RFC 8446 preserves the specification that RFC 9846 obsoletes. These sources let an auditor name the text used. They do not support a claim about vendor adoption, observed incidents or a particular deployment.

Sources