# pki.sgit.ai: The Public Key Registry Has A Documented Failure To Learn From, And It Was Caused By The Pattern This Corpus Uses Everywhere **version** v0.33.59 **date** 16 August 2026 **from** Human (project lead) **to** The sgit.ai site agent, Engineering, Architecture **type** Strategy brief *Fourteenth of 16 August. Scopes a site and a registry. The historical failure is grounded and cited, and it produces the design rules directly. Contains a tension between that failure and a pattern this corpus has adopted five times.* --- ## What This Is A site collecting existing work on public key infrastructure, and a public registry of keys, with one historical lesson that should shape the registry before a line is written: **the memo recalls noticing that good public key repositories did not exist, which is right and the reason is documented rather than accidental, because the global key server network was destroyed in 2019 by an attack its own maintainer called unsalvageable, in which two well-known contributors had their certificates flooded with garbage signatures until importing one would break a working installation, with one key reaching around a hundred and fifty thousand signatures; the attack abused three properties, being that a certificate may carry unlimited signatures, that anyone may append to anybody's certificate, and that nothing distinguishes a legitimate signature from garbage, and the reason it could not be fixed was a design goal stated at the outset, that a key server could add information to a certificate but could never delete either a certificate or anything in it; that goal is append-only, which is the pattern this corpus has now adopted five times and rightly, so the tension needs stating precisely rather than resolving by instinct, and the precise form is that append-only is safe when a writer appends only to objects it owns and fatal when anyone may append to somebody else's, which is exactly the difference between the write-only channels already in use and a naive key server; that formulation also supplies the fix without abandoning the pattern, because revocation can be an appended statement signed by the key owner rather than a deletion, which is the supersede-rather-than-delete rule already established for corrections, so the registry stays append-only and still supports withdrawal; the replacement key server that emerged strips all third-party signatures and unverified identities, which stops the attack and removes the web of trust with it, so that trade should be made deliberately rather than inherited; the material for the site is substantial, since seven hundred and twenty-nine files mention the subject and dedicated documents go back to February including an architecture, a messaging implementation, document identity, operating modes and a brand strategy; and the reason to attempt this now is the one the memo gives, that vaults supply the storage and distribution layer that was missing, which makes the registry a product of existing infrastructure rather than a new system.** It is the fourteenth document of 16 August (cross-ref: the v0.33.59 relay pattern brief, the v0.33.49 distributed vault brief, the v0.33.59 NHI site brief, the v0.33.59 shared drives research, and the v0.33.57 corrections brief). New contributions: **the keyserver failure as the registry's design input, the three abused properties turned into rules, the append-only tension formulated precisely, revocation as a signed append, and the trade the replacement made.** ## The Material Exists, In Depth Worth establishing because it changes what the site is. **Seven hundred and twenty-nine files in the repository mention the subject**, with dedicated documents going back to February: an architecture debrief, a messaging implementation, research on integration with models, a document identity brief, operating modes, a provenance treatment, and a brand strategy. Thirty-one files reference the presentation material the memo wants recycled. So this is not a research site to be built from scratch. **It is a publication and curation problem**, like the identity site scoped earlier today, and the same discipline applies: organise by the question a reader arrives with rather than by date, and promote the strongest artefacts to pages rather than entries. ## The Registry Has A Documented Failure The memo's recollection is correct and the history is worth knowing in detail, because it produces the design. The project lead: **"I remember talking about ages ago, realising there wasn't a lot of good PGP and public key repositories."** **There were, and they were destroyed.** In June 2019 an attacker flooded the certificates of two prominent contributors with bogus signatures uploaded to the global key server network. One key reached roughly **a hundred and fifty thousand signatures**. Anyone importing a poisoned certificate would break their installation in hard-to-debug ways, and the recommended mitigation was to stop using the network entirely. Its own maintainer called the network **unsalvageable**. **The attack abused three properties**, and they are worth listing exactly because each becomes a rule: | 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 | And the reason it could not be repaired was not a bug. 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 Tension With Our Own Pattern **That design goal is append-only**, which this corpus has adopted five times and for good reasons: write-only telemetry, the staging folder for issues, the usage event ledger, the vault inbox, and the message channels in the relay pattern. It was named as the house pattern on 2 August. So a documented catastrophe caused by append-only deserves more than a shrug, and the resolution is precise rather than approximate. **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.** That is the actual difference: ``` 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 ``` So the existing pattern is not implicated, and a registry must not inherit it naively. **The rule to carry across is not append-only, it is that the writer owns what it writes.** ## Revocation Without Breaking The Pattern The other half of the failure was the inability to remove anything, and a key registry needs removal more than most systems do, because **a compromised key must be withdrawable and that is the single most important operation a registry performs.** The corpus already has the resolution, from the corrections work of 9 August: **supersede rather than delete.** A correction is a new statement marking the old one superseded from a date, so the chain stays readable and the earlier state stays answerable. Applied here: **a revocation is an appended statement signed by the key being revoked**, not a deletion. That gives everything at once. The record remains append-only. The revocation is verifiable, because only the key holder could have signed it. Nothing is destroyed, so what a key said before its revocation stays checkable. And a reader always sees the current state by reading to the end. **Which means the registry can be append-only and support withdrawal**, provided only the owner may append. The two rules work together rather than against each other. ## What The Replacement Gave Up Worth knowing because the same trade will present itself. The key server built to replace the broken network **strips all third-party signatures and unverified identities**. That stops the attack completely, since third-party signatures were the vector. It also removes the web of trust, which was 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 that reason, and that no good global answer existed. So the trade is: **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. **That decision should be deliberate.** For agent identity, third-party attestation may matter a great deal, because an agent's key is only useful if somebody vouches for what that agent is allowed to do, which is the mandate concept below. ## What Vaults Change The memo's reason for attempting this now, and it holds up. The project lead: **"now we have the vaults that we can use to back this up, so that means that this is now much more realistic."** Three things the vault layer supplies that a key server had to build: **Distribution.** A published vault is readable from static hosting, clonable over plain requests, and mirrorable by anybody, per the work earlier today. A registry does not need its own replication protocol. **Custody without access.** The brief written earlier today named this: anybody can mirror a vault they cannot read. For a registry whose contents are public that matters less, and it means untrusted mirrors are safe by construction. **And versioning.** History is native, so the state of a key at any past date is answerable without designing an audit log. What the vault layer does **not** supply is the ownership rule, the size bound or the signature checking. Those are registry logic and they are the part to build carefully. ## Agent Identity And The Mandate The memo connects the registry to agent identity and the connection is the interesting part. The project lead: **"we start to create identities for our agents using PKI, so we can start to create a sort of a mandate for the agent, and we can give them a certificate."** **The mandate is the idea worth developing**, and the corpus already uses the word in the risk work, where a mandate is what somebody is authorised to do rather than who they are. That maps onto a distinction the research earlier today found missing everywhere: current systems give an agent **your** identity and therefore all your permissions. A signed mandate would separate the two: | Statement | Says | |---|---| | **Identity** | This key belongs to this agent | | **Mandate** | This agent may do these things, until this date, on whose authority | Both are signed statements in the registry, which means both are checkable by a third party, and the second can be revoked independently of the first. That is a materially different position from a bearer token, and it is what the relay pattern from earlier today needs to become more than a per-vault convention. One caution carried from that brief: **a signed mandate constrains what an agent may be authorised to do and not what it does within that authority.** It is one control among several, not a complete answer. ## Fractal, And What It Requires The memo wants this fractal. The project lead: **"as with everything, this has to be fractal. This could be PKI, PKI, PKI. This supports public and private PKI stores."** The structure works, and it needs one thing named: **a fractal trust structure requires roots.** A key is trustworthy because something you already trust vouches for it, and in a nested arrangement each store must state which roots it accepts. Otherwise the fractal property produces a graph nobody can evaluate. That is the same shape the relay pattern raised this morning about names being identities: **who may claim to be a root is a privileged decision** and needs an answer even if the answer is that it is set once by an operator. The private store case is the easier and probably the more valuable one commercially. An organisation running its own registry for its own agents, mirrored and verifiable, has a smaller trust problem and a clearer buyer than a global public registry does. ## The Site Same conventions as the other sites, with two additions specific to this one. **Lead with the failure.** A page explaining why public key repositories are in the state they are in, with the three abused properties and the design goal that made repair impossible, is genuinely useful to a reader and it establishes that whatever is proposed afterwards was designed with knowledge of the history. It is also the most linkable thing the site will have. **And state the rules the registry follows**, publicly, as claims that can be checked: only the owner writes to their own record, revocation is a signed append, records are size-bounded, every entry is signed. Those are four sentences and they answer the question a reader will have. The participant discipline from earlier today applies as usual, and lightly here, since the historical claims are all externally verifiable. ## Build Order 1. **The collection**, organised by question, with the February and March architecture material promoted. 2. **The failure page**, which is short, useful and independent of anything being built. 3. **The four rules**, published as the registry's stated design before the registry exists. 4. **A private registry**, for our own agents, which is the smaller problem and the one with a real user. 5. **Mandate statements**, separate from identity statements, revocable independently. 6. **A public registry**, last, since it inherits every hard problem of the private one plus trust roots and abuse. Step four before step six is the important ordering. **A registry with one organisation's agents in it is testable; a global one is a commitment.** ## What This Does Not Try To Be - **Not a new key server.** A registry designed from a documented failure, with different rules. - **Not append-only in the way that failed.** Append-only with the writer owning what it writes. - **Not deletion-free.** Revocation is a signed append, which supersedes without destroying. - **Not automatically a web of trust.** Third-party attestation is a deliberate choice with a known cost. - **Not public first.** A private registry is testable; a public one is a commitment. ## Honest Tensions | Tension | Note | |---------|------| | Append-only as house pattern | It is right for channels and it is what destroyed the key servers, so the ownership rule is what separates them | | Third-party attestation | It is what made the old system valuable and what made it attackable, and mandates may need it | | Size bounds on records | They prevent the flooding attack and they will one day reject a legitimate record | | Fractal trust | Nesting is powerful and it requires every store to declare its roots, or the graph is unevaluable | | Public registry | It is the memorable idea and it carries abuse, moderation and trust-root problems a private one does not | | Reusing existing material | Seven hundred documents is depth and most of it will not appear on the site | ## Open Questions | Question | Notes | |----------|-------| | Does the registry accept third-party attestations? | The central design choice, with a documented failure on one side and no social trust on the other | | What is the size bound per record? | Generous enough to be invisible, small enough to stop flooding | | How is the binding between identity and key verified? | The replacement server used email; agents have no equivalent, so this needs an answer | | Who may be a trust root? | A privileged decision needing a stated answer, even a simple one | | Is a mandate a separate object from an identity? | It should be, since they revoke independently | | What does an agent's identity attest to? | Which agent, running where, on whose authority, and how any of that is checked | ## Relationship To Previous Briefs | Date | Document | Relationship | |---|---|---| | 16 Aug | `v0.33.59__arch-brief__relay-pattern-encryption-signing-and-ordering-are-three-mechanisms.md` | Per-agent keys and the names-are-identities problem, which the registry would answer | | 17 Jul | `v0.33.49__arch-brief__sg-send-fractal-distributed-vault-architecture-registers-of-registers-messages-as-graph-transformations-transaction-log-pki-authorization.md` | Authorisation by keys, specified before this | | 16 Aug | `v0.33.59__research-brief__shared-drives-for-agents-everything-runs-on-your-identity-segregation-not-scoping.md` | The finding that no available system supports per-agent keys, which this would address | | 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | The identity gap this is the cryptographic half of | | 9 Aug | `v0.33.57__arch-brief__sg-send-fact-does-not-exist-in-a-vacuum-agenda-is-context-corrections-must-propagate.md` | Supersede rather than delete, which makes revocation compatible with append-only | --- ## Key Claims | # | Claim | |---|-------| | 1 | The material exists in depth, so this is a curation problem rather than a research one | | 2 | Good public key repositories did exist and were destroyed by a documented attack in 2019 | | 3 | One key reached around a hundred and fifty thousand signatures, breaking installations that imported it | | 4 | The attack abused unlimited signatures, universal append rights, and unverifiable signatures | | 5 | It could not be repaired because the inability to delete was a stated design goal | | 6 | That goal is append-only, which this corpus has adopted five times | | 7 | Append-only is safe when a writer appends to what it owns, and fatal when anyone appends to another's record | | 8 | Revocation can be an appended statement signed by the key owner, which keeps append-only and adds withdrawal | | 9 | The replacement server strips third-party signatures, which stops the attack and removes the web of trust | | 10 | Vaults supply distribution, safe mirroring and versioning; the ownership rule and size bound are registry logic | | 11 | A mandate should be a separate signed statement from an identity, revocable independently | | 12 | A private registry is testable and a public one is a commitment, so build the private one first | --- ## Sources - The June 2019 certificate spamming attack against two prominent contributors, the flooding of certificates with bogus certifications, the resulting breakage of installations importing them, one key reaching roughly a hundred and fifty thousand signatures, the maintainer's assessment that the network was unsalvageable, and the recommendation to stop retrieving data from it: https://securityboulevard.com/2019/07/an-attack-on-sks-keyserver-network-a-write-only-program-poisons-two-high-profile-openpgp-certificates/ and https://www.itpro.com/security/33954/decade-old-flaw-in-pgp-is-finally-being-exploited - The three properties the attack abused, namely that keys may contain an unlimited number of signatures, that anyone may append signatures to any key, and that there is no way to distinguish a legitimate signature from garbage: https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html - The original design goal that key servers could add information to certificates but could never delete either a certificate or information about one, and the assessment that changing a design goal of that magnitude means starting from a fresh sheet of paper rather than repairing anything: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f and https://securityaffairs.com/88071/hacking/poisoning-pgp-sks-key-network.html - The replacement key server being immune to the attack at the cost of stripping all signatures and unverified identities, and contemporary analysis that this was not a complete solution and that no good global answer existed at the time: https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html and https://blogs.gentoo.org/mgorny/2019/07/04/sks-poisoning-keys-openpgp-org-hagrid-and-other-non-solutions/ --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).