Closed Bug 1312827 Opened 3 years ago Closed 3 years ago
CRL only apply to TLS server certificates
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.
3 years ago
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 email@example.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.)
I had to back this out for failures like https://treeherder.mozilla.org/logviewer.html#?job_id=8385621&repo=autoland https://hg.mozilla.org/integration/autoland/rev/23b0e29c4805
Shoot - I had forgotten about that test. The updated patch should address it.
Try looked good so I'll give this a go again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=66e27e16d4f0
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/f4001bdf070d make the certificate blocklist only apply to TLS server certificates r=jcj,mgoodwin
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+
Pushed to THUNDERBIRD_45_VERBRANCH https://hg.mozilla.org/releases/mozilla-esr45/rev/5c894801eb1e
Setting qe-verify- based on David's assessment on manual testing needs (see Comment 17) and the fact that this fix has automated coverage.
You need to log in before you can comment on or make changes to this bug.