Summary

  • OCSP stapling allowed a server to deliver a third party's signed certificate-status response during TLS negotiation. Delivery moved; the authority to sign the response and the client's responsibility to verify it did not.
  • Reusable status reduced the need for another connection, but required freshness checks and renewal work. Certificate-declared support could make a missing staple consequential, at the price of coupling certificate deployment to the availability of its status evidence.

Evidence from the party being examined

Consider a server presenting its certificate to a client. Alongside it comes a statement about that certificate's revocation status. The server delivered both entities. Why should the second be any more reassuring than the server's own claim that everything is fine?

Because delivery is not authorship. The statement is an OCSP response, signed by an authority the client must recognize as entitled to answer for that certificate. A compromised server possessing its ordinary TLS private key does not thereby acquire the authority to issue an acceptable status response. It can carry a signed statement; that does not make it the statement's issuer.

This distinction was the enabling idea behind OCSP stapling. The client could obtain useful evidence through the very party it was checking, provided the evidence could be verified independently of its courier. That avoided making every satisfactory check depend on a new client-side conversation with a certificate-status service.

A shorter route, already specified in 2003

The mechanism was present in June 2003's RFC 3546, section 3.6. A client could ask for status information through status_request; a server could send an OCSP response after its certificate. The specification connected this to constrained networks, saved round trips and avoiding the transfer of certificate revocation lists.

The 2011 account in RFC 6066 was therefore not the invention of stapling. It described the extension in the later TLS framework. In that handshake, a separate CertificateStatus message carried the response. The server transported a complete encoded entity, not a fresh assertion invented by the TLS exchange.

Putting status on that route could remove a separate visit to a third party. The privacy benefit was correspondingly specific: when a suitable staple satisfied the check, the visitor did not need that additional status query. It did not make the whole visit anonymous, nor did it eliminate the responder's continuing role in supplying status.

The word “good” did less than it appeared to

The entity being carried was narrower than a general certificate endorsement. RFC 6960, published in 2013, distinguished good, revoked and unknown. A good response did not necessarily establish that a certificate had ever been issued, let alone that the website was safe.

The client still had to check the answer's correspondence to the certificate, the signature and the signer's authority. Issuing CAs, explicitly trusted responders and appropriately designated responders were recognized cases; being the website was not one of them. Certificate-chain and other acceptance requirements were not replaced by a favourable status word.

Stapling thus separated three activities that a simple picture of “the server proves itself” conflates: producing the answer, carrying it and deciding whether it is sufficient. This division made reuse possible without giving the carrier discretion to rewrite the claim.

An answer that could travel also had an age

Reuse brought a second boundary. A signed answer may be authentic yet too old to rely on. It says something about a known state, not about every event occurring after that state was observed.

The lightweight profile in September 2007's RFC 5019 made pre-produced, distributed and cached responses part of a scalable design. That profile required nextUpdate and accurate time-based checks. This was a stronger rule than base OCSP, where that field could be absent. It should not be flattened into one universal description of all OCSP responses.

The names of the clocks matter. thisUpdate concerns when the indicated status was known to be correct; producedAt records signing; nextUpdate concerns when newer information will be available. Signing later is not the same as observing status later. An unsigned HTTP cache header cannot extend what the signed response allows a client to accept.

For an operator, a cache of acceptable answers could absorb a period when the responder was unreachable. But the protection lasted only while the held answers remained acceptable under the client's freshness rules. A later revocation did not magically alter copies already distributed. Reuse saved work by accepting a bounded separation between observation and use.

Silence was not a status response

The original extension left an uncomfortable ambiguity. A client could request a staple, yet the server could decline to provide one. That absence might mean lack of support; it might mean that a server using a compromised key preferred not to supply inconvenient evidence.

RFC 6066 explicitly described that problem in its security considerations. A client requiring OCSP validation should contact the responder itself or abort. A supplied response that failed checking was another case: it required aborting the handshake. No response, an unacceptable response and an explicit revocation were not equivalent observations.

October 2015's RFC 7633 addressed the expectation. A TLS Feature declaration inside the certificate could advertise status_request, forming the basis of what became known as Must-Staple. Supporting clients could then judge omission against a commitment authenticated with the certificate, rather than against the untrusted server's explanation.

That was not a universal mandate for every client to fail every connection without a staple. The RFC allowed alternative validation cases and did not require all clients to implement every declared feature. It did, however, give a server a concrete provisioning obligation. A newly issued certificate should not be activated before the necessary status token was available. Otherwise, a legitimate certificate could arrive at a client with an expectation the server could not fulfil.

The container changed; the division survived

TLS 1.3 changed where the entity travelled. Under RFC 8446, section 4.4.2.1, status was carried in an extension in the associated CertificateEntry, rather than the older standalone handshake message. The move did not make the server the status authority or make freshness irrelevant.

The historical bargain was therefore more durable than one message format: independently verifiable evidence could travel through an interested party, reducing a connection-time dependency while creating a continuing obligation to obtain and distribute usable evidence. These specifications establish that design, not a census of current client or CA support.

Sources

RFC 3546, RFC 6066, RFC 6960, RFC 5019, RFC 7633 and RFC 8446 provide the protocol record. The allocation of operating costs described here is an inference from those requirements, not a measured deployment claim.