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

47 views
Skip to first unread message

Brian Smith

unread,
Apr 30, 2013, 5:28:12 PM4/30/13
to firef...@mozilla.org, Alexander Limi, dev-se...@lists.mozilla.org, mozilla's crypto code discussion list
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.
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

Justin Dolske

unread,
May 1, 2013, 2:42:50 PM5/1/13
to firef...@mozilla.org
On 4/30/13 2:28 PM, 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.

That would be OCSP?

It sounds to me like this is a crufty old feature that isn't enabled by
default, isn't aligned with the direction SSL is evolving, and isn't
something anyone else does (and not in a "great feature unique to
Firefox" way). So I'd have no objection to removing it.

Justin

Brian Smith

unread,
May 1, 2013, 2:46:07 PM5/1/13
to Justin Dolske, firef...@mozilla.org
Justin Dolske wrote:
> On 4/30/13 2:28 PM, 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.
>
> That would be OCSP?

We already support OCSP "as needed". The name of the X.509 extension for CRLs "as needed" is "CRL Distribution Point," and that is something we currently do not support except (currently) when validating EV certificates.

>
> It sounds to me like this is a crufty old feature that isn't enabled
> by default, isn't aligned with the direction SSL is evolving, and
> isn't something anyone else does (and not in a "great feature unique
> to Firefox" way). So I'd have no objection to removing it.

You are correct, except it is enabled by default. If somebody includes a link to a CRL (with the correct MIME type) in a page, then Firefox will pop open a dialog box to allow you to add that CRL to the revocation lists set.

I filed bug 867465 for this, BTW.

Cheers,
Brian

Justin Dolske

unread,
May 1, 2013, 4:14:58 PM5/1/13
to Brian Smith, firef...@mozilla.org
On 5/1/13 11:46 AM, Brian Smith wrote:

> You are correct, except it is enabled by default. If somebody
> includes a link to a CRL (with the correct MIME type) in a page, then
> Firefox will pop open a dialog box to allow you to add that CRL to
> the revocation lists set.

D:

That makes me even more inclined to remove it.

Justin

Sean Leonard

unread,
May 1, 2013, 6:07:49 PM5/1/13
to dev-tec...@lists.mozilla.org, dev-se...@lists.mozilla.org, firef...@mozilla.org, al...@mozilla.com
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

unread,
May 1, 2013, 7:44:49 PM5/1/13
to Sean Leonard, al...@mozilla.com, dev-se...@lists.mozilla.org, dev-tec...@lists.mozilla.org, firef...@mozilla.org
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

Gervase Markham

unread,
May 2, 2013, 6:43:46 AM5/2/13
to Justin Dolske, firef...@mozilla.org
On 01/05/13 19:42, Justin Dolske 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.
>
> That would be OCSP?

No :-) OCSP is a different technology, which is also triggered by a URL
embedded in the certificate but instead of downloading a file of "all
certs that this root/intermediate has issued which has been revoked",
gets the status of that single cert from what might charitably be called
a web service.

This, of course, has a different set of performance and privacy
tradeoffs from the CRL scheme. Better performance, in theory, and worse
privacy, because the CA finds out what site you visited.

> It sounds to me like this is a crufty old feature that isn't enabled by
> default,

"Enabled by default" isn't quite the right way of thinking about it -
it's not an on/off thing. "Has no CRL URLs loaded into it by default,
and so doesn't download anything" is more right.

Gerv

Sean Leonard

unread,
May 2, 2013, 5:10:48 AM5/2/13
to Brian Smith, al...@mozilla.com, dev-se...@lists.mozilla.org, dev-tec...@lists.mozilla.org, firef...@mozilla.org
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

Julien Pierre

unread,
May 8, 2013, 9:44:27 PM5/8/13
to mozilla's crypto code discussion list, Brian Smith, Alexander Limi, dev-se...@lists.mozilla.org, firef...@mozilla.org
Brian,

If this is just about changing the UI in Firefox, I have no objection.

If this is about removing the feature from NSS altogether on the other
hand, I would like to state that we have several several products at
Oracle that use NSS and rely on the ability to have CRLs stored in the
database, and processed during certificate validation. These
applications act as both SSL servers and clients, and we expect the CRLs
to be supported in both.

While some Oracle products are moving away from NSS, old versions
continue to be supported and we are picking up new NSS releases to get
certain security fixes. We couldn't do that anymore if the CRL feature
went away. In the past, before Oracle, Sun went to great pains to work
on the common public NSS tree for these products. We certainly don't
want to fork NSS again at this stage.

Julien

Brian Smith

unread,
May 9, 2013, 6:48:25 PM5/9/13
to Julien Pierre, Alexander Limi, dev-se...@lists.mozilla.org, mozilla's crypto code discussion list, firef...@mozilla.org
Julien Pierre wrote:
> If this is about removing the feature from NSS altogether on the
> other hand, I would like to state that we have several several
> products at Oracle that use NSS and rely on the ability to have
> CRLs stored in the database, and processed during certificate
> validation.

I am not proposing any change to NSS.

Cheers,
Brian
Reply all
Reply to author
Forward
0 new messages