273 lines
5.4 KiB
Markdown
273 lines
5.4 KiB
Markdown
Great, this fits *cleanly* into what you already have.
|
||
The key is to **treat certificates as artifacts**, not as an external PKI bolted on the side.
|
||
|
||
Below is a **minimal offline certificate system** that integrates with:
|
||
|
||
* Domain Authority Manifest (DAM)
|
||
* Policy hash
|
||
* PER signatures
|
||
* Federation
|
||
* Offline signing machine (e.g. Debian laptop kept off-network)
|
||
|
||
No X.509 complexity, no live revocation, no TLS assumptions.
|
||
|
||
---
|
||
|
||
# Offline Certificate System (OCS) for ASL Domains
|
||
|
||
---
|
||
|
||
## 1. Purpose
|
||
|
||
The **Offline Certificate System (OCS)** exists to:
|
||
|
||
* Anchor **domain authority** in an offline root
|
||
* Certify **domain keys and principals**
|
||
* Allow **air-gapped signing**
|
||
* Preserve **determinism and replayability**
|
||
|
||
It answers:
|
||
|
||
> *“Why should I believe this Domain Authority Manifest?”*
|
||
|
||
---
|
||
|
||
## 2. Core Principle (Very Important)
|
||
|
||
> **Certificates are immutable ASL artifacts, not live credentials.**
|
||
|
||
They are:
|
||
|
||
* Signed once
|
||
* Snapshot-pinned
|
||
* Replayable forever
|
||
* Never “checked online”
|
||
|
||
---
|
||
|
||
## 3. Roles in the Offline Certificate System
|
||
|
||
### 3.1 Offline Root Authority (ORA)
|
||
|
||
* A machine kept **offline** (Debian laptop, USB-only)
|
||
* Holds **root private key**
|
||
* Never participates in execution
|
||
* Never runs ASL/PEL
|
||
* Only signs *authority artifacts*
|
||
|
||
Think: constitutional court, not admin.
|
||
|
||
---
|
||
|
||
### 3.2 Online Domain Nodes
|
||
|
||
* Run ASL / PEL / TGK
|
||
* Hold *domain operational keys*
|
||
* Cannot mint new authority without ORA signature
|
||
|
||
---
|
||
|
||
## 4. Key Types (Minimal)
|
||
|
||
| Key Type | Purpose |
|
||
| ------------------ | ----------------------------------- |
|
||
| Root Authority Key | Signs domain authority certificates |
|
||
| Domain Root Key | Anchors DAM |
|
||
| Principal Keys | Execute / publish / federate |
|
||
| Execution Keys | Optional subkeys for CI, rescue |
|
||
|
||
All are just keypairs.
|
||
No hierarchy beyond signatures.
|
||
|
||
---
|
||
|
||
## 5. Authority Certificate Artifact
|
||
|
||
This is the *only* certificate type you need.
|
||
|
||
### 5.1 Logical Structure
|
||
|
||
```text
|
||
AuthorityCertificate {
|
||
subject_type : enum { domain_root, principal }
|
||
subject_id : Hash
|
||
subject_pubkey : PublicKey
|
||
domain_id : DomainID
|
||
roles[] : Role
|
||
policy_hash : Hash
|
||
issued_by : PublicKey // root authority
|
||
version : u32
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
### 5.2 What It Certifies
|
||
|
||
Depending on `subject_type`:
|
||
|
||
* **domain_root**:
|
||
|
||
* “This public key is authorized to define DAMs for domain D”
|
||
* **principal**:
|
||
|
||
* “This key may act with roles R under policy P”
|
||
|
||
No expiration.
|
||
Revocation is *by replacement*.
|
||
|
||
---
|
||
|
||
## 6. Offline Signing Workflow (Debian Machine)
|
||
|
||
### Step 1: Prepare request (online)
|
||
|
||
On a domain node:
|
||
|
||
```text
|
||
AuthorityRequest {
|
||
subject_pubkey
|
||
domain_id
|
||
requested_roles[]
|
||
policy_hash
|
||
}
|
||
```
|
||
|
||
Export as file / USB.
|
||
|
||
---
|
||
|
||
### Step 2: Offline signing (Debian ORA)
|
||
|
||
On the offline machine:
|
||
|
||
1. Verify intent manually
|
||
2. Construct AuthorityCertificate
|
||
3. Canonical-serialize
|
||
4. Sign with root private key
|
||
5. Output certificate artifact
|
||
|
||
No network. No ASL required.
|
||
|
||
---
|
||
|
||
### Step 3: Import certificate (online)
|
||
|
||
* Certificate is imported as an ASL artifact
|
||
* Snapshot-pinned
|
||
* Referenced by DAM
|
||
|
||
At this point, authority exists.
|
||
|
||
---
|
||
|
||
## 7. Relationship to Domain Authority Manifest (DAM)
|
||
|
||
The DAM does **not** stand alone.
|
||
|
||
A DAM is valid **iff**:
|
||
|
||
1. DAM.root_key is certified by a `domain_root` certificate
|
||
2. Certificate.policy_hash matches DAM.policy_hash
|
||
3. Certificate is visible in snapshot
|
||
4. Certificate signature validates against offline root key
|
||
|
||
DAMs are *governed*, not self-asserted.
|
||
|
||
---
|
||
|
||
## 8. Validation Chain (Offline-Friendly)
|
||
|
||
To trust an action:
|
||
|
||
```
|
||
PER → PERSignature → Principal Key
|
||
→ DAM → AuthorityCertificate
|
||
→ Offline Root Public Key
|
||
```
|
||
|
||
No CRLs.
|
||
No OCSP.
|
||
No clocks.
|
||
|
||
Just hashes and signatures.
|
||
|
||
---
|
||
|
||
## 9. Revocation Model (Deterministic)
|
||
|
||
There is **no live revocation**.
|
||
|
||
Instead:
|
||
|
||
* Publish a **new DAM**
|
||
* Omit revoked principals
|
||
* Reference a **new authority certificate**
|
||
* New snapshots enforce new authority
|
||
* Old snapshots remain valid
|
||
|
||
This preserves determinism.
|
||
|
||
---
|
||
|
||
## 10. Federation Verification
|
||
|
||
When receiving state from another domain:
|
||
|
||
1. Load snapshot
|
||
2. Load DAM
|
||
3. Load AuthorityCertificate artifacts
|
||
4. Verify against *known offline root pubkeys*
|
||
5. Verify policy hash
|
||
6. Accept or reject
|
||
|
||
Federation trusts *roots*, not nodes.
|
||
|
||
---
|
||
|
||
## 11. Why This Beats X.509 for Your System
|
||
|
||
| Problem | This System |
|
||
| ---------------------- | ----------- |
|
||
| Online dependency | None |
|
||
| Mutable trust | None |
|
||
| Time-based expiry | None |
|
||
| Replay safety | Guaranteed |
|
||
| Snapshot compatibility | Native |
|
||
| Forensics | Perfect |
|
||
|
||
---
|
||
|
||
## 12. Minimal Files on Offline Debian Machine
|
||
|
||
```
|
||
/ora/
|
||
├── root.key
|
||
├── root.pub
|
||
├── policies/
|
||
├── issued/
|
||
│ └── authority-cert-*.bin
|
||
└── requests/
|
||
```
|
||
|
||
That’s it.
|
||
|
||
---
|
||
|
||
## 13. One-Sentence Summary
|
||
|
||
> **Offline authority certificates make domain trust explicit, immutable, and replayable — turning cryptographic signatures into constitutional facts rather than live permissions.**
|
||
|
||
---
|
||
|
||
If you want next, we can:
|
||
|
||
* Define **canonical byte layout for AuthorityCertificate**
|
||
* Specify **how many root keys a domain may trust**
|
||
* Walk through **full bootstrap from zero**
|
||
* Model **rescue-node temporary authority**
|
||
* Tie certificates into **ZFS snapshot metadata**
|
||
|
||
Just say where to continue.
|
||
|