On Tue, Apr 9, 2019 at 11:25 AM Nick Lamb via dev-security-policy < [email protected]> wrote:
> Mozilla's wiki has a page about the subCAs > > https://wiki.mozilla.org/CA/Intermediate_Certificates > > On that page I see a link labelled: > > "Non-revoked, non-expired Intermediate CA Certificates chaining up to > roots in Mozilla's program with the Websites trust bit set" > > And clicking that link produces a CSV file. Fine so far. > > I anticipated that this CSV file would be a set of subCA certs which > were trusted by Firefox to issue leaf TLS certs, since on the face of > it that's what the title claims. > > > But, that seems to be wrong, for example the file includes > "Symantec Shared Individual Email Certificate Authority" > https://crt.sh/?id=197857126 > > which as its name suggests does not have the Websites trust bit set > So. What's actually going on here? Is there a trick that I'm not > understanding to processing this file? Why are there certs in it that > actually aren't for trusted subCAs at all? > > Is the link wrong? > > What is the recommended procedure for someone who wants to determine > whether a random leaf cert they're looking at would in fact be trusted > in Firefox? Other than "try it in Firefox" ? > I think it's merely a misparsing of the description. The intermediate you referenced - https://crt.sh/?id=197857126 - chains to a "root in Mozilla's program with the Websites trust bit set". That root is https://crt.sh/?caid=1110, and you can see, it has the Website Trust Bit set. I suspect you parsed it as "intermediates ... with the websites trust bit set", but that's not what that report is. The answer for how to determine that is, yes, to attempt to construct a chain and determine whether the intersection of the root trust policies (which are maintained in CCADB) and the attributes of all the certificates in all of the chains to that root overlap with the Website trust bit. The answer for whether it would be trusted in Firefox is, indeed, canonically to "try it in Firefox". If you're willing to accept a more probabilistic approach (even if that actual probability may be 99.999%), then you'd need to evaluate the particular certificate paths. For example, you could use Golang along with the stock Go X.509 library (or if you want more nuanced handling and certificate path enumeration, ZMap's ZCrypto - https://github.com/zmap/zcrypto , as used by Censys) to do this. crt.sh uses PGSQL to compute these paths, if I recall correctly ( https://github.com/crtsh/certwatch_db/blob/master/determine_ca_trust_purposes.fnc I believe) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
