CA:ImprovingRevocation: Difference between revisions

Jump to navigation Jump to search

CA:ImprovingRevocation (view source)

Revision as of 10:11, 18 November 2015

740 bytes removed ,  18 November 2015
Modified to update the status of OCSP must-staple
(Modified to update the status of OCSP must-staple)
Line 159: Line 159:
* Process Change: None
* Process Change: None


=== OCSP Must-Staple ===
Websites that implement OCSP Must-Staple will get Hard Fail Revocation.
A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.
[http://tools.ietf.org/html/rfc7633 The IETF have specified a standard mechanism], which is implemented in Firefox Nightly but currently off-by-default (see [https://bugzilla.mozilla.org/show_bug.cgi?id=901698 bug 901698]). It will be a long time before all CAs in our program have deployed that extension in all of the certificates they issue.
* Release: Mozilla 45
* Discussion: [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html ''Discussion Thread'']
* Code Change: {{Bug|901698}}, {{Bug|921907}}
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]], insanity::pkix {{Bug|915930}}
* Policy Change: To be determined.
* Process Change: To be determined.


=== ''Change Name'' ===
=== ''Change Name'' ===
Line 228: Line 247:


'''How''' to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?
'''How''' to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?
* Process Change: To be determined.
=== OCSP Must-Staple ===
Websites that implement OCSP Must-Staple will get Hard Fail Revocation.
A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.
[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: {{Bug|901698}}, {{Bug|921907}}
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]], insanity::pkix {{Bug|915930}}
* Policy Change: To be determined.


* Process Change: To be determined.
* Process Change: To be determined.
Mgoodwin
Confirmed users
81

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1106184"

Navigation menu