Closed Bug 682948 Opened 13 years ago Closed 8 years ago

certificate list should be pulled at runtime, like the blocklist

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
7 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bhearsum, Unassigned)

Details

For the second time we're preparing to chemspill for simply to revoke a compromised certificate. If we synced the certificate list to clients, like we do for the blocklist, we could avoid chemspilling for future issues like this, and more importantly, get updated CA lists to users MUCH faster.

I asked about this in developers and understand there may be good reason we can't or shouldn't do this, but if it's possible to do safely, it would be very nice to have.
(Filed as a security bug because I'm not sure if talk of chemspilling should be public knowledge or not)
This would be exceedingly difficult: you have to have *some* built-in certificates in order to validate the downloaded CA lists. You could potentially limit it to a few well-known CAs or we could run our own private keys for signing this specifically to bootstrap everything else, but it will be painful and I really don't expect that we'll be pulling root CAs except for the most unusual circumstances.
How is this different than bug 642503 ?
I'm not technical enough to know if bug 642503 is the same as this. But if it allows us to update our CA list without shipping a new Firefox, Thunderbird, and SeaMonkey - feel free to dupe.
Yes.

Dupe of bug 647868 which I had filed in April after Comodo, and set priority to critical?
This bug and bug 647868 are different from bug 642503.

Bug 624503 is about the NSS roots module - this is a binary component - it still requires compilation.

This bug and bug 647868 propose a mechanism that doesn't require compilation - but rather uses static information, to be parsed at runtime, potentially delivered via the Mozilla update mechanism and stored in the profile directory - as an immediate reaction channel.

In order to keep dynamic parsing minimal, any information pushed to users via a "bug 647868 like" mechanism could be rolled into the next regular release using the "bug 624503 like" mechanism, and at runtime we could cleanup the earlier pushed files, that have become redundant.
s/624503/642503/
Group: core-security
I'm resolving this as WONTFIX because:
 - The main reason why this bug was filed (needing to chemspill just to revoke a cert) is no longer an issue now that we have OneCRL.
 - As mentioned in comment 2, the changes required would be somewhat of a headache.
   - In addition, I believe our HPKP implementation assumes certain roots are present, which is another annoyance.
 - Root cert changes aren't made all that often AFAICT.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.