On Fri, 2017-06-30 at 18:46 +0000, David Adrian wrote: > Censys validates certificates against multiple root stores. At the end of > the day, what we want is a reliable and repeatable way to get an up-to-date > version of a root store in PEM format.
Can you please clarify if you're talking about the file format that starts with a header line (a) "-----BEGIN CERTIFICATE-----" or about the file format that starts with (b) "-----BEGIN TRUSTED CERTIFICATE-----" ? The Mozilla trust list cannot be correctly represented in file format (a), because it can only carry a list of certificates, but not trust information. It cannot carry information like "this CA should be trusted only for email security, but not for SSL/TLS servers". It cannot carry information like "this intermediate CA (or this end entity certificate) must NOT be trusted, although it has been issued by a trusted CA". Maybe Mozilla shouldn't publish a single, simple PEM file, in format (a) because it could give consumers the false impression that it's equivalent to the Mozilla trust. Potentially Mozilla could publish multiple different PEM files in format (a), one for the list of CAs that are trusted for email security, and another list of CAs that are trusted for web security. An additional PEM file could be published in format (a), which lists all the certificates that are explicitly blacklisted/distrusted in certdata.txt. Multiple files would be necessary, beause the standard PEM file format (a) cannot contain trust or distrust flags, therefore the name of the list would have to indicate the meaning of each list. However, file format (b) is able to represent trust and distrust information. I think it might have been been invented by the OpenSSL project. You can read more about it on the manual page that can be accessed with "man x509", see the -trustout and -addtrust and -addreject parameters. Today's certdata.txt can mostly be represented in file format (b). However, even today's certdata.txt is incomplete. It doesn't contain the list of distrusted certificates that Mozilla publishes with the OneCRL project, which means only the Mozilla applications can benefit from that information, but not other applications based on NSS. If Mozilla works on developing a consolidated CA trust and distrust list, ideally that list should contain the distrust information from OneCRL, too. But even with that, it will still exclude the dynamic distrust rules that this newsgroup has decided, which partially restrict some of the trusted CAs, such as the whitelist-only approval for some CNNIC roots, the restriction to certain domains for some ANSSI and TUBITAK roots, or the date base limitation for some StartCom and WoSign roots. If Mozilla is asked to publish a single file containing all trust in a PEM file format, which cannot express these partial distrust rules, should Mozilla include or exclude the partially trusted CAs? Kai _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
