On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote: > That logic would imply that all of the "Not Trusted by Mozilla" > intermediates should be moved to "Disclosure required!", given that I > can't prove the non-existence of cross-certificates that would cause > these intermediates to become trusted!
As a relying party I think the correct algorithm here is an iterative one, or at least, is best explained that way. Given the set of disclosed certificates, create a graph of CA nodes, reachable from the NSS public trust roots by following certificates that meet certain criteria. From each of those nodes, if you know of any certificates that would also meet the criteria, which are not yet disclosed, you must disclose them. Repeat until nobody discloses any more certificates and thus the graph stops changing. A rough stab at the criteria goes like this: CA:TRUE (and not ruled out by path length?) notBefore < now() < notAfter() EKU either non-existent or contains TLS-server something about name constraints ? Why do I say the algorithm is iterative ? Here's an extreme example. Suppose there are two rather incestuous companies Foo and Bar, each is a public root CA but also operates a confusing number of intermediates built up over many years, some even prior to the World Wide Web. Their root CAs are respectively Foo Root CA and Bar Root CA and all their intermediates have their name in the CN (already an improvement over the reality we face today). Step 1. Foo identifies that "Foo Root CA" signed an unconstrained cert for "Bar Public Issuer Class 8" and they disclose that, although the only record they still have is a stained bar napkin so they hope they copied the serial number down correctly. Step 2. Bar now remembers that "Bar Public Issuer Class 8" is still trusted, it had a 25 year expiry date and from archive tapes they find it signed an unconstrained cert for "Foo SHA-1 Upgrade CA" so they disclose that. Step 3. Foo is surprised to be reminded of the old "Foo SHA-1 Upgrade CA" and that it's still technically trusted despite being retired back when Twitter didn't exist, they dig through old records and find it signed "Bar New 2048 RSA" so they disclose that. Step 4. Bar is a little embarrassed, the keys from "Bar New 2048 RSA" are actually still in use in an OCSP server, but yep, it was technically unconstrained, and worse yet they find it was used to sign a cert for "Foo Private CA Oscar Zulu" before moving to its OCSP role. Step 5. Foo are even more embarrassed that "Foo Private CA Oscar Zulu" is actually publicly trusted, they've been moving clients who want Intranet certs onto it, and completely forgot it has a cross-signature. Whoops. At least it didn't sign any other CA certificates though. The algorithm terminates. As I understand it this algorithm, once performed properly, discloses all the intermediate certificates that should end up in a chain for a certificate I, a normal relying party, end up relying on. Relying parties can make trust decisions based on these disclosures, and Mozilla can inspect e.g. audits and evidence of appropriate technical controls for the disclosed intermediates. If I run into a bad certificate (not talking about merely non-conforming, but e.g. a fake "google.com" or something of that sort) with an undisclosed intermediate in the chain Mozilla can most reasonably as a first step actively distrust that undisclosed intermediate. It would be literally _incredible_ for a root CA to argue that an intermediate is so important that Mozilla should still trust it despite the bad certificate, yet so unimportant they forgot it even existed and so didn't disclose it. From there Mozilla can investigate the intermediate's issuer. Did they "forget" any others? But in many cases just this first step plugs a big hole without waiting for weeks of discussion to conclude. So far what we tend to see with intermediates that have been "forgotten" is that they aren't supposed to be used to issue TLS certificates. Distrusting those as a result of a security incident would be no great loss to the web PKI. A "submarine" intermediate, one that was not only technically unconstrained but deliberately signing end-entity TLS certificates or signing another CA that does so, yet not disclosed to Mozilla during the current process would therefore be rare and deserving of extra scrutiny if found later. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
