257 lines
4.9 KiB
Markdown
257 lines
4.9 KiB
Markdown
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.
|
||
|