Creation to recovery

BetterSign™

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.

Stable identity

A VLAD remains stable while its keys and protected metadata rotate.

Self-verifying history

Every state transition is hash-linked and authorized by the previous log state.

Decentralized discovery

VLADemlia helps peers locate current records without becoming the trust root.

Routine rotation

Key changes become signed updates that followers can verify and apply.

Creation to recovery

Key Lifecycle

Four Required Operations

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.

Lifecycle Loop

Create key material and initial policy
Publish verifiable plog state
Rotate keys when policy or risk changes
Revoke keys when use should stop
Recover authority through higher-priority controls

Creation

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.

Creation Outputs

Private keys remain under the chosen local custody model.

VLAD
stable identity address
/keys/primary
ordinary operational signing authority
/keys/recovery
higher-priority recovery and administrative authority
/keys/encrypt
public encryption or KEM material for sealed messages
policy
lock scripts and proofs required for future updates

Rotation

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.

Rotation Verification

Discover latest plog head
Fetch missing entries by CID
Verify prev links and skip links
Run lock/unlock authorization
Accept replacement key only after proof succeeds

Revocation

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.

Revocation Reaction

Owner publishes authorized revocation entry
Followers verify plog update
Derived state removes or marks the key
Local integrations stop accepting the revoked material

Recovery

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.

Priority-Based Recovery

Proposed update arrives
Verifier checks higher-priority recovery proof
If recovery proof is valid, accept recovery-grade update
Otherwise evaluate ordinary primary authority
P0 recovery wins contested updatesP1 primary handles normal operations

Storage and Access

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.

Storage Options

BetterSign publishes and verifies public lifecycle state; private custody remains deployment-specific.

Threshold keys
split authority across shares for signing, decryption, or recovery
TEE or enclave
restrict key use inside hardware-backed execution contexts
HSM
centralized hardware-backed custody for high-value keys
OS keyring
practical local storage for desktop and server workflows
MPC
selected multi-party workflows where key material should not reassemble in one place