CA:RevocationPlan: Difference between revisions

CA:RevocationPlan (view source)

Revision as of 20:37, 3 September 2014

1,349 bytes removed , 3 September 2014

no edit summary

Richard Barnes

15

edits

@@ Line 1: / Line 1: @@
-{{draft}}
 This page will document Mozilla's future plans for revocation checking of SSL certificates.
@@ Line 61: / Line 59: @@
 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, with EE certificates covered as possible.  So we will need to collect URLs for sources of revocation information for all intermediate CAs.  For EE certificates, we will establish a process for selecting certain EE-issuing CAs to include.  This process will take into account the benefits of including a CA (e.g., the number of certs covered) and the costs (primariy the size of the CA).
+'''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.  In the future, we may look into covering EE certificates with OneCRL, possibly focusing initially on specific classes (e.g., EV certificates).
-<blockquote>
-'''NOTE:''' The current text on this page is written to cover the inclusion of EE certificates in OneCRL.  However, whether or not to include EE certificates in OneCRL is a major open issue, and comment is welcome.  We will definitely use OneCRL to handle CA revocations, but may choose not to cover EE certificates, because we will certainly not be able to cover them all.
-'''Pros:'''
-* Faster revocation for EE certificates covered by OneCRL
-* No action required by server operators; Mozilla platform and users can benefit immediately
-'''Cons:'''
-* CAs and certificate holders may feel penalized if they are not included
-* Coverage by OneCRL is a disincentive to deploying must-staple or short-lived certificates
-Any plan to include EE certificates in OneCRL will need to have an open, transparent, and neutral process for selecting which CRLs will go into OneCRL, in order to mitigate the "cons" above.  Note that regardless of the outcome of this decision, Mozilla may choose to include a small number of revoked EE certificates in OneCRL in exceptional cases.
-</blockquote>
-'''Distribution and Security of OneCRL:''' Logically, OneCRL updates will be distributed to browsers regulary (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.
-'''Format  and Usage of OneCRL:''' For CA certificates, we will include revocation  information by explicitly representing revoked certs (directly or with a fingerprint).  Because EE certificates are so numerous, we will instead distribute a selection of CRLs for EE-issuing CAs, with each CRL stored in a compressed representation with some false positive rate  (e.g., a Bloom filter).  Thus, for CA certificates, OneCRL will be  dispositive -- a certificate will be rejected if it is in OneCRL and  accepted if not.  For EE certificates, it will be dispositive only in  the positive direction: If the certificate issuer's CRL is in OneCRL and  the certificate is not listed as revoked, then we know it is not  revoked.  But if the certificate is in OneCRL, then we still check OCSP  (stapled or live) to for false positives.
+'''Format  and Usage of OneCRL:''' For CA certificates, we will include revocation  information by explicitly representing revoked certs (directly or with a fingerprint).  Thus, for CA certificates, OneCRL will be  dispositive -- a certificate will be rejected if it is in OneCRL and  accepted if not.  (If OneCRL is updated in the future to cover EE certificates, it will likely require the use of a probabilistic, compressed representation, such as a Bloom filter.  In this case, OneCRL will be dispositive only in  the positive direction: If the certificate is covered by OneCRL and the certificate is not listed as revoked, then we know it is not revoked.  But if the certificate is in OneCRL, then we still check OCSP (stapled or live) to for false positives).
 ==== Next Steps ====
@@ Line 87: / Line 69: @@
 * Complete implementation of block list based OneCRL
 * Add support for CRL polling as an input, as well as manual input
-* Adapt format of OneCRL data for greater scalability
 * Collect URLs for revocation information covering all intermediate CAs
-* Establish a process for selecting CRLs covering EE certificates
+* Investigate whether there are some EE certificates that should be covered by OneCRL
 === OCSP must-staple ===