13 — Keys and signatures
Summary
Which things in this design get keypairs, and why the answer is fewer than proposed. Two principles adopted: a secret is defined by expectation, not by content (which explains the estate's existing key rules in one line, and needs the intention recorded at issue, because a deliberate publication and a leak are indistinguishable afterwards); and a signature's value comes entirely from the scarcity of the private half. One proposal declined — per-object keypairs with the private half published — because it leaves a hash wearing a signature's clothes, defeats its own stated use, and would make C3's fixture flag true on every row. A flag that is always true is a column, not evidence, so declining the proposal is what preserves C3 rather than conservatism.
Key concepts
- A secret is defined by expectation — C18: sort by intention rather than by class, and record it at issue
- Scarcity is what a signature is made of — publish the private half and a verifier succeeds and concludes something false
- Artefacts get signed, principals get keys — confirmed twice, by two independent routes
- Sign by default, and publish what anybody checks — a fully signed graph nobody verifies manufactures the appearance of assurance
Key ideas
- Destroying a vault makes its key safe to publish from your server's point of view, and says nothing about the content — custody without access means mirrors exist that nobody can enumerate.
- The one genuine benefit of a per-object key is an address, and the lane derivation is proposed rather than shipped.
- Route to the issuer's lane tagged with the object's identifier: one lane per party, not one per document.
- Whether a rented instance can hold a private half across sessions is open, and it decides whether instances can hold identities at all.