Home»Documents»IAB Correspondence, Reports, and Selected Documents»2017»IAB Statement on OCSP Stapling
1 February 2017
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>.