Confirmed users, Administrators
5,526
edits
CA:ImprovingRevocation: Difference between revisions
→Change Name
| Line 204: | Line 204: | ||
* Process Change: To be determined. | * Process Change: To be determined. | ||
=== OCSP Must-Staple === | |||
Websites that implement Must-Staple will get Hard Fail Revocation. | |||
[http://www.ietf.org/mail-archive/web/tls/current/msg10323.html IETF is working on a standardized must-staple mechanism], but it will be a long time before all CAs in our program have deployed that extension in all of the certificates they issue. | |||
As an interim measure, we plan to implement a must-staple mechanism that any website can deploy that does not require the cooperation of any CA. The mechanism will be based on a Must-Staple HTTP header, analogous to the Strict-Transport-Security and the Public-Key-Pins mechanism being worked on in the IETF. For example, “Must-Staple: max-age=10886400; includeSubdomains” in a response to an HTTPS request on a connection with a valid certificate and a stapled OCSP response would cause the browser to reject any TLS handshake for that domain (and all subdomains) that does not include a stapled OCSP response. | |||
This mechanism would suffer from the same first-visit problem that Strict-Transport-Security and Public-Key-Pins suffer from, but we can mitigate all these issues through the preloaded list mechanism that we're already using for HSTS. | |||
http://www.ietf.org/mail-archive/web/tls/current/msg10351.html | |||
* Discussion: ''Link to Discussion Thread'' | |||
* Code Change: ''Bugzilla Bug Number'' | |||
* Dependencies: OCSP Stapling | |||
* Policy Change: To be determined. | |||
* Process Change: To be determined. | |||
=== ''Change Name'' === | === ''Change Name'' === | ||