Why do we use "too big to fail" CAs and the chain of trust instead of a global fingerprint database in a similar vein to how ssh works?
Tell me more
×
IT Security Stack Exchange is a question and answer site for
IT security professionals. It's 100% free, no registration required.
|
|
This is in fact two questions: why use CAs instead of a global fingerprint database, and why use CAs instead of doing what SSH does. There's no global fingerprint database for SSH, it's in fact the very opposite. In the SSH model, there's no built-in way to obtain the fingerprint of a server other than by connecting to it. The usual model for security is that when you connect to a server for the first time from a given client, you are prompted to manually verify the fingerprint, and when you connect again, the client verifies that the fingerprint hasn't changed. A common case where this model just works is when the client is on a laptop and you perform the first connection from inside the same trusted network that contains the server. Other than that, you are supposed to verify the fingerprint out of band, but most users just type “yes”. This system doesn't really scale; it's workable when you only connect to a handful of new hosts per year, but not for something like the web where you might connect to several new HTTPS sites every day. If there was a global fingerprint database, then it would for all intents and purpose be a universal CA. The definition of a CA is that you trust it when it tells you that a certain public key K belongs to a certain entity E. In the SSL protocol, a CA tells you this by providing a certificate that contains a cryptographic assertion that K is the public key of E. A fingerprint database, where you look up E and get K or vice versa, is a different implementation of a trust relationship assertion. So with a global fingerprint database, we'd have an even bigger “too big to fail” database. An approach that avoids the “too big to fail” problem is the web of trust as used by PGP. The principle is that you know that K is the key of E because someone you know tells you so. This approach is reasonably well-suited to applications such as email, because many emails are sent between people who have a prior existing relationship, or who have common friends. It isn't applicable in a case like “I want to connect to this merchant's website”, where you'd never heard of this merchant before seeing a link to it on a price comparison site, but you want to know that the website belongs to a corporate entity that has been doing business for several years, and not to some drive-by scammer who'll take your money and be gone next week. Having a single CA would raise concerns other than the risk to the integrity of the trust relationship database. When an entity registers a key, the CA is supposed to verify that the registrant has a valid claim to its purported identity (that the user registering a key for "Joe Bloggs" is really called Joe Bloggs, that the registrant for "Yoyodine, Inc." is indeed an authorized officer of Yoyodine, …), so the registrant cannot have privacy with respect to the CA. A choice of CA means that registrants have a choice of who they submit their private identity to. A state-run CA would be in a good place there because it knows the registrant's identity already — but which state? People may well want to declare identities that are not known to the state they live in. Another concern with a single CA is that it would have a monopoly on registration; having many CAs means that an entity is unlikely to be barred from participating. A way to reduce the impact of a failure of a CA would be to routinely have keys certified by multiple CAs. This is something people often do in PGP-style web of trusts: I want to verify Alice's key, so I ask Bob, who tells me that the key is correct. But while I'm sure that it's Bob telling me this because I've verified his key, I don't completely trust Bob to have verified Alice's identity. So I also ask Carol, and Dan, and so on. With many converging presumptions, I get a better assurance that Alice is who she claims to be. In the same way, having a website's key certified by multiple CAs, and not revoked by any, would reduce the concerns that one of these CAs may have been compromised or may have been lax in verifying the registrant's identity. However, this would require updates to a lot of software that verifies SSL certificates and increase the cost of key registration. |
|||||||||
|
|
I can't see how this would be a benefit. Currently we have many CA's which means that if one is broken for some reason (Diginotar, for example) we can simply (well, relatively simply) revoke the certs for that CA. If you just had one big dB, what happens when it is broken, either deliberately or accidentally? You don't have any useful or quick fallback options. |
|||
|
|
