Open djlucas opened 1 year ago
Just for the record, since it didn't see this discussed in the linked email thread: The distrust after date does not behave like removing the CA from the trust store after it expired.
Root CAs with a distrust after date will still be used by NSS (and Firefox) to verify certificates that were issued before the distrust after date, even if the wall clock has passed the distrust after date.
Say you have a CA "Honest Achmed's Used Cars and Certificates Root CA" that issued a certificate on 2022-12-22, valid for a year, and in January the distrust after date gets set to 2023-01-10 for that root CA. The issued certificate will still be accepted until it expires on 2023-12-22. Any certificates signed by "Honest Achmed's Used Cars and Certificates" after 2023-01-10 will however not be accepted.
This mechanism allows NSS (and thus Firefox) to distrust a CA without considering the unexpected and potentially disastrous effect it would have on customers of this CA, thus preventing the CAs from holding Mozilla hostage with the argument that "half of the internet would break if you distrust us, since we're a big CA".
As @ueno already mentioned on the mailing list thread, adding this check would really require runtime support in the various libraries that consume the certificate store. Removing the root CA when its distrust after date has passed might be acceptable for the TrustCor case, since they (IIRC) didn't sign a lot of certificates that were very relevant, but it certainly wouldn't be OK if Mozilla were to decide tomorrow to distrust Let's Encrypt, for example.
Thanks for the clarification, Clemens. Here is the reference of that behavior: https://wiki.mozilla.org/CA/Additional_Trust_Changes#Distrust_After also the original request from the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1465613#c0
See discussion at https://lists.freedesktop.org/archives/p11-glue/2022-December/000717.html
The long and short is that extract is placing explicitly distrusted roots into newly created bundles of trusted roots because the downstream consumer does not have a mechanism in place to support the nss-{server,email}-distrust-after value. Ultimately, for the purpose of extract, these values (if less than today's date) should effectively override CKA_TRUST_SERVER_AUTH and CKA_TRUST_EMAIL_PROTECTION, presumably as CKT_NSS_NOT_TRUSTED, so that the certificates are not extracted to the new bundles.