# 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. Sep 18, 2013 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, 2013 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. Sep 18, 2013 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. $\:$
– user991
Sep 19, 2013 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. Sep 19, 2013 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.

• 2022 update: In 2013 Moxie had already given up on convergence and switched to pinning, which was adopted (with some differences) in 2015 and promoted for a while, but now dropped due to causing too many problems. A convergence followon lasted another year before dying. perspectives appears to have lasted longer; its website still exists but hasn't been updated since 2018. Jan 16 at 2:53

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.

The ENS project - which runs on the Ethereum public blockchain - provides a fully decentralized naming service that is permissionless and censorship resistant.

And Cloudflare operates a public global gateway to classic DNS that auto-maps ENS <name>.eth and DNS <name>.eth.link. For example, https://tornadocash.eth.link/ and https://app.ens.domains/name/tornadocash.eth/details . Of course, in this DNS->ENS resolution, Cloudflare can be forced to remove <name>. To avoid this, an ENS enabled resolver library (in the client) or app (e.g. Brave) is necessary.