On Fri, May 6, 2016 at 6:58 AM, Rob Stradling <[email protected]> wrote:
> On 05/05/16 17:42, Nick Lamb wrote: > >> 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. >> > > Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is > that right? > Note that this is not just a Mozilla policy question, it's also a BR question: """ *Technically Constrained Subordinate CA Certificate*: A Subordinate CA certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates. ... Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.5 and audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. """ https://github.com/cabforum/documents/blob/master/docs/BR.md#161-definitions https://github.com/cabforum/documents/blob/master/docs/BR.md#81-frequency-or-circumstances-of-assessment It seems like the Mozilla policy's disclosure requirement basically boils down to saying that any CAs that are considered Unconstrained by the BRs (and thus require an audit) must also be disclosed to Mozilla. So we need to answer this question for the BRs as well as for the Mozilla policy. The BR text above seems to me to pretty much read as saying "look at the certificate", not "look at the certificate and all its parents" (i.e., C not CoAP). I'll grant that the phrase "uses" in the definition of Technically Constrained is a little ambiguous. --Richard > > 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. >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
