Stable identity
A VLAD remains stable while its keys and protected metadata rotate.
Creation to recovery
BetterSign treats key creation, rotation, revocation, and recovery as first-class signed lifecycle events that peers can discover, verify, and apply without changing the stable identity.
A VLAD remains stable while its keys and protected metadata rotate.
Every state transition is hash-linked and authorized by the previous log state.
VLADemlia helps peers locate current records without becoming the trust root.
Key changes become signed updates that followers can verify and apply.
Creation to recovery
A complete key-management system needs creation, rotation, revocation, and recovery. BetterSign models all four as provenance-log state transitions rather than one-off file distribution events.
Lifecycle events are first-class citizens in BetterSign. They are not side-channel notifications, support tickets, or emergency ceremonies; they are signed entries in the same verifiable history that defines current identity state.
The identity remains the VLAD. Keys are current state under the VLAD plog, so a follower can verify lifecycle history and derive the present trusted key set.
Key creation generates initial cryptographic material, assigns intended operations, and publishes the resulting public state to the BetterSign network.
BetterSign does not require every deployment to store secrets the same way. The generated public keys and policy become verifiable plog state; the private-key storage strategy remains an operator choice.
Private keys remain under the chosen local custody model.
Rotation invalidates old key material and replaces it with new material while preserving the identity. It can be triggered by expiration, compromise suspicion, cryptographic agility, or a change in policy.
A normal rotation is authorized by the current accepted key or policy. Followers do not need a manual out-of-band key file; they verify the plog update and derive the new current state.
Key changes should be expected. BetterSign makes rotation a routine state transition so operators can shorten key lifetimes, adopt stronger algorithms, and recover from exposure without treating every change as an outage.
BetterSign can let a peer jump to the latest advertised head while still validating the intermediate chain, so long histories remain practical without sacrificing lifecycle authentication.
See rotation and propagation in action — one signed entry, and every follower verifies and switches on its own.
Revocation invalidates a key without immediately designating a replacement. It uses the same publication and verification path as rotation, but the resulting state marks the key as no longer usable.
Followers that watch relevant plog paths can react by removing SSH keys, refusing a signing authority, updating service registries, or forcing local policy to reject the revoked material.
Recovery is the highest-risk lifecycle operation because it restores authority after loss or compromise. BetterSign handles recovery through explicit higher-priority authority rather than asking a third party to reset the identity.
A common model is P0/P1 authority. A P1 primary key handles day-to-day updates. A more protected P0 recovery key can override or replace the P1 key when compromise or loss occurs.
This maps directly to the standard recovery-before-primary lock behavior: a valid recovery proof can authorize recovery-grade updates before the normal primary proof is considered.
BetterSign does not require one custody model for all deployments. Operators can choose key storage that matches their threat model while publishing verifiable public state through the plog.
Suitable custody models include threshold protocols, TEEs, HSMs, OS keyrings, enclaves, and other controlled storage systems. The important boundary is that only authorized parties can use private material to decrypt or sign.
BetterSign publishes and verifies public lifecycle state; private custody remains deployment-specific.