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

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

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:

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.