Closed Bug 1312827 Opened 3 years ago Closed 3 years ago

make OneCRL only apply to TLS server certificates

Categories

(Core :: Security: PSM, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
thunderbird_esr45 51+ fixed
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: keeler, Assigned: keeler)

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

When we revoke intermediates in OneCRL, there is the unintended consequence that this also causes email certificates issued from those intermediates to be revoked, reducing their usability in e.g. Thunderbird. One option we have here is to make OneCRL revocations only apply to certificates used in TLS connections.
If the certificate was revoked, why would it be ok to use as email certificate?
OneCRL is used to block certain certs, as well as to indicate revoked intermediate certs. OneCRL was designed and implemented for the SSL/TLS use case, so for now we are considering limiting the use of OneCRL to SSL/TLS.

If, at some point people who maintain Thunderbird evaluate the S/MIME use cases of OneCRL, and update Thunderbird to address those use cases, then OneCRL may be applied to S/MIME as well. (example use cases: importing certificate, signing email, validating signature on signed email, encrypting email, reading encrypted email)
What about certificates that are used for other purposes such as content signatures? They're explicitly non-TLS certs but we want to be able to revoke those certs with onecrl iirc.
As I understand it, OneCRL was intended for TLS certs. Handling S/MIME, code-signing, and content-signing use cases are all  reasonable, but I think they should be considered new features.

The alternative is to embrace the idea that there's no granular control; that's fine in the event of OneCRL being limited to use for compromise scenarios, but we've already been using it to retire certain TLS trust bits (as opposed to compromise recovery). We'd need to stop that.
The problem I see is that this would leave everything that's using content signing without a revocation mechanism, e.g. certificates used to update onecrl itself can't be revoked.
CS was designed with onecrl as revocation mechanism in mind such that we'd have to reconsider how we use them if onecrl can't be used for revocation anymore.
Assignee: nobody → dkeeler
Priority: P2 → P1
Summary: investigate making OneCRL only apply to certificates used in TLS connections → make OneCRL only apply to TLS server certificates
Whiteboard: [psm-backlog] → [psm-assigned]
Comment on attachment 8821385 [details]
bug 1312827 - make the certificate blocklist only apply to TLS server certificates

https://reviewboard.mozilla.org/r/100688/#review101224
Attachment #8821385 - Flags: review?(mgoodwin) → review+
Comment on attachment 8821385 [details]
bug 1312827 - make the certificate blocklist only apply to TLS server certificates

https://reviewboard.mozilla.org/r/100688/#review101290

Looks good to me, too.
Attachment #8821385 - Flags: review?(jjones) → review+
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/25d339813371
make the certificate blocklist only apply to TLS server certificates r=jcj,mgoodwin
Thanks! (And, to clarify, we can still revoke content signing certificates with OneCRL - this change only applies to the default certificate verifier, which the content signature implementation actually doesn't use.)
Shoot - I had forgotten about that test. The updated patch should address it.
Flags: needinfo?(dkeeler)
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f4001bdf070d
make the certificate blocklist only apply to TLS server certificates r=jcj,mgoodwin
https://hg.mozilla.org/mozilla-central/rev/f4001bdf070d
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment on attachment 8821385 [details]
bug 1312827 - make the certificate blocklist only apply to TLS server certificates

Approval Request Comment
[Feature/Bug causing the regression]: OneCRL initially applied to all certificates, not just TLS server certificates
[User impact if declined]: this impacts Thunderbird in particular. When we put a certificate in OneCRL, we're saying we don't trust it to issue for TLS server certificates. However, we don't have a similar process and policies for email certificates (for example), so we shouldn't also apply OneCRL to those for the moment.
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: not by QA (although, it does have tests)
[Needs manual test from QE? If yes, steps to reproduce]: probably not
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not very
[Why is the change risky/not risky?]: the patch basically adds a single "if" block, and it has tests, so we're pretty sure it's correct and won't cause other problems
[String changes made/needed]: none
Attachment #8821385 - Flags: approval-mozilla-aurora?
Comment on attachment 8821385 [details]
bug 1312827 - make the certificate blocklist only apply to TLS server certificates

only look at onecrl for tls server certs, take in aurora52
Attachment #8821385 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Setting qe-verify- based on David's assessment on manual testing needs (see Comment 17) and the fact that this fix has automated coverage.
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.