Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Who maintains the database? In particular, who has the right to add fingerprints to it? What happens when it's down? – CodesInChaos Jan 1 '13 at 16:42
BTW we're using a bit in that direction by having DNSSEC deliver fingerprints (DANE). – CodesInChaos Jan 1 '13 at 16:43
Wait, so you are suggesting that every OS ships with millions and millions of fingerprints for every website that uses certificates? That's impratical because of (1) the sheer volume and (2) turnaround/update times. – us2012 Jan 1 '13 at 17:05
@User145678 Yes, every website does need one. If only the private data is encrypted, encryption becomes suspicious. Privacy is becoming more and more of an issue. But this is besides the point. Even if there were only 1 million fingerprints, that would mean close to 3000 updates every day, assuming an even distribution. The solution is delaying updates, but I wouldn't want to have to wait a month to get my webshop https-enabled. – Luc Jan 1 '13 at 20:33
So, instead of several "too big to fail" CAs, you recommend replacing it with one "too big to fail" fingerprinting authority? :) – mricon Jan 1 '13 at 23:03
up vote 2 down vote accepted

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.

share|improve this answer
So basically you're saying that the major reason we sacrifice our autonomy is to keep the scammers away (so that they would require a legal proof before getting certified). My proposed system lacks that (there is no problem in getting certified, because the only proof you need is to own a domain to add a fingerprint. IMHO, we already pay for domains, storing a fingerprint could be part of that. – User145678 Jan 2 '13 at 16:00
@User145678 Indeed, SSL registration could be tied to domain registration. That's what DNSSEC encourages. But domain registrars typically don't check the identity of registrants, and more importantly the identity of registrants is not what users care about. Using again the example of a web merchant, if I buy something on, I don't just want to know that I'm paying to the legitimate owner of the domain, I want to know that I'm paying to someone who has a reputation to maintain, who has an address where I can sue, ... – Gilles Jan 2 '13 at 17:11
ICANN requires that all information in your registration be valid. In my particular case in order to register, I need to go through the bank and the registry checks whether the name I'm registering under is the same as the person who is paying for a domain. Furthermore, it should be more of a concern to banks and payment systems (e.g. implementing escrow system, validating account owners) and not enforced on a technological level. Basically, it's not a bazaars fault that you found a shady seller. You knew the risks and you still went there... – User145678 Jan 3 '13 at 8:07
@User145678 Requires != checks. The only ways in which my DNS records are tied to my real identity is information that I declared but nobody checked, and the credit card I paid with (and that information might only have gone to a payment processor). Registrars aren't used to checking identities. Furthermore, there are so many registrars all over the place that it's hard to trust that all of them would check identities correctly — registrars are too small for their failure to matter! – Gilles Jan 3 '13 at 10:07

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.

share|improve this answer
Domain DNS fingerprint. – User145678 Jan 2 '13 at 16:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.