The four rules, published before the registry exists
Publishing the design before the implementation is cheap to do in this order and impossible to claim afterwards. These are the registry's stated rules, each derived directly from the documented failure, each checkable against whatever eventually ships. If something ships that breaks one of them, this page is the evidence.
The rules
Only the owner writes to their own record
The keyserver attack existed because anyone could append to anybody's certificate. The property that separates safe append-only channels from the fatal ones is ownership of the written object — so it is the registry's first rule, not a policy bolted on later.
Turns around: anyone may append to anybody's certificateRevocation is a signed append, not a deletion
The single most important operation a registry performs is withdrawing a compromised key — and the keyservers could not delete, by design. The supersede-rather-than-delete rule resolves this: a revocation is an appended statement signed by the key being revoked. The record stays append-only; the revocation is verifiable, because only the key holder could have signed it; what the key said before revocation stays checkable; and a reader always sees current state by reading to the end.
Turns around: a key server can never delete a certificate or information about oneRecords are size-bounded
One poisoned key reached ~150,000 signatures because certificates had no size limit. A bound generous enough to be invisible in normal use and small enough to stop flooding is a stated design parameter — with the honest cost that it will one day reject a legitimate record.
Turns around: a certificate may carry unlimited signaturesEvery entry is signed by something you can check
Nothing in the old network distinguished a legitimate signature from garbage. Every entry in the registry carries a signature that resolves against a key the reader can verify — which is what makes untrusted mirrors safe and the registry's contents portable.
Turns around: nothing distinguishes a legitimate signature from garbageThe registry can be append-only and still support withdrawal, provided only the owner may append.
Rules 1 and 2 are usually assumed to be in tension — you cannot both refuse deletion and support revocation. They are not, and the reason is rule 1: when the only writer is the owner, an appended revocation is as authoritative as a deletion would have been, and strictly more useful, because the history it supersedes stays answerable.
Revocation, as the reader sees it
What a reader does with a record is read it to the end. Current state is the last statement that applies; nothing has to be trusted to have been removed:
sequenceDiagram
participant O as Key owner
participant R as Registry record
participant V as Reader / verifier
O->>R: append: identity statement (signed)
O->>R: append: mandate statement (signed, expires)
Note over R: record is append-only
and owner-writable only
O->>R: append: revocation (signed by the revoked key)
V->>R: read record to the end
R-->>V: identity, mandate, revocation
Note over V: current state = last applicable statement
earlier states stay checkable
Two properties fall out of this that a deletion-based registry cannot offer. The revocation is self-authenticating — only the holder of the revoked key could have signed it, so a mirror cannot forge one and cannot suppress one without the gap being visible. And what a key asserted before its revocation stays checkable, which is what you need when the question is whether a signature made last March was valid at the time.
The deliberate choice: third-party attestations
The replacement keyserver stripped all third-party signatures — which stopped the attack and removed the web of trust with it. That trade must be made deliberately, not inherited:
| Choice | What you get | What it costs |
|---|---|---|
| Permit attestations | A social trust signal: somebody else vouches for this key, and for what its holder may do | The attack surface that ended the last network — so rules 1 and 3 must be enforced hard |
| Forbid attestations | Immunity to the flooding attack, by construction | No trust signal at all; the registry says only "this key exists and claims this" |
For agent identity the question is live rather than academic, because a key alone says nothing about what an agent may do — which is what mandates are for, and a mandate issued by somebody other than the agent is a third-party attestation. This is the site's central open question, and it is published unresolved.
What vaults supply, and what they don't
The reason to attempt this now is not that the idea got better. It is that the layer a key server used to have to build for itself now exists:
| Vaults supply | Registry logic must supply |
|---|---|
| Distribution — a published vault is readable from static hosting and mirrorable by anybody, with no replication protocol of its own | The ownership rule (rule 1) |
| Custody without access — anybody can mirror a vault they cannot read, so untrusted mirrors are safe by construction | The size bound (rule 3) |
| Versioning — history is native, so the state of a key at any past date is answerable without designing an audit log | Signature checking (rule 4) |
A proposed fifth rule: publish the reference
Three of the four rules are about entries. None of them is about the pointer that decides which entries a reader sees — and that turns out to be the one layer where append-only is a policy rather than a mechanism.
| Layer | Property | What follows |
|---|---|---|
| Blobs, trees and commits | Content-addressed and immutable | A commit that existed cannot be altered undetectably |
| The branch reference | Mutable | The history a reader sees is whatever the reference currently points at — and moving it is a shipped command |
The distinction is the familiar one. A revert appends: a new commit undoing an earlier one, both still reachable — which is what rule 2 means. A reset moves the pointer: commits that were reachable stop being. Nothing was mutated, and the history changed anyway.
Append-only history is a policy about one pointer, not a property of the store.
For a registry whose whole proposition is that a reader can reconstruct what was believed at a past date without trusting the party serving it, that is a material gap. Saying "our published branch does not accept a reset" is a promise. The site's own fourth rule asks for better:
The registry publishes its head — signed and dated — on a stated cadence. A reference that moves backwards is observable to anybody who recorded where it used to point. A reader who kept yesterday's head can verify that today's history still contains it, which turns the promise into an assertion somebody else can falsify.
It is the same move as a short-lived certificate recorded in a public log, and the same move a notary that publishes rather than answers makes: publish the thing that makes the claim checkable, rather than asking to be believed. The honest limit is that it protects the attentive and nobody else — it only helps readers who kept a previous head.
Where the growth goes — and why rules 2 and 3 stop competing
Read as rules about one accumulating object, rule 2 (nothing is ever removed) and rule 3 (the record must not grow without limit) are close to contradictory, and rule 3 is the one that would quietly be dropped.
The tension dissolves once the entry is a file inside a commit graph rather than a record that accumulates. The bound applies to the entry file; the growth lives in the history, where growth is already handled. The entry then carries current state and no history array — no list of prior fingerprints, no embedded revocation log. A consumer wanting the current answer fetches one object; a consumer wanting the story clones.
The authorisation model is not a new one
A registry needs to say who may append, who may read, who may configure and who holds the signing key. That model already exists in the platform, implemented and code-verified, as four capability tiers with the server holding only hashes — so a total compromise of the server yields hashes rather than capabilities.
Reusing it beats designing a second one for three reasons: it is implemented rather than argued for, the hash-only property is the catastrophic-failure discipline these rules already invoke, and a second authorisation model in the same platform is a second thing to reason about, get wrong and document. Rule 1 is a constraint on the first of those four tiers.
Fractal stores need declared roots
The structure nests — public and private registries, registries of registries. What nesting requires is that each store declares which trust roots it accepts; without that, the fractal property produces a graph nobody can evaluate. Who may claim to be a root is a privileged decision that needs a stated answer, even a simple one ("set once by the operator").
The private store — one organisation's own agents, mirrored and verifiable — is the smaller trust problem and the clearer buyer, which is why it is the build target before any public registry.