Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
