# Can we design a public-key infrastructure without certificate authorities?

In a recent essay, Bruce Schneier tasks the engineering community with redesigning and rebuilding the vulnerable parts of the Internet's backbone.

We need to figure out how to re-engineer the Internet to prevent this kind of wholesale spying. We need new techniques to prevent communications intermediaries from leaking private information.

In my mind, one of the most glaringly vulnerable parts of the Internet's security infrastructure is the certificate authorities. They're big, private companies, vulnerable to legal and extralegal attacks from governments and hackers alike. They nevertheless hold the keys (no pun intended) to the kingdom, cryptographically speaking.

Are these kinds of central trust authorities the sine qua non of a practical public-key infrastructure? If so, why?

If not, what alternatives exist? What would it take to use one of these alternatives in a new, less vulnerable public-key infrastructure? What is the cryptography community's role in this discussion?

-
There is the web of trust concept. But I'm not sure if this would work for HTTPS like it works for email. –  Paŭlo Ebermann Sep 18 '13 at 20:01
@PaŭloEbermann: That's what I was going to say ... imagine trying to apply the WOT model to, say, Google. All of those people ... I just don't see it working. –  Reid Sep 18 '13 at 20:06
There is the Identity Based Encryption, where the public key is, say, your email address or your name.surname or your social security number or ... You still need a trusted authority to ship the corresponding private key. –  ddddavidee Sep 18 '13 at 20:19
One could easily get lots more (so, perhaps not "central") trust authorities if clients did $\hspace{1.02 in}$ "not mind receiving more than one certificate for the" servers. $\:$ –  Ricky Demer Sep 19 '13 at 2:21
@ddddavidee So you replace a trusted third party by an even more powerful trusted third party. The only advantage of IBE is that you don't need to be connected to the internet to encrypt a message with their private key. That advantage is obviously irrelevant for applications that inherently require internet connectivity. –  CodesInChaos Sep 19 '13 at 15:35

There was a post on security.stackexchange last week about this. SSL/TLS with Certificate Authorities for all intents and purposes is now completely insecure from governments and any organisation who has a CA pre-trusted inside the standard web browsers.

DNSSEC will also fall under the same scenario because at the top level you have a particular government in control of the DNS root.

There is one design that may help solve the issue. There's also an excellent talk explaining the issue with Certificate Authorities. At about 35 mins he discusses the problems with the Perspectives Project and recommends another solution called Convergence. I would recommend everyone moves to something like that as a matter of urgency.

-

There is "PGP network of trust" (also implemented by other OpenPGP-compatible systems like GnuPG) which does exactly that.

You start off with nobody to trust except yourself. You decide to trust some friends of yours and hand your public key to them to have it signed. This signed public key will be automatically trusted by anyone else who trust your friends. It can spread further in this fashion. By that, you will be able to set up a network of trust based on friends that trust friends.

-

Another approach is done by the Perspective Project.

With it you setup your server and it will monitor the certificates of the sites. You can then subscribe to any number of these monitoring servers and verify them against each other. Since you decide which ones you want to trust, instead of 1 certificate being certifiable by just 1 person, it should be harder to compromise. It also supports self-signed certificates out of the box.

-