Skip to main content

Disaster Recovery

This page records the law for recovering Zen Lock secret material into a new or replacement environment via portable sealed artifacts (the zen-lock sealed-verify / zen-lock sealed-import ceremony). Recovery never weakens custody: the same admission rules apply during a disaster as at any other time.

Import requires a source-authorized importer​

Admitting a portable sealed artifact requires the importer to prove it is an authorized target for that artifact. For the AGE_LOCAL model this proof is the verify-blob identity check: the importing Zen Lock must hold an identity that the artifact's verify blob recognizes, and this step is never skipped. An importer without a matching recipient identity is denied (ErrUnauthorizedTarget) — an unauthorized importer remains denied no matter the circumstances of the recovery.

Provenance, format/integrity, policy, and the generation/rollback law are verified on every import, and import is idempotent: re-admitting an already-admitted artifact generation is a no-op.

Destination recipient does not imply source authorization​

Being a valid recipient at the destination proves nothing about authorization at the source. Holding (or being able to decrypt) a re-wrapped copy at the recovering environment grants no rights over the original, and does not authorize any further export. Authorization always travels with the artifact's own verify/reciprocal proof against an authorized identity — never with physical possession of the ciphertext.

Cross-environment and cross-cluster movement requires recipient-aware rewrap​

Moving material between environments or clusters is a rewrap, not a copy:

  • AGE_LOCAL model: sealed-import --rewrap decrypts the application ciphertext transiently in process memory and immediately re-seals it to the destination environment's recipients. Without --rewrap, the import admits the sealed bundle without decrypting the application secret.
  • ENVELOPE_V2 model: artifact-level rewrap is refused by law. Rewrap goes through the custody authority (RewrapAuthority), which enforces environment, tenant, and custody-generation acceptance windows; import requires the custody-envelope validator.

A destination recipient list is chosen deliberately at rewrap time; it is never inherited from the source artifact.

Ciphertext-only transport remains the default​

Artifacts travel as ciphertext. The default import path verifies and admits without decrypting the application secret at all; the only decryption that ever occurs is the explicit, transient, in-memory window inside a requested rewrap. Plaintext export, plaintext transport, or persistent plaintext staging is out of law for recovery flows.

No weakening for recovery convenience​

Recovery situations do not relax admission law. Flags or code paths that would skip the importer identity proof, bypass the custody authority, admit unknown crypto models, or widen recipients beyond the destination environment's canonical recipients are forbidden — including under an active incident. A recovery that cannot complete lawfully escalates to the custody owner instead of weakening the ceremony.