Define lockbox signer trust, authorship, and multi-author authorization

Context

The lockbox format embeds owner public signing keys and signatures alongside the
commit-auth record. This is enough to test whether the commit was signed by the
corresponding private key, but an embedded key does not establish who controls
that key or whether that person was allowed to modify the lockbox.

If an attacker can replace an archive and the only trust material is inside that
same archive, the attacker can insert a new key, rewrite the content, and sign
the replacement. Verification will report a mathematically valid signature but
cannot honestly report "Alice authored this". Trust must come from outside the
artifact.

Related: #211 covers the original signature-validation question, #226 designs
reciprocal exchange of signing keys, and #227 defines signed/unsigned
plaintext/encrypted artifacts.

What an embedded public key is useful for

An embedded signing key is not worthless. Before identity trust exists it can:

• prove possession of the private key corresponding to that commit;
• provide a stable fingerprint for independent verification or TOFU pinning;
• bind a complete commit and its history against undetected modification after
  the key has been pinned externally;
• allow a later trust decision to be applied to an already received artifact;
• identify unexpected signer changes relative to locally stored state.

It must initially be labelled valid but untrusted, not "authentic" or
"authored by Alice".

Required assurance layers

Treat these as independent results:

1. Integrity: the committed root matches the archive state.
2. Signature validity: the signature verifies under the stated public key.
3. Identity trust: the public key is bound to a contact through an
   independently trusted process.
4. Author authorization: that trusted contact/key was permitted to create
   this commit under the lockbox author policy at that point in history.
5. Freshness: the artifact is not an older, otherwise valid version.

A failure or unknown result at one layer must not be hidden by success at
another.

Multiple authors and authority

Reading/decrypting a lockbox must not automatically grant signing authority.
When multiple people may modify a lockbox, the format needs an explicit author
policy rather than one self-declared owner key.

The model should distinguish:

• recipients/readers who can decrypt content;
• authorized authors who can sign new commits;
• administrators/owners who can add, remove, rotate, or recover author keys;
• the signer of each historical commit;
• the current authorized-author list;
• the observed list of authors in retained history.

Author-policy changes must themselves be authorized and committed. Removing an
author must prevent that author from signing later commits without erasing the
fact that earlier commits were validly authored while the key was authorized.
The design must define quorum/threshold requirements for author-policy changes,
key recovery, and owner loss rather than assuming that any current writer can
silently replace the whole policy.

Trust establishment

The trusted binding belongs in the local vault/contact store, not in claims made
by the lockbox. A received signing key should start as pending/untrusted and
become trusted only after fingerprint verification through an independent
channel or another explicit policy source.

#226 proposes exchanging encryption and signing keys atomically while keeping
the trust decisions local and independent. Key transport, email control, a
profile name, and a self-signature are evidence, but none alone proves human
identity.

Key rotation should be accepted automatically only when the new key is signed
by a currently trusted key under the rotation policy. Lost-key recovery needs a
separate, explicit verification path and must not inherit trust silently.

User trust policies

Provide an explicit policy for opening and operating on archives:

permissive  accept signed or unsigned archives; report all assurance results
warn        continue, but prominently warn for absent, invalid, untrusted, or
            unauthorized signatures
strict      reject unsigned archives and commits that are invalid, untrusted,
            or unauthorized

Invalid signatures should normally be treated more severely than absent
signatures because an invalid signature indicates corruption, tampering, an
incomplete write, or a broken implementation. Commands that mutate, extract,
execute, or consume secrets may need stricter defaults than read-only inspect.

The CLI/API should show a concise author list with fingerprint, contact binding,
trust state, authorization interval, commits signed, rotation/revocation state,
and how the trust decision was established.

Format and state questions

• Define a stable signer/key ID derived from canonical algorithm and public-key
  bytes; do not use a display name as identity.
• Bind the full author policy, signer key ID, commit sequence, previous commit,
  archive mode, and logical root into the signed message.
• Decide whether every commit has one author signature, multiple co-signatures,
  or policy-dependent thresholds.
• Decide what author metadata is public and what remains encrypted; public
  signer data improves pre-decryption verification but leaks relationships and
  identity metadata.
• Define the external local trust record and its binding to contact generation,
  signing-key rotation, and archive UUID/policy.
• Define whether TOFU is supported, how it is presented, and how a changed key
  is handled without training users to approve substitutions.
• Define an external freshness anchor or explicitly report freshness as unknown
  for standalone files.
• Ensure whole-file replacement, signature stripping, author-policy rollback,
  and cross-lockbox signature reuse cannot be mistaken for authorized history.

Threats and failure cases

• Embedded-key substitution and complete archive replacement.
• A valid signature from an unknown or malicious key.
• A trusted contact key that was never authorized for this lockbox.
• A reader/content-key holder attempting to become an author.
• Compromise, loss, rotation, expiry, or revocation of an author key.
• A removed author signing a later fork or replaying an older author policy.
• Signature stripping or signed-to-unsigned downgrade.
• Rollback to an older fully valid archive.
• Cross-archive, cross-profile, or cross-generation signature replay.
• Misleading names/emails inside an archive.
• Partial multi-signature commits and disagreement about threshold policy.
• Trust-store loss, restore, merge conflicts, and inconsistent trust decisions
  across a user's devices.

Existing planning notes

• rust/revault_lockbox_api/ARCHIVE_FORMAT.md defines the current embedded
  Ed25519 and ML-DSA-65 owner keys/signatures, commit chain, and external
  freshness limitation.
• rust/revault_lockbox_api/README.md describes owner signing as write authority
  and currently requires both signature algorithms.
• rust/revault_lockbox_api/IMPLEMENTATION_GUIDE.md documents the current
  commit-auth write sequence.
• docs/format_versioning_and_migrations.md and docs/migration_guide.md
  document that migration creates a new commit/signature history.
• rust/revault_key_server/CLI_VAULT_PUBLISH_DESIGN.md already distinguishes
  signed key rotation from unsigned recovery and only auto-accepts rotation
  under the previously verified signing key.
• #211 and #226 contain the key-exchange and independent-fingerprint trust
  planning that should feed archive verification.

Plan

1. Write the signer/authorship threat model and normative assurance vocabulary.
2. Define the vault contact trust record, fingerprint, verification evidence,
   trust transitions, and persistence/backup behavior.
3. Define the versioned lockbox author policy, roles, authorization intervals,
   policy-change authority, and threshold/quorum rules.
4. Define canonical signed fields and domain separation for commits, policy
   changes, rotation, recovery, and archive modes.
5. Define author history, removal, revocation, rotation, and recovery semantics.
6. Define permissive/warn/strict policy behavior for inspect, open, extract,
   execute, copy, share, and mutate operations.
7. Specify CLI/API verification reports and author-list UX without overstating
   unknown identity or freshness.
8. Connect #226 contact trust records to lockbox signer matching and author
   authorization checks.
9. Decide whether format changes and migration/export tooling are required.
10. Add adversarial tests for substitution, stripping, downgrade, replay,
    rollback, unauthorized writers, removed authors, rotation, recovery, and
    threshold failures.
11. Update the archive format, security model, key exchange, user guide, and
    troubleshooting documentation.
12. Complete an independent security review before trusted-authorship claims
    are enabled by default.

Acceptance criteria

• Verification reports integrity, signature validity, identity trust, author
  authorization, and freshness independently.
• An embedded or self-signed key is never treated as trusted by itself.
• Users can inspect current authorized authors and historical commit signers.
• Decryption/read access does not imply signing/write authority.
• Author additions, removals, rotations, recovery, and historical validity have
  documented and tested semantics.
• Reciprocal exchange supplies candidate signer keys, while an independent local
  decision establishes trust.
• Permissive, warn, and strict modes behave consistently across CLI and API
  operations.
• Signature stripping, key substitution, unauthorized signing, policy rollback,
  and cross-context replay are detected.
• Standalone rollback limitations are clearly reported unless an external
  freshness anchor is available.
• Documentation never says "authored by X" unless the signature is valid, X's
  key is trusted, and X was authorized for that commit.

Start with rust/revault_lockbox_api/ARCHIVE_FORMAT.md, README.md, and IMPLEMENTATION_GUIDE.md, then review issues #211 and #226 for existing signing and trust assumptions. This is a broad security-design effort: completion requires documented assurance layers, author-policy and trust semantics, CLI/API behavior, adversarial tests, and updates to the listed format and user documentation.