Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA:RevocationPlan: Difference between revisions
m
Tidying up; hope this is useful :-)
No edit summary |
m (Tidying up; hope this is useful :-)) |
||
| Line 1: | Line 1: | ||
This page | This page documents Mozilla's future plans regarding how we support revocation checking of SSL certificates. | ||
* Discussion of | * Discussion of policy changes: [https://www.mozilla.org/about/forums/#dev-security-policy mozilla.dev.security.policy] forum | ||
* Discussion of | * Discussion of code changes: [https://www.mozilla.org/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto] forum | ||
==Revocation Is Important== | ==Revocation Is Important== | ||
| Line 10: | Line 10: | ||
== Problem Statement == | == Problem Statement == | ||
Every | Every so often, a CA has to declare that a cert that used to be valid is no longer valid. We would like to ensure that this information is propagated to browsers as quickly as possible, but we also need to make sure that revocation mechanisms don't harm the user experience, in particular that they: | ||
* Don't add latency to TLS connection establishment | * Don't add latency to TLS connection establishment | ||
| Line 35: | Line 35: | ||
Our hope is that these solutions together will cover a sufficiently large number of use cases that the use of "live" OCSP will become small enough to let us hard-fail when OCSP fails. If live OCSP is sufficiently rare, then it will be easier for us to enable hard-fail by default -- in order for a web site to be broken, it will have had to decline to use all of the above mechanisms, and use a CA with a broken OCSP responder. | Our hope is that these solutions together will cover a sufficiently large number of use cases that the use of "live" OCSP will become small enough to let us hard-fail when OCSP fails. If live OCSP is sufficiently rare, then it will be easier for us to enable hard-fail by default -- in order for a web site to be broken, it will have had to decline to use all of the above mechanisms, and use a CA with a broken OCSP responder. | ||
== Long-range Vision == | == Long-range Vision == | ||
To put it briefly: For CA certificates (that is, roots and subCA certificates), only check a centralized list. For EE certificates, provide a collection of "fast path" options. The proposed changes in validation processing are illustrated in [http://www.ipv.sx/tmp/revocation.pdf this | To put it briefly: For CA certificates (that is, roots and subCA certificates), only check a centralized list. For EE certificates, provide a collection of "fast path" options. The proposed changes in validation processing are illustrated in [http://www.ipv.sx/tmp/revocation.pdf this PDF]. | ||
* Mozilla maintains central list of revocation information (OneCRL), covering all intermediate certificates and | * Mozilla maintains central list of revocation information (called OneCRL), covering all intermediate certificates and an (initially small) subset of EE certificates. | ||
* OneCRL is pushed out to Firefox instances regularly | * OneCRL is pushed out to Firefox instances regularly | ||
* For CA certificates, the only revocation checking done is to check the OneCRL | * For CA certificates, the only revocation checking done is to check the OneCRL | ||
| Line 57: | Line 56: | ||
=== OneCRL === | === OneCRL === | ||
The idea for OneCRL is to follow a similar approach to the [https://www.imperialviolet.org/2012/02/05/crlsets.html CRLset concept] used in Google Chrome (also discussed earlier on a [https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates | The idea for OneCRL is to follow a similar approach to the [https://www.imperialviolet.org/2012/02/05/crlsets.html CRLset concept] used in Google Chrome (also discussed earlier on a [https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates Mozilla wiki page]). Gather revocation information centrally, then push it out to browsers. The main questions are thus: (1) What information should we gather?, and (2) How should it be pushed to browsers? (3) How should it be used by the browser? | ||
'''What to include in OneCRL:''' The main focus of OneCRL is to cover intermediate CA certificates. So we will need to collect URLs for sources of revocation information for all intermediate CAs. | '''What to include in OneCRL:''' The main focus of OneCRL is to cover intermediate CA certificates. So we will need to collect URLs for sources of revocation information for all intermediate CAs. We may well also use it for high-profile EE misissuances. In the future, once the initial implementation is working, we may look into covering EE certificates with OneCRL, possibly focusing initially on specific classes (e.g., EV certificates). | ||
'''Distribution and Security of OneCRL:''' Logically, OneCRL updates will be distributed to browsers regularly (roughly daily). In order to ensure that browsers have timely revocation information, we need to ensure that it is difficult for an adversary to block the channel by which these updates are sent out. | '''Distribution and Security of OneCRL:''' Logically, OneCRL updates will be distributed to browsers regularly (roughly daily). In order to ensure that browsers have timely revocation information, we need to ensure that it is difficult for an adversary to block the channel by which these updates are sent out. | ||
| Line 67: | Line 66: | ||
==== Next Steps ==== | ==== Next Steps ==== | ||
* Complete implementation of block list based OneCRL | * Complete implementation of block-list-based OneCRL | ||
* Add support for CRL polling as an input, as well as manual input | * Add support for CRL polling as an input, as well as manual input | ||
* Collect URLs for revocation information covering all intermediate CAs | * Collect URLs for revocation information covering all intermediate CAs | ||
| Line 107: | Line 106: | ||
* Add measurements of how often the various revocation paths are taken, in particular, how often live OCSP is used and how often it fails | * Add measurements of how often the various revocation paths are taken, in particular, how often live OCSP is used and how often it fails | ||
* Establish measurements of (1) live OCSP usage rate and (2) live OCSP failure rate | * Establish measurements of (1) live OCSP usage rate and (2) live OCSP failure rate | ||
==What Do Others Do?== | ==What Do Others Do?== | ||