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?
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
