Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Hi all,

I propose we remove the "Revocation Lists" feature (Options -> Advanced -> Revocation Lists). Are there any objections? If so, please explain your objection.

A certificate revocation list (CRL) is a list of revoked certificates, published by the certificate authority that issued the certificates. These lists vary from 1KB to potentially hundreds of megabytes in size.

Very large CRLs are not super common but they exist: Reportedly, GoDaddy (A CA in our root CA program) has a 41MB CRL. And, Verisign has at least one CRL that is close to 1MB on its own, and that's not the only CRL that they have. the US Department of Defense is another example of an organization known to have extremely large CRLs.

The "Revocation Lists" feature allows a user to configure Firefox to poll the CAs server on a regular interval. As far as I know, Firefox is the only browser to have such a feature. Other browser either ignore CRLs completely or download CRLs on an "as needed" basis based on a URL embedded in the certificate. For example, in its default configuration, Google Chrome ignores CRLs, AFAICT (they use some indirect mechanism for handling revocation, which will be discussed in another thread). AFAICT, the "Revocation Lists" feature was added to Firefox a long time ago when there were IPR concerns about the "as needed" behavior. However, my understanding is that those concerns are no longer justified. In another thread, we will be discussing about whether or not we should implement the "as needed" mechanism. However, I think that we can make this decision independently of that decision.

Obviously, the vast majority of users have no hope of figuring out what this feature is, what it does, or how to use it.

Because of the potential bandwidth usage issues, and UX issues, it doesn't seem like a good idea to add this feature to Mobile. But, also, if a certificate feature isn't important enough for mobile*, then why is it important for desktop? We should be striving for platform parity here.

Finally, this feature complicates significant improvements to the core certificate validation logic that we are making.

For all these reasons, I think it is time for this feature to go.

Cheers,
Brian

[*] Note: I make a distinction between things that haven't been done *yet* for mobile vs. things that we really have no intention to do.

[Jan Schejbal]

Am 2013-04-30 23:28, schrieb Brian Smith:
> For all these reasons, I think it is time for this feature to go.

I just checked. In my list, I had two CRLs, one by OpenLimit, one by
CACert. The CACert had autoupdate enabled and set to be done 1 day
before nextupdate date, a nextUpdate date in 2008, and no reported
update failures. Manually triggering the update did bring up a current
CRL. Therefor, I am not even sure if the feature works properly.

The only place where I could imagine this could be relevant are
enterprise setups where someone has rolled out their own CA, either for
https or for mail. Thus, I would suggest asking on the various
Enterprise Working Group mailing list.

Kind regards,
Jan


--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...

[Sean Leonard]

Please, do not remove this important feature.

On 4/30/2013 2:28 PM, Brian Smith wrote:
> Hi all,
>
> I propose we remove the "Revocation Lists" feature (Options -> Advanced -> Revocation Lists). Are there any objections? If so, please explain your objection.

Please do not remove this feature. There are several objections.

> The "Revocation Lists" feature allows a user to configure Firefox to poll the CAs server on a regular interval. As far as I know, Firefox is the only browser to have such a feature. Other browser either ignore CRLs completely or download CRLs on an "as needed" basis based on a URL embedded in the certificate.

This is not true.

The Microsoft Windows CryptoAPI stack allows users (and admins) to load
CRLs manually, not just via an automated network call during certificate
validation. These CRLs are checked by default (indeed, in preference to
the network download) if they are present. Admins can push updated CRLs
to PCs as well.

All applications on Windows that use CryptoAPI use the CRL store. This
includes Internet Explorer, Google Chrome (at least certain versions
and/or derivative Chromium products), and all other Windows-based apps
that use the operating system-provided SSL or other certificate-touching
functions (Outlook, the rest of the Office Suite, Authenticode,
driver/kernel signing, etc.).

Similar statements could be made about libnss on *nix, if and when
multiple apps use libnss and the same stores.

> For example, in its default configuration, Google Chrome ignores CRLs, AFAICT (they use some indirect mechanism for handling revocation, which will be discussed in another thread).

Not necessarily true. See above. It may be more accurate to say that
"Chrome does not take any special effort to download CRLs of its own
accord". What more recent and future versions of Chrome do is to gather
all the CRLs from all the main CAs and re-compile a Google-signed single
CRL where all the revoked certificates are. This is pushed to the
browser each time it updates (e.g., when it starts up). The poor
security practice that they subsequently do is to strip the revoked
certificates that are not "important" according to an algorithm that
they implemented (from second-hand knowledge, if there is no specific
revokeInfo in the CRL entry or the revokeInfo is of certain types, that
entry is ignored).

>
> Obviously, the vast majority of users have no hope of figuring out what this feature is, what it does, or how to use it.

Enterprise users, software developers, and system administrators do use
this feature. You should see the point of this feature not as asking
users to maintain it themselves--that would be like expecting regular
car drivers to take apart their combustion engines or transmissions to
unclog them. These features remain incredibly valuable for mechanics
(admins/developers), however, to service the machine (software) in a
cost-effective manner across a fleet of vehicles (software deployment).

Additionally, the UI for Revocation Lists is part of "pippki", which is
a core Mozilla Toolkit component. Removing the UI would be tantamount to
removing it from all other apps, including Thunderbird. In theory you
could remove it--or the button--from just Firefox, but what would be the
point? You would just be removing functionality that has already proven
its utility.

> Because of the potential bandwidth usage issues, and UX issues, it doesn't seem like a good idea to add this feature to Mobile. But, also, if a certificate feature isn't important enough for mobile*, then why is it important for desktop? We should be striving for platform parity here.

If you expect or want enterprises, developers, or security-conscious
users to use Firefox in an advanced way, keep it in.

> Finally, this feature complicates significant improvements to the core certificate validation logic that we are making.

As long as you follow RFC 5280, you should be compliant, and as long as
you keep RFC 4158 ("Internet X.509 Public Key Infrastructure:
Certification Path Building") in mind, it will be fine. In spite of
"libpkix" being (in my opinion) unnecessarily complicated, it was
designed to be RFC 3280 (and subsequently RFC 5280) compliant. As I have
independently documented, it pretty much covers all the bases.

However, "improvements to the core certificate validation logic" are NOT
improvements if they ignore valuable revocation information. If a user
(or admin) intentionally ships Firefox--or any app--with **additional
revocation information**, that user preference ought to be respected.

Thank you,

Sean

[Brian Smith]

Sean Leonard wrote:

> Brian Smith wrote:
> > The "Revocation Lists" feature allows a user to configure Firefox
> > to poll the CAs server on a regular interval. As far as I know,
> > Firefox is the only browser to have such a feature. Other browser
> > either ignore CRLs completely or download CRLs on an "as needed"
> > basis based on a URL embedded in the certificate.
>
> This is not true.
>
> The Microsoft Windows CryptoAPI stack allows users (and admins) to
> load CRLs manually, not just via an automated network call during
> certificate validation. These CRLs are checked by default (indeed,
> in preference to the network download) if they are present. Admins
> can push updated CRLs to PCs as well.

Thanks for correcting my mistake. I did search for this feature, but I could not find it. How does one access this feature?

> All applications on Windows that use CryptoAPI use the CRL store.
> This includes Internet Explorer, Google Chrome (at least certain
> versions and/or derivative Chromium products), and all other
> Windows-based apps that use the operating system-provided SSL or
> other certificate-touching functions (Outlook, the rest of the
> Office Suite, Authenticode, driver/kernel signing, etc.).

Also, like Jan noted in this thread, and as others have noted previously, this feature seems to be buggy. So, I hope that nobody has been relying on this feature for anything important. And, given that it seems to be broken/unreliable for a long time, underused, and difficult to figure out, it seems silly to devote any resources to fixing it, when it is much easier to just remove it and forget about it.

> Similar statements could be made about libnss on *nix, if and when
> multiple apps use libnss and the same stores.

> > For example, in its default configuration, Google Chrome ignores
> > CRLs, AFAICT (they use some indirect mechanism for handling
> > revocation, which will be discussed in another thread).
>
> Not necessarily true. See above. It may be more accurate to say that
> "Chrome does not take any special effort to download CRLs of its own
> accord".

It seems, insofar as this feature might be useful, that it would be better to integrate with the systems' CRL stores, rather than have our own. And, in general, for systems that care about this kind of stuff, it seems better in general to just have an option to use the system's certificate validation logic (e.g. Windows CryptoAPI), as configured by the sysadmin/user, for certificate validation, instead of Gecko/NSS's certificate validation. For the type of user that requires such special handling and centralized control, that seems like the "real" solution to this problem and related problems.

Still, insofar as revocation checking is important, it is equally important on all platforms. But, I seriously doubt that many of these platforms will ever have this feature. That is, certificates have to be safe even for platforms that don't have this feature, and given that, it seems pointless to have this if other mechanisms must already be sufficient.

> Additionally, the UI for Revocation Lists is part of "pippki", which
> is a core Mozilla Toolkit component. Removing the UI would be tantamount
> to removing it from all other apps, including Thunderbird. In theory you
> could remove it--or the button--from just Firefox, but what would be
> the point? You would just be removing functionality that has already
> proven its utility.

It would be removing broken functionality that slows down progress fixing much more important broken functionality.

Also, before I became module owner of PSM, I had it clarified that decisions in mozilla-central are to be focused on the needs of Firefox and FirefoxOS. If Thunderbird or another application needs a particular (mis)feature of PSM that Firefox/FirefoxOS doesn't need, then they can add that feature back in the products that need it (and fix all the bugs in those misfeatures).

> As long as you follow RFC 5280

RFC 5280 allows us to do revocation checking in any way we choose.

> However, "improvements to the core certificate validation logic" are
> NOT improvements if they ignore valuable revocation information. If a
> user (or admin) intentionally ships Firefox--or any app--with
> **additional revocation information**, that user preference ought to
> be respected.

It's going to be a long week. :)

Cheers,
Brian

[Sean Leonard]

Can't respond to everything at once, but let me at least try to pick of
the easy ones:

On 5/1/2013 4:44 PM, Brian Smith wrote:
> Sean Leonard wrote:
>> Brian Smith wrote:
>>> The "Revocation Lists" feature allows a user to configure Firefox
>>> to poll the CAs server on a regular interval. As far as I know,
>>> Firefox is the only browser to have such a feature. Other browser
>>> either ignore CRLs completely or download CRLs on an "as needed"
>>> basis based on a URL embedded in the certificate.
>> This is not true.
>>
>> The Microsoft Windows CryptoAPI stack allows users (and admins) to
>> load CRLs manually, not just via an automated network call during
>> certificate validation. These CRLs are checked by default (indeed,
>> in preference to the network download) if they are present. Admins
>> can push updated CRLs to PCs as well.
> Thanks for correcting my mistake. I did search for this feature, but I could not find it. How does one access this feature?

Run > certmgr.msc
(This opens the "Certificates" MMC component to "Current User")

Intermediate Certification Authorities > Certificate Revocation Lists

If you want to store CRLs in other stores, you can open mmc.exe, add the
Certificates component, and choose the user (notably, you can choose the
"Local Computer" store, or the "Service" store).

To import: it's actually pretty easy. Just right-click on the .crl file
in Explorer, and select "Install CRL".

Can also use certmgr.exe /CRL with /add, /delete, and /put. (This is
conceptually identical to NSS crlutil that Bob mentioned.)

Some links:
http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/07a3a4a2-3b86-4d51-8986-b98cc62060e4/
http://technet.microsoft.com/en-us/library/cc753863.aspx
http://technet.microsoft.com/en-us/library/cc731638.aspx
http://technet.microsoft.com/en-us/library/cc782162(v=WS.10).aspx
http://technet.microsoft.com/en-us/library/cc770315(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc754877.aspx

While I did not find a specific pre-configured Group Policy Object to
deploy CRLs, I am sure that something exists. Anyway, it's pretty easy.
Here's the thing. You can just promulgate a batch file to run
certmgr.exe /CRL /add (analogous to NSS crlutil), you can call the
CryptoAPIs (analogous to calling the NSS APIs), or you can add the CRL
to the Registry directory (analogous to editing the cert8.db/cert9.db
database, or, I suppose, calling the PKCS #11 softoken APIs). The
Registry key where those particular CRLs are stored is
HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\CA\CRLs. The
subkey is the SHA-1 hash of the CRL.


-Sean

[Michael Ströder]

Brian Smith wrote:
> I propose we remove the "Revocation Lists" feature (Options -> Advanced ->
> Revocation Lists). Are there any objections? If so, please explain your
> objection.

For privacy reasons many people switch off OCSP checking. And therefore I have
strong objections against everything which makes CRL checking less flexible.

Ciao, Michael.