amduat-api/notes/Offline Certificate System (OCS) for ASL Domains

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.