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
