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

```text
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

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

or

```yaml
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.