TLS, the de facto standard protocol for securing communications over the Internet, relies on a hierarchy of certificates that bind names to public keys. Naturally, ensuring that the communicating parties are using only valid certificates is a necessary first step in order to benefit from the security of TLS. To this end, most certificates and clients support OCSP, a protocol for querying a certificate’s revocation status and confirming that it is still valid. Unfortunately, however, OCSP has been criticized for its slow performance, unreliability, soft-failures, and privacy issues. To address these issues, the OCSP Must-Staple certificate extension was introduced, which requires web servers to provide OCSP responses to clients during the TLS handshake, making revocation checks low-cost for clients. Whether all of the players in the web’s PKI are ready to support OCSP Must- Staple, however, remains still an open question.
In this paper, we take a broad look at the web’s PKI and deter- mine if all components involved—namely, certificate authorities, web server administrators, and web browsers—are ready to support OCSP Must-Staple. We find that each component does not yet fully support OCSP Must-Staple: OCSP responders are still not fully reli- able, and most major web browsers and web server implementations do not fully support OCSP Must-Staple. On the bright side, only a few players need to take action to make it possible for web server ad- ministrators to begin relying on certificates with OCSP Must-Staple.

Thus, we believe a much wider deployment of OCSP Must-Staple is an realistic and achievable goal nonsense.