poztter.org
philosophy · essay 05
Cryptography, with revocation.
For decades, cryptography has kept the internet relatively safe. Complex algorithms and a community of professional distrust have formed the backbone of the internet and finance. POZ builds on that foundation — and adds one important assumption: every key will eventually be broken.
signing is enough, if you do it right
The POZ philosophy is that cryptography — and specifically cryptographic signing — when applied right, can form the backbone of identity sharing and record retrieval. Not encryption. Not consensus. Just signatures, chained the right way.
This is a much smaller claim than it might sound. POZ doesn't invent any new cryptography. It uses Ed25519 for signatures, SHA-3 for hashes, Curve25519 / ChaCha20-Poly1305 for the network. All mature, all standard, all well-understood. What's new is what POZ does with these primitives.
every key is breakable
A cryptographic key can protect and control great power. The POZ philosophy is that every key must be considered breakable and eventually broken. Not because today's algorithms are weak — they're not — but because keys leak, devices get stolen, backups get exfiltrated, and time keeps moving. No part of the chain can be considered usable if the standard cannot allow for every private key to eventually become public knowledge.
This is a design constraint, not a worry. Once you accept it, a lot of consequences follow naturally.
distributing power across keys
If any single key will eventually be broken, never let any single key carry the whole record. POZ encourages distributing authority across many keys. Multiple master keys with a threshold rule. Multiple delegation keys per sub-zone. Frequent key rotation.
As multiple keys are kept safe and frequently rotated, the rare compromised single key loses almost all of its usefulness. The attacker holds something that, by itself, can't do anything.
atomic replacement
Compare to current website PKI. Website keys are time-bound — certificates expire in a timeframe the issuer guessed the key would stay safe through. For keys compromised before they expire, revocation requires the end user to reach a centralized service the user didn't choose. CRLs, OCSP, certificate transparency — each is a layer added because the previous one was insufficient.
POZ takes the philosophy one step further. Keys are immediately invalid once they are replaced. Never can two keys be valid for the same role. The chain of serialization and hierarchical authorities enforces this directly. When a key is replaced in the record, the old one is dead — not "expires in 90 days," not "revoked pending acknowledgment." Dead.
algorithmic revocation
Since the validity of a key is part of the algorithm — encoded in the chain itself — revocation can be performed algorithmically instead of authoritatively. Any demonstration of the use of a compromised key is sufficient evidence to revoke it.
While only a higher authority may replace a key, this property means users may submit evidence of a compromised key and the server can immediately act on it. No central revocation service to consult. No window during which the leaked key still works. The use of the key is the proof of its compromise. The chain handles the rest.
POZ believes security is everyone's responsibility. The protocol lets users participate in keeping the network safe, instead of asking them to defer to a small set of certificate authorities whose only job is to be trusted.
asymmetric authority — locking down vs opening up
One specific consequence of these principles is worth calling out because it shapes how POZ records are configured day-to-day.
The cost of an incorrect grant — adding an identity or credential that shouldn't exist — is high: an attacker has gained a foothold. The cost of an incorrect deny — revoking something that should still be valid — is much lower: a legitimate operation is delayed. Symmetric systems treat both as the same operation. POZ doesn't.
Each delegation key in POZ carries two values: a grant value and
a deny value. They're evaluated independently. A common pattern:
two devices, each with grant=50, deny=100. Either
device alone can revoke a compromised credential — fast incident
response, no quorum required. Both devices must agree to add a
new one — deliberate authorization. Locking down is
unilateral; opening up is consensual.
The protocol doesn't enforce this asymmetry, but it makes it easy. Most users should configure deny ≥ grant on their delegation keys, unless they have a specific reason not to.
the broader rule
The grant/deny split is one example of a broader principle: when two operations have meaningfully different stakes, the protocol should give them different controls. Symmetric where the operations are symmetric. Asymmetric where they aren't. Discipline that, applied consistently across a specification, makes the resulting system easier to reason about — and harder to misuse.