On 26/03/14 15:29, Emilia Kasper wrote:
Wow, thanks for all the great feedback!
On Wed, Mar 26, 2014 at 2:47 PM, Daniel Kahn Gillmor wrote:
<snip>
This is a pretty perverse situation, though, and perhaps the answer is
that CA X just shouldn't do that kind of weird/chained reissuance over
the key in Y. I've also done no certificate surveys to see if this sort
of scenario has actually happened anywhere in the modern landscape.
Cross-signing happens all the time but afaik the other way around, i.e.,
an intermediate Y' corresponding to a _newer_ root cert Y is
cross-signed by some _older_ root cert Z. So an old client would usually
know only Z and a newer client would know Z and Y (or even Y' - some
clients directly trust intermediates these days).
That's true in many cases, but...
Comodo gained entry into the CA marketplace by purchasing one set of
roots (from AddTrust) that were in the Netscape trust store, and another
set of roots (from The USERTrust Network, aka UTN) that were in the
Microsoft trust store. Neither set of roots were "older" or "newer".
UTN cross-certified AddTrust. A few years later we were able to get one
of the AddTrust roots added to the Microsoft trust store. After that,
it made more sense to have the cross-certification relationship the
other way around, and so AddTrust cross-certified UTN.
(Cue various cross-certification loop bugs in Mozilla's code, but I digress)
Oh, BTW, bi-directional cross-certification also occurs in Bridge CA
scenarios such as the Federal PKI.
<snip>
CT might be a good place to gather this information from -- are there
plans to ensure that all intermediate CAs are logged publicly?
No current plans for CT to require logging intermediates. But actually,
if we go the autocorrect route then we should just implement AIA
fetching. Modern certs should have a CA Issuers field in the
AuthorityInformationAccess extension in them that the chain builder
could follow recursively. I've now looked a bit more at the mod_ssl code
and it's a bit of work but maybe not all that different from doing OCSP,
really?
So, we arrived at the point where "AddTrust External CA Root" became our
primary root certificate, but we still needed to involve UTN in the cert
chain in order to be trusted by old Windows platforms (i.e. Windows
2000, and XP boxes that have Automatic Root Update disabled).
Noting that Windows clients do AIA fetching, we started including a
carefully constructed pair of AIA->caIssuers URLs in many of the
intermediate certs we issue and still use today.
e.g. http://crt.comodoca.com/COMODOSSLCA.crt
CA Issuers - URI:http://crt.usertrust.com/AddTrustExternalCARoot.p7c
CA Issuers - URI:http://crt.usertrust.com/AddTrustUTNSGCCA.crt
Most platforms trust "AddTrust External CA Root", so they don't chase
either of these AIA URLs.
Old Windows boxes download the first URL (a PKCS#7 "certs only" bundle
containing the self-signed "AddTrust External CA Root" root and a
cross-cert issued to it by one of the UTN roots), and are able to build
a chain up to AddTrust, or failing that, UTN.
Even older Windows boxes don't support PKCS#7 AIA caIssuers URLs, so
they then download the second URL and build a chain up to UTN.
A correctly configured TLS server that uses one of our certs will send a
cert chain terminating with "AddTrust External CA Root".
I do _not_ want mod_ssl to "autocorrect" this by following the AIA
URL(s) and deciding to also send the cross-certificate issued by UTN.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
