1665715 - pass the embedded SCT list extension (if present) to TrustDomain::CheckRevocation instead of the notBefore value

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P1)

Description

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

In bug 1593141, we added the certificate's notBefore field as an argument to TrustDomain::CheckRevocation to use with CRLite. However, since CAs can backdate certificates, we could end up in a situation where we're trying to check a certificate against CRLite that is too new, even though it looks old, and we may get an incorrect answer. To protect against this, we should use the earliest embedded SCT timestamp, so we should pass that instead to CheckRevocation.
This needs to land at the same time as bug 1605273 or the build will break.

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: Bug 1665715 - (1/2) revert e8f2720c8254 (bug 1593141) because it's no longer necessary r?jcj

Bug 1593141 added the certificate's notBefore field as an argument to
TrustDomain::CheckRevocation so that Firefox could use it with CRLite.
However, since CAs can backdate that field, we need to use the earliest
embedded SCT timestamp instead.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: Bug 1665715 - (2/2) pass encoded signed certificate timestamp extension (if present) in CheckRevocation r?jcj

This will allow Firefox to make decisions based on the earliest known time that
a certificate exists (with respect to certificate transparency) that a CA
shouldn't be able to back-date. In particular, this is essential for CRLite.

Depends on D90595

Comment 3

[Ryan Sleevi]

I would love to encourage caution and care here. This is an area where we've struggled with in Chrome. While it's very true that CAs can backdate, Mozilla policy at least describes that as an policy violation ( https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date )

I totally understand that having code to enforce things is good, but it's definitely a systems problem.

• If you don't have a set of "recognized logs", then it's easy to add a backdated SCT without running afoul of anything
• If you do have a set of "recognized logs", this approach now makes them more "trusted"
  • For example, consider the DigiCert Log whose key was compromised. The goals of CT still work even in light of that compromise.
  • However, with this change, the compromise of that key would allow creating "backdated" SCTs that could impair your checks
• Even if you have a set of "recognized logs", it could be that all the logs have been retired before the certificate is expired.
  • The certificate can still be used (e.g. by including SCTs via TLS or OCSP), proving the certificate is logged in still-recognized logs.
  • However, in that scenario, the new SCTs will inevitably be later than when the certificate was issued, since those new SCTs are (generally) obtained after all the embedded SCTs are no longer recognized.
  • It also runs into trouble with handling situations of no embedded SCTs (only using OCSP/TLS), since the logging may be weeks or months after issuance (e.g. when you're dealing with the case redaction deals with, of not trying to announce a website until publicly announced)

For Chrome, at least, the solution is two-fold:

• Moving to a path where we expect CT for 'all' certificates (circa 2021), to guarantee visibility.
• Using CT to enforce this policy, via scanning/monitoring, rather than doing so on the client. This allows for more human review of nuanced cases.

I realize jumping in from the peanut gallery may not be the most helpful, but definitely, this was an area where we've spent a lot of time debating for Chrome policy enforcement. We're happy to help however we can in discussing some of these tradeoffs; we haven't really written them up because it was just us internally working this through.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Thanks for the words of caution, Ryan. Since we're not validating against a set of recognized logs currently, this change is not about protecting against malicious or compromised CAs. The aim is to get a timestamp that should be no earlier than the relevant certificate was disclosed to CT, in order to protect against false positives in CRLite.

Comment 5

[J.C. Jones [:jcj] (he/him)]

https://hg.mozilla.org/projects/nss/rev/8ebee3cec9cfb4d5b4355173f193b8e5f5bb9e73

Comment 6

[J.C. Jones [:jcj] (he/him)]

https://hg.mozilla.org/projects/nss/rev/c1f4d565ceda also