Plan a trustworthy public key directory

Context

The current key server is a short-lived rendezvous service addressed by opaque
publish codes. We need to evaluate whether it should also operate as a
persistent public key directory, where a user can discover a profile key bundle
using an email address or another stable identifier.

This is a different trust and operational model from an expiring invitation.
Public keys are not secret, but directory membership, lookup activity, profile
relationships, rotation history, and email association can still be sensitive.

Related: #211.

Questions to answer

• Is the directory enumerable, exact-lookup-only, or restricted to verified
  recipients?
• Is email the canonical key or a verified attribute of a stable profile ID?
• Does an entry represent a person, email address, or profile generation?
• How does registration prove control of the email and both private keys?
• How do clients distinguish email control from human identity trust?
• How are update, rotation, revocation, recovery, deletion, and history
  authenticated?
• How do clients detect substitution, rollback, and split-view responses?
• Should persistent directory and short-lived exchange be separate services?

Capacity findings

One current reVault profile contains:

Component	Serialized bytes
X25519 + ML-KEM-768 contact public-key record	1,232
Ed25519 + ML-DSA-65 signing public-key record	2,000
Total raw key material	3,232

For one million active profiles:

3,232 x 1,000,000 = 3,232,000,000 bytes = approximately 3.01 GiB

Practical primary storage for one generation is approximately 3.8-4.8 GB after
metadata, indexes, and database overhead. Retaining both proof signatures makes
the raw entry about 6.6 KB and the practical database about 7-9 GB per million
generations.

Average generations	Practical primary storage
1	4-5 GB
2	8-10 GB
5	20-25 GB

Two live copies plus three backup generations would be approximately 25-45 GB
for one million profiles. Storage is not the main constraint. Post-quantum keys
are high entropy, should be stored in binary, and will not compress materially.
Bandwidth, scraping, transparency, privacy, and lifecycle correctness dominate.

Usage models

1. Opaque invitation only: short-lived and non-enumerable; no persistent
   lookup.
2. Verified-recipient inbox: recipient authenticates an email before seeing
   addressed invitations.
3. Opt-in lookup directory: exact normalized lookup, anti-enumeration
   controls, authenticated lifecycle, and transparency.
4. Fully public directory: mirrorable public dataset with the greatest
   privacy burden and strongest transparency requirements.

Risks

• Email/user enumeration and confirmation that someone uses reVault.
• Scraping and post-quantum bandwidth amplification.
• Correlation of profiles, organizations, rotations, and lookup activity.
• Malicious-server substitution or split-view responses.
• Stale-key, rollback, replay, and suppressed-revocation attacks.
• Unauthorized recovery after email-account compromise.
• Treating verified email control as proof of human identity.
• Key poisoning, profile-name impersonation, and namespace squatting.
• Verification-email, registration, lookup, and rotation denial of service.
• Retention of historical identifiers after deletion requests.
• Backup leakage and incomplete purge across replicas and logs.
• Directory availability becoming necessary for ordinary archive use.
• Compromise of directory signing or transparency roots.
• Privacy and regulatory obligations for persistent email-linked records.

Proposed direction to investigate

• Canonical binary ProfileBundle with one profile generation, encryption key,
  signing key, stable profile ID, generation, timestamps, and proof of
  possession.
• Explicit opt-in; never publish every local profile implicitly.
• Authenticated updates signed by the previous trusted signing key.
• Independently verified recovery when the previous key is unavailable.
• Append-only key-transparency log with signed tree heads.
• Inclusion/consistency proofs plus gossip or independent witnesses.
• Directory validity remains separate from independently verified contact
  trust.
• Consider isolating persistent directory storage from exchange storage.

Plan

1. Choose and document the intended usage model.
2. Write the threat, privacy, retention, and trust-boundary specifications.
3. Specify profile identity, email normalization, uniqueness, and multi-profile
   behavior.
4. Specify registration with email verification and proof of possession.
5. Specify authenticated update, rotation, revocation, recovery, deletion, and
   generation history.
6. Design lookup authorization, exact-match rules, anti-enumeration controls,
   rate limits, and scraping policy.
7. Design transparency logging, signed tree heads, inclusion/consistency proofs,
   and split-view detection.
8. Model storage, indexes, replication, backup, purge, and bandwidth at 1M,
   10M, and 100M entries.
9. Define availability and disaster recovery without making the directory
   necessary to open archives using locally trusted contacts.
10. Prototype canonical entries and transparency logging.
11. Test enumeration, substitution, replay, rollback, equivocation,
    unauthorized update, compromised email, and deletion failure.
12. Complete privacy/legal and independent security review.
13. Document monitoring, incident response, key compromise, and operator
    procedures.

Acceptance criteria

• A written decision selects a usage model and explains why.
• Email verification is never equated with independently verified identity.
• Registration proves possession of both associated private keys.
• Rotation, revocation, recovery, deletion, and retention are explicit.
• Clients can detect stale, substituted, and equivocated responses.
• Enumeration and scraping behavior is intentional, tested, and monitored.
• Capacity estimates include bandwidth, indexes, replicas, backups, and history.
• Directory failure does not prevent use of locally stored trusted contacts.
• Persistent-directory and short-lived-exchange responsibilities are separated.
• Privacy, legal, abuse, operational, and security review is complete before
  production rollout.

Start with related issue #211, then review the proposed usage models, threat questions, plan, and acceptance criteria in this issue. Produce the written decision and supporting specifications for identity, lifecycle, lookup authorization, transparency, capacity, recovery, and privacy; done means all listed acceptance criteria are addressed before implementation.