amduat-api/notes/Offline Root Trust Specification.md

Below is a clear, minimal, and opinionated specification for how many offline roots to trust, designed to preserve determinism, avoid governance creep, and still give you real-world safety.

This is not “enterprise PKI”. It is constitutional law for domains.

---

Offline Root Trust Specification

---

1. Design Goal

The offline root system must:

• Be auditable
• Be offline
• Be stable across decades
• Avoid quorum games, liveness assumptions, or time-based logic
• Preserve deterministic replay

Therefore:

Offline roots define legitimacy, not availability.

---

2. Fundamental Rule (Normative)

A domain MUST trust a fixed, small set of offline root public keys.

This set is explicit, finite, and snapshot-pinned.

---

3. Recommended Number of Offline Roots

✅ Exactly 1–3 offline roots

Count	When to use
1 root	Personal domain, research system, prototype
2 roots	Organization with separation-of-duties
3 roots	High-value or long-lived domain

❌ More than 3 is strongly discouraged.

---

4. Why Not More?

Because offline roots are not about redundancy — they are about legitimacy.

Problems with many roots:

• Ambiguous authority
• Governance disputes
• Non-deterministic interpretation
• Social quorum bugs (“who signed this?”)
• Long-term rot

Your system values historical truth, not organizational politics.

---

5. Root Trust Model

5.1 Root Set Definition

OfflineRootSet {
    version       : u32
    root_keys[]   : PublicKey   // sorted, unique
    threshold     : u8
}

This object itself is:

• Canonical
• Snapshot-pinned
• Hardcoded into verifier configs
• Rarely changed

---

6. Threshold Rules (Critical)

6.1 Threshold = 1 (Default)

Exactly one root signature is sufficient.

This is the recommended default.

Why:

• Deterministic
• Simple
• No coordination needed
• No partial legitimacy

This matches your “constitutional” model.

---

6.2 Threshold > 1 (Optional, Advanced)

If you must:

Roots	Threshold
2	2-of-2
3	2-of-3

Rules:

• Threshold MUST be static
• Threshold MUST be declared
• Partial signatures are meaningless
• Verification must be order-independent

⚠️ Avoid 1-of-3 — it defeats the point.

---

7. What Roots Are Allowed to Sign

Offline roots may sign only:

• AuthorityCertificate artifacts
• Root rotation statements (rare)
• Policy ratification certificates (optional)

They must never sign:

• Artifacts
• PERs
• Snapshots
• TGK edges
• Execution data

This keeps authority narrow and legible.

---

8. Root Rotation (Rare, Heavyweight)

Root rotation is constitutional change.

Rules:

1. New root set defined
2. Old root(s) sign rotation artifact
3. Rotation artifact imported
4. New snapshots reference new root set
5. Old snapshots remain valid forever

Rotation frequency: measured in years, not days.

---

9. Validation Algorithm (Deterministic)

To validate authority:

1. Load snapshot

2. Resolve DAM

3. Resolve AuthorityCertificates

4. Verify certificate signature(s)

5. Check:

   • signer ∈ OfflineRootSet
   • threshold satisfied

6. Accept or reject

No time. No online checks. No ambiguity.

---

10. Federation Implications

A domain MAY trust:

• Its own offline roots
• Explicitly configured foreign roots

Federation is opt-in trust, never transitive.

---

11. Failure Modes (Explicit)

Situation	Result
Root key lost	Domain frozen (history intact)
Root compromised	Publish new root set + DAM
Disagreement between roots	No new authority issued
Conflicting certificates	Reject both

This is intentional. Ambiguity is worse than halt.

---

12. Minimal Example

offline_roots:
  version: 1
  threshold: 1
  root_keys:
    - ed25519:aa93...

or

offline_roots:
  version: 1
  threshold: 2
  root_keys:
    - ed25519:aa93...
    - ed25519:b4c1...
    - ed25519:c019...

---

13. Why This Fits Your System

✔ Snapshot-safe ✔ Replayable ✔ Offline-friendly ✔ Human-auditable ✔ Minimal governance ✔ No temporal logic

Most importantly:

Legitimacy is a historical fact, not a service.

---

14. One-Sentence Takeaway

Trust as few offline roots as possible — because roots define history, not availability, and ambiguity at the root level destroys determinism.

If you want next, we can:

• Specify root rotation artifacts
• Model emergency recovery
• Define foreign-domain trust pinning
• Walk through a zero-to-first-snapshot bootstrap

Just say the word.