CA:ImprovingRevocation

Plan for Improving Revocation Checking in Firefox

This page is dedicated to improving how Firefox does revocation checking of SSL certificates.

Problems to Solve

Here are some of the issues that we hope to address very soon.

• User preferences of revocation checking can be over-ridden or turned off by malicious actor that is trying to use a revoked certificate to attack a browser.
• Currently revocation of intermediate certificates is only checked during EV validation. Sadly, the intermediates we do check revocation for (EV) are the ones that are the least likely to cause our users security problems.
• The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP to its servers.
• Revocation checking through OCSP and CRL requests is way too slow.
• Many captive portals with HTTPS login pages work very poorly in Firefox because it stalls for 30+ seconds waiting for the OCSP response for the captive portal that is being blocked by the captive portal until the user logs in.
• If revocation checking via OCSP/CRL fetching for an EV certificate fails, then EV treatment is not given, which may cause confusion. This is particularly problematic for cases when a web app is designed to be used offline (e.g. using AppCache), but even normal websites are affected by this. This inconsistency in the security indicators devalues the security indicators.

These problems can be solved, but they cannot be solved overnight, and they cannot be solved without cooperation from our partners on the internet: certificate authories and websites. We need to quickly provide our partners with useful and working tools, so they can adapt to improve the security of the internet. The most achievable way to do this is to stretch existing, already-standardized and easily-deployable (if not already widely-deployed) mechanisms so that they actually address our users' needs in a reasonable way.

Changes In Progress

The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.

Change Name

Description

• Discussion: Link to Discussion Thread

• Code Change: Bugzilla Bug Number

• Dependencies:

• Policy Change:

• Process Change:

Proposed Changes under Discussion

The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.

Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.

Preload Revocations of Intermediate CA Certificates

Push revocation information of revoked intermediate CA certificates to clients.

• Discussion: Link to Discussion Thread

• Code Change: bug 72599

• Dependencies:
  • The CAs in our program must notify us when intermediate certificates that chain up to any of their roots that are included in Firefox have been revoked. Mozilla will deliver these revocations to Firefox through the revocation set. For CAs that regularly revoke intermediate certificates, we will consider implementing a whitelist of intermediate certificates to prevent too many updates to the revocation set.
  • In addition, the CAs in our program must notify us of any mis-issuances and of any certificates that are to be revoked because some important constraint is missing or invalid (e.g. an end-entity certificate is given the statusResponder EKU, or a subscriber certificate was given the isCA=true basic constraint without meeting the requirements for such subscriber CA certificates).
  • The CA should send us details of the revocation, including the issuer subject name, the subject serial number, a link to the OCSP response for the revocation, and an assertion that the certificate was revoked for one of the reasons that we consider the issuing CA to be responsible for (they should say which reason it was). The easiest and best way to transmit this information is to simply attach the revoked certificate to the notification, assuming it contains the OCSP AIA URL. The link to the OCSP response that contains the revocation is needed to verify the authenticity of the email and to verify the exact encoding of the issuer and serial number. Note that this will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list of such revocations that occurred in the past.
  • In the short term, we will (probably) respond to the revocation notification by issueing a browser security update that contains the updated list of revoked certificates. In the long term, we may have a lighter-weight mechanism for updating the browser with updated revocation information, similar to Google's CRLSet mechanism.

• Policy Change: To be proposed and discussed in the mozilla.dev.security.policy forum. This draft still needs work. For instance, we should consider the notification policy expressed in NIST IR 7924, Section 5.7 (starting on page 36). However, we also want to take into account mis-issued end-entity certificates.
  • EARLY DRAFT of text to add to MaintenancePolicy.html after item 3: 4. CAs must notify Mozilla within 24 hours of revocation of an intermediate certificate for any reason and of revocation of a website certificate whose revocation was not prompted by the certificate owner. To notify us of a revocation due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org. To notify us of an intermediate certificate revocation, submit a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. Whenever possible, the CA should send us the revoked certificate itself, along with the rfc5280 revocation reason code. If the CA cannot send us the revoked certificate, then the information listed below will be needed.
    • Serial number of the revoked certificate
    • Link to the OCSP response for that serial number
    • Link to the CRL that contains that serial number
    • notAfter date of the revoked certificate
    • rfc5280 revocation reason code

• Process Change: To be determined, but may include changes to the Inclusion Process, and EV treatment (maybe EV treatment is only granted when the CA is providing this information?)

Change Name

Description

• Discussion: Link to Discussion Thread

• Code Change: Bugzilla Bug Number

• Dependencies:

• Policy Change:

• Process Change: