You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9603f3c0-af0c-44ee-bb40-589444d542acn%40mozilla.org.
One thing that stands out is Mozilla's approach to removing trust, which has changed somewhat in the past several years. Typically, once a CA has some large set of non-compliance issues, but not yet to the point of a public discussion of how to address these issues, the CA may decide to say "We've stopped issuing TLS certificates" or "We're starting over with new roots, and have stopped using the old ones", at which point, Mozilla decides to distrust new certificates while continuing to trust old certificates (based on the notBefore).
Relatedly, I just rediscovered https://github.com/mozilla/pkipolicy/issues/97. If Mozilla wants certdata.txt to be regarded as a proprietary internal file format with no backward compatibility promise, then dissuading application developers from using certdata.txt directly would seem sensible.
Sent: 04 May 2021 17:46
Subject: Re: DRAFT blog post: Beware of Applications Misusing Root Stores
> Additionally, some application developers make the mistake of using OpenSSL to directly parse a file in Mozilla’s source code management system called certdata.txt, in which Mozilla’s root store is maintained in a form that is convenient for NSS to build from.
I don't think OpenSSL provides any function to directly parse certdata.txt, so I suggest striking the OpenSSL reference. Also, "to directly parse" isn't necessarily "a mistake"...if the application developer does know what they're doing!
> The problem with the scripts that directly parse this file is that some of the certificates in this file are not trusted but rather explicitly distrusted, so scripts that do not take the trust records into account may be trusting root certificates, such as the DigiNotar certificates, which Mozilla explicitly distrusts.
Is it your intent to:(1) Dissuade application developers from using certdata.txt directly, because they'll almost certainly do it wrong; or(2) Help application developers to use certdata.txt correctly, because a "Here be dragons!" disclaimer probably won't stop them from using it?
If (2), might it be useful to provide example code, perhaps by pointing to one or more projects that do parse certdata.txt correctly?
Sent: 04 May 2021 16:59
Subject: DRAFT blog post: Beware of Applications Misusing Root Stores
I will greatly appreciate your feedback on the following post that I am drafting for Mozilla's Security Blog. I am hoping to publish it on Monday, May 10. The target audience is application developers, especially those using Mozilla's root store either directly or via NSS or Linux.
> "Application developers who continue to parse the certdata.txt file should use a script that correctly takes the trust records into account"
I'd be tempted to emphasize here the insufficiency of only considering the trust records (CKA_TRUST_SERVER_AUTH and CKA_TRUST_EMAIL_PROTECTION). If an application developer is going to use certdata.txt directly, then why wouldn't they also be advised to consider the distrust records (CKA_NSS_SERVER_DISTRUST_AFTER and CKA_NSS_EMAIL_DISTRUST_AFTER) that are also present in certdata.txt ?(Are we perhaps presuming that application developers want to have a simple bundle of PEM root certs with no associated metadata?)
I see you've now linked to https://github.com/agl/extract-nss-root-certs, which was last updated 8 years ago and doesn't currently consider any of the items mentioned on https://wiki.mozilla.org/CA/Additional_Trust_Changes, including the distrust records. Also, AGL's code only considers CKA_TRUST_SERVER_AUTH, not CKA_TRUST_EMAIL_PROTECTION.
In case it's useful, https://github.com/crtsh/root_programs/tree/master/mozilla_certdata is a fork of https://github.com/agl/extract-nss-root-certs that considers all of the trust and distrust records. Its output is an SQL script that updates the trust store data on crt.sh; obviously this isn't likely to be a useful output format for any other project to consume, but as example code that might not matter.
> We recommend that you use the certificate lists provided on the CCADB Resources page rather than directly parsing the certdata.txt file.
I notice that these CCADB certificate lists contain the certificates but not the distrust fields. Have you considered adding the CKA_NSS_SERVER_DISTRUST_AFTER information to the "PEM of Root Certificates in Mozilla’s Root Store with the Websites (TLS/SSL) Trust Bit Enabled (CSV)" list and the CKA_NSS_EMAIL_DISTRUST_AFTER information to the "PEM of Root Certificates in Mozilla’s Root Store with the Email (S/MIME) Trust Bit Enabled (CSV)" list?
Are these CCADB certificate lists always guaranteed to be in sync with the latest (mozilla-central) certdata.txt?
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/dccc97d9-4401-4ffb-b542-e814917f51b1n%40mozilla.org.