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) |
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.