pki.sgit.ai / failure

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

Design, at the outsetA key server may add information to a certificate. It may never delete either a certificate or information about one. Stated as a goal, not arrived at by accident.
June 2019An attacker floods the OpenPGP certificates of two prominent contributors with bogus signatures, uploaded to the global SKS keyserver network. One key reaches roughly 150,000 signatures.
On importAnyone retrieving a poisoned certificate breaks their own working installation, in hard-to-debug ways. The recommended mitigation becomes: stop retrieving data from the network entirely.
The assessmentThe network's own maintainer calls it unsalvageable. Changing a design goal of that magnitude, he concludes, means starting from a fresh sheet of paper rather than fixing anything.
AfterA replacement key server strips all third-party signatures and unverified identities. Immune to the attack — and the web of trust goes with it.

The three abused properties

Each one becomes a design rule for any registry built afterwards — which is the only reason this history is worth a page:

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. Everything downstream follows from that — including the impossibility of a fix, because a design goal is not a bug you patch.

The precise lesson about append-only

That design goal is append-only — a pattern this project 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 therefore not "append-only" — it is the writer owns what it writes. Stated that way, the pattern survives the history intact, and rule 1 is what carries it.

The same property, both ways

	Append-only, owner-writes	Append-only, anyone-writes
Who may write to a record	Only its owner	Anybody
Can a stranger grow your record?	No	Without limit
Is every entry attributable?	Yes — signed by the owner	No — garbage is indistinguishable
Can something be withdrawn?	Yes — a signed append supersedes	Never — by design
Failure mode	A record grows slowly, in the owner's own hand	Destroyed the network

One word separates the column that works from the column that ended a global network — and it is not "append-only". The four rules this produces →

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 enforced hard; 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.

Why this page leads the site

Two reasons, both practical. It is useful on its own — a reader who never touches an agent registry still leaves knowing why the public key ecosystem is in the state it is in. And it is the evidence that whatever comes next was designed with the history in hand: the rules are not four preferences, they are three abused properties plus the deletion problem, turned around one at a time.

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
This page's own source document, captured verbatim with all citations: the scoping brief (v0.33.59, 16 August 2026)

← Home Next: the four rules →