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
