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.

[Robert Relyea]

On 04/30/2013 02: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.

Let me check with our group that works with the DoD. My guess is it's
probably OK. I believe the DoD primarily uses OCSP, and only uses CRLs
in the offline scenario (laptops in the war theater, or example). I'm
pretty sure the original feature was driven by defense needs.

(Also note: while no browsers have this feature, some browsers do
automatic CRL fetching at validation time, so we should make sure that
we don't need to make sure we have a fall back after removing this feature).

bob

[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

[Robert Relyea]

On 05/01/2013 03:07 PM, Sean Leonard wrote:
> 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.

Thanks for your input.

Brian, I was under the impression you wanted to remove the CRL
autofetching feature (where you enter a URL and a fetching time and the
CRL will automatically be fetched). When I looked at the UI, it looked
like it had both the URL fetching feature as well as the ability to
manage downloaded CRLs. I think you need to be careful about removing
the management ability with CRLs. The most important part of the UI is
the ability to delete CRLs which may have gotten into the database.

Any the processing of already loaded CRLs is part of NSS proper. You can
load them and delete them by hand with crlutil. What you can't do is
have them automatically refreshed.

Sean, is it the ability to load offline CRLs or the automatically
fetch/refresh them that you object to. I already know that processing
offline, already loaded CRLs are a requirement, so it's not going away
from NSS anytime soon.

bob

[Brian Smith]

Robert Relyea wrote:
> Brian, I was under the impression you wanted to remove the CRL
> autofetching feature (where you enter a URL and a fetching time and
> the CRL will automatically be fetched). When I looked at the UI, it
> looked like it had both the URL fetching feature as well as the
> ability to manage downloaded CRLs. I think you need to be careful
> about removing the management ability with CRLs. The most important
> part of the UI is the ability to delete CRLs which may have gotten
> into the database.

My intent is to remove/disable all aspects of this feature: the UI *and* the processing of CRLs stored in the database.

> Any the processing of already loaded CRLs is part of NSS proper. You
> can load them and delete them by hand with crlutil. What you can't do
> is have them automatically refreshed.
>
> Sean, is it the ability to load offline CRLs or the automatically
> fetch/refresh them that you object to. I already know that processing
> offline, already loaded CRLs are a requirement, so it's not going
> away from NSS anytime soon.

To be clear, I don't know of any reason to consider the processing of already-loaded CRLs as a requirement for Firefox.

Anyway, I wouldn't get to hung up about what NSS currently does. We can always change Firefox and/or NSS to get the behavior we need.

Cheers,
Brian

[Varga Viktor]

Hello,

A normat certificate user never go to this menu, but maybe developers does... (ad remove crls- to test your application works well with revoked state or not, etc...

my opinion, remove it, but ask the right people too, please. :)

Üdvözlettel/Regards,

Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customer Service Executive
Netlock Kft.

--
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu

This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________

_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu

This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________

[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

[Falcon Darkstar Momot]

There would be a lot of benefit in doing something like that. If
enterprise trust could also be imported from the Windows CryptoAPI, that
would be two less seams in the transition for a company trying to
transition away from IE.

[Robert Relyea]

On 05/01/2013 08:40 PM, Brian Smith wrote:
> Robert Relyea wrote:
>> Brian, I was under the impression you wanted to remove the CRL
>> autofetching feature (where you enter a URL and a fetching time and
>> the CRL will automatically be fetched). When I looked at the UI, it
>> looked like it had both the URL fetching feature as well as the
>> ability to manage downloaded CRLs. I think you need to be careful
>> about removing the management ability with CRLs. The most important
>> part of the UI is the ability to delete CRLs which may have gotten
>> into the database.
> My intent is to remove/disable all aspects of this feature: the UI *and* the processing of CRLs stored in the database.

Oh, in that case I can say we have customers that definately need to use
CRLs that have been loaded and stored in the database.

>
>> Any the processing of already loaded CRLs is part of NSS proper. You
>> can load them and delete them by hand with crlutil. What you can't do
>> is have them automatically refreshed.
>>
>> Sean, is it the ability to load offline CRLs or the automatically
>> fetch/refresh them that you object to. I already know that processing
>> offline, already loaded CRLs are a requirement, so it's not going
>> away from NSS anytime soon.
> To be clear, I don't know of any reason to consider the processing of already-loaded CRLs as a requirement for Firefox.

Oh, then I'd say we really can't remove it....

bob

[Brian Smith]

Robert Relyea wrote:
> Oh, in that case I can say we have customers that definately need to
> use CRLs that have been loaded and stored in the database.

> > To be clear, I don't know of any reason to consider the processing
> > of already-loaded CRLs as a requirement for Firefox.

> Oh, then I'd say we really can't remove it....

Right now, I am thinking that we will remove it in the default configuration of Firefox. If the user has switched Firefox to use the system's certificate verification logic, and the system's certificate validation logic happens to use this information, then it will get used. The good thing (for Firefox) is that it will be the operating system's responsibility to provide tools to manage this and also to make sure that it works, independently of anything that Firefox explicitly does.

I think this will address the desires of your customers, since they are using system NSS with libpkix on RHEL, right? This would also meet the goal of driving the web towards sane, uniform, and standardized certificate processing, since Firefox wouldn't do it by default.

Cheers,
Brian

[Robert Relyea]

On 05/02/2013 02:02 PM, Brian Smith wrote:
> Robert Relyea wrote:
>> Oh, in that case I can say we have customers that definately need to
>> use CRLs that have been loaded and stored in the database.
>>> To be clear, I don't know of any reason to consider the processing
>>> of already-loaded CRLs as a requirement for Firefox.
>> Oh, then I'd say we really can't remove it....
> Right now, I am thinking that we will remove it in the default configuration of Firefox. If the user has switched Firefox to use the system's certificate verification logic, and the system's certificate validation logic happens to use this information, then it will get used. The good thing (for Firefox) is that it will be the operating system's responsibility to provide tools to manage this and also to make sure that it works, independently of anything that Firefox explicitly does.

So are you actually going to ship a different version of NSS with the
default Firefox, or are you going to create a switch that changes the
behavior of NSS with respect to stored CRLs (and what about cached CRLs,
and do you want to support persistent cached CRLs?). I'm not really sure
this decision has been completely thought through...

>
> I think this will address the desires of your customers, since they are using system NSS with libpkix on RHEL, right? This would also meet the goal of driving the web towards sane, uniform, and standardized certificate processing, since Firefox wouldn't do it by default.

I'm not completely sure. I know I have to worry about off-line for
things like smart card login, which doesn't affect FF. I don't know if
the customer has some sort of off-line use of FF on windows (It does
seem like an oxymoron: off-line and FireFox and https...). You are
probably right on this case.
>
> Cheers,
> Brian

[Julien Pierre]

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

On 4/30/2013 14:28, 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.
>

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

[Brian Smith]

Robert Relyea wrote:
> On 05/02/2013 02:02 PM, Brian Smith wrote:
> So are you actually going to ship a different version of NSS with the
> default Firefox, or are you going to create a switch that changes the
> behavior of NSS with respect to stored CRLs (and what about cached
> CRLs, and do you want to support persistent cached CRLs?). I'm not
> really sure this decision has been completely thought through...

There are no plans to change NSS, so as long as we're using NSS we would still check the stored CRLs, though there would be no UI to manage them. I doubt that the type of deployments that you are concerned about are managing these CRLs through the Firefox UI anyway.

> > I think this will address the desires of your customers, since they
> > are using system NSS with libpkix on RHEL, right? This would also
> > meet the goal of driving the web towards sane, uniform, and
> > standardized certificate processing, since Firefox wouldn't do it
> > by default.
>
> I'm not completely sure. I know I have to worry about off-line for
> things like smart card login, which doesn't affect FF. I don't know
> if the customer has some sort of off-line use of FF on windows (It
> does seem like an oxymoron: off-line and FireFox and https...).
> You are probably right on this case.

I am only talking about SSL. There seems to be a vague agreement to stop using code signing for Firefox extensions, and I have a goal of removing all the email-certificate related stuff from Gecko (moving all S/MIME functionality it to mailnews). So, then Gecko and Firefox only need to worry about the SSL case. Like you noted, it would be very strange to me to *require* these offline CRLs for the SSL case for a closed network. Also, even if it were to be important to those particular users, it does not seem to be a particularly important use case for the Firefox product.

Cheers,
Brian

[Brian Smith]

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

[Robert Relyea]

On 05/09/2013 03:47 PM, Brian Smith wrote:
> Robert Relyea wrote:
>> On 05/02/2013 02:02 PM, Brian Smith wrote:
>> So are you actually going to ship a different version of NSS with the
>> default Firefox, or are you going to create a switch that changes the
>> behavior of NSS with respect to stored CRLs (and what about cached
>> CRLs, and do you want to support persistent cached CRLs?). I'm not
>> really sure this decision has been completely thought through...
> There are no plans to change NSS, so as long as we're using NSS we would still check the stored CRLs, though there would be no UI to manage them. I doubt that the type of deployments that you are concerned about are managing these CRLs through the Firefox UI anyway.

So to be clear:
You propose removing the mime processing for CRLs which imports the CRLs
into the database.
You propose removing the UI that manages CRLs in the database (and also
automatically fetches the CRLs).
You are not changes the NSS processing which automatically checks the
CRLs if they are there.

The only downside I see is that someone who had set crls up in the past
won't be able to remove them using firefox. I suggest coming up with a
plan to help these people recover (I think the number should be small
enough).

>>> I think this will address the desires of your customers, since they
>>> are using system NSS with libpkix on RHEL, right? This would also
>>> meet the goal of driving the web towards sane, uniform, and
>>> standardized certificate processing, since Firefox wouldn't do it
>>> by default.
>> I'm not completely sure. I know I have to worry about off-line for
>> things like smart card login, which doesn't affect FF. I don't know
>> if the customer has some sort of off-line use of FF on windows (It
>> does seem like an oxymoron: off-line and FireFox and https...).
>> You are probably right on this case.
> I am only talking about SSL. There seems to be a vague agreement to stop using code signing for Firefox extensions, and I have a goal of removing all the email-certificate related stuff from Gecko (moving all S/MIME functionality it to mailnews). So, then Gecko and Firefox only need to worry about the SSL case. Like you noted, it would be very strange to me to *require* these offline CRLs for the SSL case for a closed network. Also, even if it were to be important to those particular users, it does not seem to be a particularly important use case for the Firefox product.

OK, if mailnews still has the UI, that's probably fine. I suspect the
customer may use the mail interface to distribute CRLs. If they were
using FF to fetch them, one wonders why OCSP doesn't work in that case..
>
> Cheers,
> Brian