The cryptography in OpenPGP is not the part that fails people. The math has held up. What fails is everything around it, and key discovery sits at the top of that list. If you want to send an encrypted email to alice@example.org, you need Alice's public key before you can write a single encrypted byte. Getting that key correctly, and knowing it is really hers, has been the reason PGP never reached ordinary users.
Web Key Directory, usually shortened to WKD, is a small specification with a narrow goal. It lets a mail domain publish its users' public keys at a predictable HTTPS location, so a sending client can fetch the right key automatically from the same organization that runs the recipient's mailbox. It is defined in the IETF draft draft-koch-openpgp-webkey-service, authored by Werner Koch, the maintainer of GnuPG.
Why keyservers were never enough
The traditional way to find a PGP key was the public keyserver network, the SKS pool. Anyone could upload a key for any email address, and the servers never verified that the uploader controlled that address. That design decision aged badly. Keys accumulated thousands of unverifiable signatures, and in 2019 attackers weaponized this by flooding specific keys with so many signatures that GnuPG choked trying to import them. The SKS network effectively collapsed under its own trust-nothing model.
The deeper issue is that a keyserver answers the wrong question. It tells you "here is a key that claims to belong to this address," not "here is the key this address's own provider vouches for." Those are different statements, and only the second one is useful for routine encrypted mail. WKD moves the authority to where it belongs: the domain that operates the mailbox.
With a keyserver, you trust an anonymous uploader plus a web of signatures. With WKD, you trust that the operator of example.org is publishing the right key for its own users, and that HTTPS delivered it to you without tampering. For most people sending mail to a colleague or a company, that second model matches how they already think about who runs a domain.
How the lookup works
WKD is built entirely on things that already exist: DNS, HTTPS, and a fixed URL layout. There is no new protocol on the wire. When your client wants the key for alice@example.org, it does the following.
First it takes the local part of the address, the text before the @, lowercases it, and hashes it with SHA-1. The resulting digest is encoded in Z-Base-32, a compact alphabet designed to be readable. SHA-1 is used here purely as a fixed-length mapping function, not as a security barrier, so its cryptographic weaknesses do not matter for this purpose. The point is to turn a username into a stable, opaque string that does not leak the raw address in the URL path.
Then it requests one of two URL shapes over HTTPS:
- Advanced method:
https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/<hash>?l=alice - Direct method:
https://example.org/.well-known/openpgpkey/hu/<hash>?l=alice
The advanced method uses a dedicated openpgpkey subdomain, which lets a large provider host keys separately from its main website. Clients try advanced first and fall back to direct. The ?l= query parameter carries the original local part so the server can serve the right key even in edge cases. The response body is the binary public key, and because it arrived over a valid TLS connection, the transport itself authenticates that the key came from the domain it claims to.
In GnuPG you can trigger this directly. gpg --locate-external-keys alice@example.org will attempt a WKD lookup and import the key if the domain publishes one. Modern mail clients like Thunderbird do it silently the first time you compose to a new address.
What WKD proves, and what it does not
It is worth being precise here, because the value of WKD lives entirely in the boundary of its guarantee. WKD proves that the domain operator, at the moment of the request, chose to serve a particular key for a particular address, and that TLS delivered it intact. That is a real and useful property. It is also the whole property.
WKD does not prove that the person reading alice@example.org personally generated that key. On a corporate domain, the administrator publishes the directory, so the organization vouches for the key rather than the individual. It does not protect you if the domain itself is compromised, or if the operator is compelled to swap in a key they control. And because the trust anchor is the same TLS certificate system that secures the web, it inherits both the strengths and the weaknesses of the public certificate authority model.
WKD answers "which key does this domain publish for this address" reliably and automatically. It does not answer "is this the key the human at that address actually controls." For that stronger claim you still need out-of-band verification. The practical dividing line for any WKD deployment
This is why WKD pairs well with, rather than replaces, stronger verification. If your threat model requires certainty that a key belongs to a specific human, you still compare fingerprints in person or over a separate trusted channel, the same discipline described in trust-on-first-use key verification. WKD gets the right key onto your device automatically; a fingerprint check confirms the human behind it. The two layers do different jobs.
WKD next to the alternatives
| Mechanism | Who vouches for the key | Automatic |
|---|---|---|
| Public keyservers | Anonymous uploaders plus signature web | Partial |
| Web of Trust | Other users who signed the key | No |
| WKD | The recipient's mail domain operator | Yes |
| Manual fingerprint | You, out of band | No |
Compared with the Web of Trust, WKD gives up the property that any user can vouch for any key, and in return gets something the Web of Trust never delivered: it works without the sender doing anything. Compared with the keyserver network, it gives up universal coverage in return for an authoritative answer per domain. Those are sensible trades for the common case of writing to someone whose provider you already have a reason to trust.
Publishing your own directory
If you run your own domain, WKD is mostly a matter of file placement. GnuPG ships gpg-wks-client --print-wkd-hash to compute the hashed local part, and gpg-wks-server to help generate the directory tree. You export each user's public key to the right hashed filename under .well-known/openpgpkey/hu/, add a policy file at .well-known/openpgpkey/policy, and serve the whole thing over HTTPS with correct CORS headers. Providers including mailbox.org, Posteo, and Proton already publish WKD for their users, which is why sending encrypted mail to those domains often works with no key hunting at all.
One caveat worth stating plainly: because the hashed local part is derived from the address, anyone who guesses or knows an address can confirm whether that mailbox has a published key, and fetch it. That is by design, since the point is discoverability, but it does mean WKD is not a place to hide which of your users use encryption. For most organizations that is a non-issue. For a directory of at-risk users it is a consideration worth weighing.
Where Haven fits
Haven uses PGP for email so that messages to and from the wider world interoperate with any standards-compliant client, and WKD is part of what makes that interoperability smooth rather than manual. When the far side publishes a directory, the right key is simply there. When it does not, the fallback paths still apply.
Discovery is one of those problems that sounds minor until you watch a non-technical person try to send their first encrypted email and give up at the key step. Getting the correct key onto the device without a scavenger hunt is most of the battle. Web Key Directory does not make PGP perfect, and it does not replace verifying a fingerprint when the stakes call for it. What it does is remove the excuse that finding a key is too hard to bother, and that alone moves encrypted email closer to something people will actually use. For the adjacent piece of this puzzle, see our explainer on key transparency, which tackles the harder question of catching a provider that publishes the wrong key on purpose.