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.

• Nonsensical security properties of revocation checking of end-entity certificates: In most cases, a malicous actor that is trying to use a revoked certificate to attack a browser user will be able to turn off the revocation checking for the certificate he is using.
• Nonsensical security propoerties of revocation checking for intermediate CA certificates: We don't check for revocation of intermediate certificates at all except for the case of EV. A bad intermediate CA certificate is extremely dangerous, so it is important to check revocation of them; sadly, the intermediates we do check revocation for (EV intermediate certificates) are the ones that are the least likely to cause our users security problems. And, those revocation checks suffer from the same problem that revocation checking of end-entity certificates currently has: an attacker can usually just block the check and prevent us from seeing that the certificate has been revoked.
• Poor Privacy: 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.
• Poor Performance: Revocation checking through OCSP and CRL requests is way too slow.
• Poor Usability: Many captive portals with HTTPS login pages work very poorly in Firefox because we stall for 30+ seconds waiting for the OCSP response for the captive portal that is being blocked by the captive portal until you log in.
• Confusing UX for EV certificates: If we fail to get revocation information via OCSP/CRL fetching for an EV certificate, then we do not show the certificate as an EV certificate. This is particularly problematic for cases when a web app is designed to be used offline (e.g. using AppCache), but even normal websites like paypal.com are affected by this. This inconsistency in the security indicators devalues the security indicators.

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

• Policy Change:

• Process Change:

Proposed Changes under Discussion

The following changes are being discussed (or will be discussed) in a Mozilla discussion 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 of the discussion or outcome.

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 an 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.
  • 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

• Policy Change:

• Process Change: