Why good public key repositories don't exist
They did — and they were destroyed, by an attack whose cause was a stated design goal rather than a bug. Anyone proposing a key registry today should be able to show they designed it with this history in hand. This page is that history, in five minutes, with sources.
June 2019: the certificate-flooding attack
An attacker flooded the OpenPGP certificates of two prominent contributors with bogus signatures, uploaded to the global SKS keyserver network. One key reached roughly 150,000 signatures. Anyone importing a poisoned certificate would break their own working installation in hard-to-debug ways — so the recommended mitigation became: stop retrieving data from the network entirely. The network's own maintainer called it unsalvageable.
The three abused properties
Each one becomes a design rule for any registry built afterwards:
| Abused property | Rule it produces |
|---|---|
| A certificate may carry unlimited signatures | Bound the size of a record |
| Anyone may append to anybody's certificate | Only the owner may write to their own record |
| Nothing distinguishes a legitimate signature from garbage | Every entry is signed by something you can check |
Why it could not be repaired
The fatal property was not an oversight. It was a design goal stated at the outset: a key server could add information to a certificate but could never delete either a certificate or information about a certificate. The maintainer's own conclusion was that changing a design goal of that magnitude means starting from a fresh sheet of paper rather than fixing anything.
The precise lesson about append-only
That design goal is append-only — a pattern this corpus itself uses in five places (write-only telemetry, staging folders, event ledgers, vault inboxes, relay channels), and rightly. A documented catastrophe caused by append-only deserves a precise resolution, not a shrug:
OUR CHANNELS a component appends to ITS OWN inbox or log nobody writes into another's record -> append-only is a guarantee THE KEY SERVERS anyone appends to ANYBODY'S certificate and nothing can be removed -> append-only is an attack surface
Append-only is safe when a writer appends only to objects it owns. It is fatal when anyone may append to somebody else's object. The rule to carry forward is not "append-only" — it is the writer owns what it writes.
What the replacement gave up
The key server built to replace the broken network (keys.openpgp.org) strips all third-party signatures and unverified identities. That stops the attack completely — third-party signatures were the vector. It also removes the web of trust, the entire model by which one person's endorsement of another's key conveyed confidence. Commentary at the time noted this was not a full solution for exactly that reason, and that no good global answer existed.
The trade, stated plainly: third-party attestations are what made the old system valuable and what made it attackable. A registry that permits them needs the size bound and the ownership rule; a registry that forbids them is safe and carries no social trust signal at all. For agent identity that choice matters more than usual, because an agent's key is only useful if somebody vouches for what the agent is allowed to do — the mandate concept.
Sources
- The attack, the breakage on import, ~150,000 signatures on one key, the "unsalvageable" assessment, and the stop-using-it recommendation: securityboulevard.com, itpro.com
- The three abused properties: gentoo.org
- The never-delete design goal, and the fresh-sheet-of-paper conclusion: the maintainer's own writeup, securityaffairs.com
- The replacement's trade — immune, at the cost of stripping signatures and identities; contemporary analysis that no good global answer existed: gentoo.org, blogs.gentoo.org