What is meant by an "intermediate certificate authority?"
1If you really want to know "who", I'll just note that while many could be listed, part of the problem with the CA model is that we have no information on how many other intermediates there are out there. I would love to see good attempts at a list here, at any rate.– nealmcbJan 25, 2011 at 2:28
Any CA can be an "intermediate CA". Because "being intermediate" is defined by how the verifier sees it.
When you validate a certificate, you verify the signature which has been generated over that certificate by the CA which emitted the certificate. This signature is verified against the CA public key. If you know the CA public key "inherently" (e.g. it is one of the CA public keys distributed with the operating system), then the CA is a trust anchor, also known as root CA. On the other hand, if you know the CA public key only through validation of a CA certificate (a certificate issued to that CA by another CA), then the CA is deemed "intermediate". One can see the name "intermediate" as describing where the CA is in the chain of trust: the trust anchor is at the beginning, the end-entity is at the end (duh!), and anything in-between is "intermediate".
I can issue certificates for any CA, even without their consent or even awareness, by simply taking the certificate contents and resigning them with a key of my own. This means that every single CA on this planet is, potentially, an intermediate CA.
Thus, in the SSL case, it would depend on which certificate chain the server sends - the last one is the root, all others are intermediate. Oct 7, 2011 at 18:52
1@Paŭlo: and even so, the chain sent by the SSL server is indicative only; the client is free to obtain the server key in any way that it sees fit. The SSL server chain is just supposed to be apt to validation, should the client want to validate it that way. Also, sending of the root is optional (and mostly useless). Oct 7, 2011 at 19:30
A CA can delegate signing authority to another "intermediate" CA, and depending on the path validation rules used by the relying party, this may be trusted as much as the original.
This can be a problem, especially since so many CAs are probably in your trusted root store. See e.g. page 20 or so of the transcript in the reference below:
"… world governments are able to legally compel their national SSL Certificate Authorities to issue Intermediate CA certificates which allow agencies of those governments to surreptitiously intercept, decrypt, and monitor secured SSL connections …"
—Steve Gibson, Security Now episode #243 "State Subversion of SSL".
This still requires access to the actual traffic, but there are a variety of ways that a determined adversary can often accomplish that.
Contrast this with the situation in DNSSEC, which has a single root, and in which the keys associated with sub-domains can only vouch for the associated sub-domain.
For a look at some of the complications and possible future resolutions of the problem, see, e.g., ImperialViolet - DNSSEC and TLS to allow for exclusion of certificates issued either mistakenly or maliciously by CAs, and for avoiding MITM for sites even without a CA cert.
1That quote is so out of context and incomplete it's not even funny... There are a lot more things (that are a lot more complex to set up and deploy) that need to happen before a government agency having an Trusted Intermediate CA can "intercept, decrypt, and monitor secured SSL connections of any and all kinds." Jan 24, 2011 at 6:08
1@eugen-constantin-dinca I've updated the post to drop part of the quote and note some of the issues. And to contrast with DNSSEC. We can argue about whether the threats are funnier than the claims of a lot of CAs, but a lot of people think that snooping wifi traffic is a lot easier than getting a widely trusted intermediate CA cert. As always, it depends on the environment and the threat model....– nealmcbJan 25, 2011 at 2:21
I did not argue the possibility, rather the complexity. Tnx for the update. Jan 26, 2011 at 23:35