This blog post examines options to retire the Web-of-Trust (WoT) and the SKS key pool
Recap: The WoT is a decentralized trust model that was created in an attempt at making a decentralized alternative to the centralized trust model of a PKI with it’s hierarchical CA system. If Alice signs Bob’s key, Alice vouches for Bob being who he claims to be. If enough users sign Bob’s key, any third party can have a reasonable expectation that Bob is in fact the Bob they want to contact.
At Whiteout, we conciously chose to bypass the WoT in order to make key management easy. Without looking up a key’s signatures, a user can be reasonably sure that keys from the Whiteout Key Server belong to whoever owns the email address, because we validate their contact's public key. But unfortunately, that is not true for the SKS key pool.
What’s Wrong With The WoT?
What exactly is the problem with the WoT and why do we need a replacement? Here are a few issues that fundamentally hinder adoption:
Key Signing Parties: At a key signing party, people sign other people’s keys when they are physically present, possibly with having their ID checked and personally confirming their key’s fingerprint. Those are only for the most hardcore of users, not feasible at all for average users. If this is the smartest solution we have to establish a high degree of trust, it is time for a change.
Revocation: Revoking your public key, should you have lost the private key for whatever reason, is impossible. The key will just live on and will never be renewed. In the words of Phil Zimmermann: “I’m sorry, you’re hosed”. Trust me, that stuff happens more often than you think!
Transparency and Authenticity: How do you trust a system where anyone can claim to be somebody he’s not?
Is There A Better Way?
At the PGP Summit earlier this year, we had a get-together with other (email) encryption projects. Among them were Werner Koch (GPG), GPGTools, OpenKeychain, and the Google e2e team. I moderated a session centered around alternatives for public key management, and finding requirements for the next generation of Identity Providers (IPs). We specifically discussed these requirements:
Federation: Decentralization creates complexity and can be really tricky to get right. Centralization is not an alternative, for obvious reasons. But federation would be a feasible middle-ground here. This way, every provider can handle their customers’ keys for them.
Authenticated Uploads: In this model, Bob has to authenticate to the Identity Provider (IP), instead of the sender. This makes it easier and creates a trust relationship between IP and user.
Key Server Integrity: The key store should be write-only, with an audit trail of what has been added.
Revocation: In an append-only world, you would simply take the latest key and replace the key before with it. Remember, the upload itself is authenticated and audited, so you can be fairly sure that you’re talking to the correct person!
HKP-compatible API and/or REST API, CORS, TLS: This should just be part of any modern approach.
A Better Tomorrow
Google has published a lot about their ideas in their Github Wiki. Their ideas are in line with the requirements presented above and well worth the read.
Keybase.io has been very vocal with their idea about how an IP should work. It is definitely worth checking out their documentation.
Very little is known about Facebook’s current efforts, except that FB exposes the public key through the graph API.
All in all, we’re excited to see all of the recent efforts to improve over the status quo!