A Secret Is Defined By Expectation And A Signature By Scarcity
Summary
A brief that adopts a proposal's opening principle and its closing pattern and rejects the proposal in between, and says so rather than smoothing the difference. The principle: a secret is defined by expectation rather than by content, which explains read-keys-yes and write-keys-never in one line and sorts key material by intention rather than by class — with the qualification that the intention has to be recorded at issue, since a deliberate publication and a leak are indistinguishable afterwards. The rejection: publishing a private half destroys the integrity it was meant to supply, because a signature's value comes entirely from scarcity, so what is left is a hash wearing a signature's clothes — worse than a hash, because a verifier checks it, succeeds, and concludes something false. And the closing pattern, promoted to the governing rule: an instance generates its own keypair and a project key endorses it, so a key belongs to whatever can keep a secret and everything else is signed by something that can.
Key concepts
- A signature is made of scarcity — publish the private half and verification stops carrying information
- A flag that is always true is a column — publish-by-default would make the fixture flag true on every row
- Custody without access — destroying a vault does not make the ciphertext other people already hold unreadable
- Route to the issuer's lane — the addressing benefit of per-object keys, without the keys
Key ideas
- A key belongs to whatever can keep a secret; everything else is signed by something that can.
- The proposal's own use — sealing to a specific object — requires exactly the scarcity the proposal removes.
- Sign by default, and publish which signatures anybody actually checks.
- A memo has now raised per-object keys twice, which says the first explanation did not stick.
On this site
Became document 13 of the registry MVP pack. It reinforces the fixture flag rather than amending it: the flag survives precisely because per-object published keys are declined.