CA:RevocationPlan

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This page will document Mozilla's future plans for revocation checking of SSL certificates.

• Discussion of Policy changes: mozilla.dev.security.policy forum
• Discussion of Code changes: mozilla.dev.tech.crypto forum

Revocation Is Important

Support for revoking certificates is important, because otherwise stolen certificates can be used to abuse our users until they expire. History, from Diginotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Having no revocation story is not an option.

Problems to Solve

However, there are several things very sub-optimal about the current mechanisms for revocation checking.

There are two common revocation-checking mechanisms - CRLs and OCSP. CRLs are lists of revoked certs, and OCSP is a protocol where a browser can enquire about the status of specific certs from the CA in real time. CRLs have bad download size and storage size characteristics, and because they are lists of "known badness", can't protect against misissuance the CA doesn't know about. Firefox no longer checks CRLs at all, although they remain useful for feeding revocation information into other mechanisms. This page will not consider CRLs further. For OCSP:

• Revocation of intermediate certificates is only checked during EV validation. That is, the intermediates we do check revocation for are the ones that are the least likely to cause our users security problems.
• Standard OCSP has poor privacy properties; the CA learns the user's IP address, location, and a subset of their browsing history.
• Standard OCSP is way too slow, especially on mobile.
• Captive portals with HTTPS login pages work very poorly in Firefox because it stalls for 30+ seconds waiting for the (blocked) OCSP response.
• The traditional revocation mechanisms treat all possible reasons for revocation uniformly for all websites, so relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations.

The Plan

To be agreed :-) See [1] and [2] for discussion and ideas.

What Do Others Do?

Chrome on Desktop

Google Chrome only uses CRLsets for non-EV (and some EV?) certs. However, their CRLset implementation covers both end-entity and intermediate certs, and is not designed to be comprehensive. Some CRLs are not included - the list is manually mantained by emailing agl.

agl is of the opinion that the only thing other than CRLsets which is worth considering is must-staple. So Chrome seems to be going in the same direction as us.

IE on Desktop

IE checks OCSP and, if OCSP fails, falls back to CRLs - although they are considering eliminating the fallback.

Chrome on Mobile

???

Android Browser

???