IAB Statement on OCSP Stapling
In the public key infrastructure used for the World Wide Web, the
browser needs to check the revocation status of the server's
certificate [RFC5280] to ensure that it has not been revoked by
the Certification Authority (CA) before it expired.
Over the past few years, several techniques have been tried by CAs and
browser vendors to make certificate status checking more efficient. Of
these techniques, Online Certificate Status Protocol (OCSP) Stapling
offers an efficient solution, and it also offers improved privacy for
the browser user.
OCSP is specified in [RFC6960]. The TLS Certificate Status Request
extension is defined [RFC6066], which provides a time-stamped OCSP
response in the TLS handshake. This technique is referred to as
"stapling" the OCSP response to the TLS handshake. The web server
periodically fetches an OCSP response for its own certificate, and then
includes it in each TLS handshake so that no browsers need to contact
the OCSP responder at all. OCSP stapling completely avoids the
latency associated with the browser fetching revocation status
information. This latency is one of the primary reasons that other
revocation status checking mechanisms are not used by browsers.
A web server can advertise that it will always provide an OCSP response
for its certificate with the TLS Feature certificate extension [RFC7633].
The web server administrator must request that the CA include this
extension in the certificate. This creates a dependency on the CA to
provide OCSP responses whenever they are needed.
If every browser that connects to a high volume website performs its own
OCSP lookup, the OCSP responder must handle a real-time response to every
browser. OCSP stapling can avoid enormous volumes of OCSP requests for
certificates of popular websites, so stapling can significantly reduce
the cost for a CA to provide an OCSP service.
An OCSP response includes a time that the relying party should expect
to find the next update. As a result, a compromised private key can be
used by an attacker until the next update occurs. The CA needs to
balance the duration of potential exposure against the frequency of
issuing Certificate Revocation Lists (CRLs) [RFC5280] and OCSP
responses.
If a browser fetches its own certificate status information, the browser
can reveal the web sites that the browser user is visiting to the OCSP
Responder or the server providing the CRL. OCSP Stapling eliminates this
privacy concern because web servers are the only ones communicating
directly with the OCSP responder.
Many web sites are taking advantage of OCSP stapling. Today, browser
vendors report that less than 20% of TLS-protected transactions use OCSP
stapling. The IAB encourages all web servers to employ TLS to protect
their content, and use OCSP stapling to improve the efficiency and
privacy of revocation checking.
References:
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[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,
<http://www.rfc-editor.org/info/rfc6960>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension" RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>.
