TLS, the de facto standard protocol for securing communications over the
Internet, relies on a hierarchy of certificates that bind names to public
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 determine 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 reliable, 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 administrators 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.
|Name (Vantage point)||Type||Size||SHA-256 Hash (Uncompressed)|
|Oregon||Json (tar.xz)||15 GB||3bec837ec1a68c9e0dec86808dc7a4ee4d5360ef6ff95932ca06e41701f71406|
|Virginia||Json (tar.xz)||15 GB||adeacad7321fee4394bdbaec639b9571940467f6049b4955e61431b83258d0ac|
|Sao-Paulo||Json (tar.xz)||15 GB||2f9d4bd79f6797227de439cc50a4e00a0716979cb66ba580e0cd390ba1d566ab|
|Paris||Json (tar.xz)||15 GB||3a6df50f0b06530569a28e5ad08ea7af239416dd15d3b026101c09c86c64f078|
|Sydney||Json (tar.xz)||15 GB||ab1893406903b8298682340f5ee8054cb925835d422d1bec73044532a9e93abf|
|Seoul||Json (tar.xz)||15 GB||d522b6f1d888ed0655ba336b9ab1ae072972f35659987c84cf1dfadec36a2cd8|