This is the right moment to pin this down.
What follows is a **complete, staged, minimal certificate story** that fits *exactly* with what you’ve built so far — no PKI bloat, no premature abstraction, and no magical trust.

I’ll walk it in **time order**, because *when* certificates exist matters more than *what* they are.

---

# Certificate Lifecycle in ASL (Walkthrough)

## 0. First principle (anchor this)

> **Certificates do not create authority.
> They record it.**

Authority already exists because:

* someone controls a machine
* someone controls a domain
* someone makes a decision

Certificates make that **legible and replayable**.

---

## 1. Phase 0 — Before Any Certificates Exist (Virgin State)

This is where your system starts.

### What exists

* ASL-HOST
* ASL-STORE
* Domains
* Logs
* Snapshots
* Artifacts
* PERs

### What does NOT exist

* No CA
* No identities
* No signatures
* No trust

Everything works anyway.

Artifacts are still immutable.
Receipts still exist.
Snapshots still reconstruct CURRENT.

This is important: **certificates are optional metadata**, not a dependency.

---

## 2. Phase 1 — Birth of an Authority (Offline Auth Host)

At some point, you decide:

> “This domain should be able to make statements that others may trust.”

This happens on the **offline auth host**.

---

### 2.1 Create the Root Authority (once)

This produces the **Root Authority Certificate**.

#### Root CA (ASL-ROOT)

* Self-signed
* Offline forever
* Never rotates casually
* Stored only on auth host

Conceptually:

```
ASL-ROOT
  public_key
  policy: may sign domain authorities
```

This is **not** a TLS CA.
It is a *semantic authority*.

---

### Where it is stored

* On disk (auth host):

  ```
  /var/lib/asl/auth/root/
    root.key   (private, offline)
    root.crt   (artifact)
  ```
* As an ASL artifact:

  ```
  artifact: root.crt
  domain: auth-host
  ```

The **private key is never an artifact**.

---

## 3. Phase 2 — Domain Authority Certificates

Now the root creates **Domain Authorities**.

This is the most important certificate type.

---

### 3.1 Domain Authority (DA)

A **Domain Authority Certificate** binds:

```
(domain_id) → public_key → policy
```

Example:

```
alice.personal
```

Gets a DA certificate:

```
DA(alice.personal)
  signed_by: ASL-ROOT
  key: alice-domain-key
  policy:
    - may seal snapshots
    - may publish artifacts
```

---

### Where DA certs live

* Stored as artifacts
* Stored **inside the domain they govern**
* Also optionally copied to Common

Example:

```
/var/lib/asl/domains/alice.personal/auth/domain.crt
```

This makes replay self-contained.

---

## 4. Phase 3 — Operational Keys (Actors)

Now we separate **authority** from **action**.

---

### 4.1 Operator / Host Certificates

These are **delegation certs**.

They answer:

> “Which machine / user is allowed to act for this domain?”

Examples:

* Rescue image
* Laptop
* CI node
* VM

They are **short-lived** and **revocable**.

```
OperatorCert
  subject: host-id
  acts-for: domain_id
  signed_by: domain authority
  scope:
    - may write artifacts
    - may append log
```

---

### Storage

* Stored in domain auth area
* Referenced by PERs

```
/var/lib/asl/domains/alice.personal/auth/operators/
```

---

## 5. Phase 4 — Signing Receipts and Snapshots

Now certificates begin to **matter operationally**.

---

### 5.1 What gets signed

1. **Snapshot seals**
2. **PERs (execution receipts)**
3. **Policy artifacts**

Never raw data blocks.

---

### 5.2 PER Signature Model

A PER includes:

```
PER:
  inputs
  program
  outputs
  snapshot_range
  signer:
    operator_cert_id
  signature
```

This allows later verification:

* Who ran this?
* Under which authority?
* Against which snapshot?

---

## 6. Phase 5 — Federation and Trust

Now certificates cross domains.

---

### 6.1 Trust is explicit

A domain never trusts another domain implicitly.

Instead it stores a **Trust Artifact**:

```
"I trust domain X snapshots ≥ S
 signed by DA(X)
 under policy P"
```

This artifact can be:

* private
* group-shared
* published to Common

---

### 6.2 Common’s role

Common may store:

* Root cert(s)
* Domain Authority certs
* Trust policies

But Common **does not enforce trust**.

It only witnesses it.

---

## 7. Certificate Types (Complete List)

Here is the full minimal set:

### 1. Root Authority Certificate

* Signs domain authorities
* Offline
* Rare

### 2. Domain Authority Certificate

* One per domain
* Signs snapshots, operators
* Long-lived

### 3. Operator / Host Certificate

* Acts-for a domain
* Short-lived
* Used in PERs

### 4. Trust Policy Artifact (not a cert, but signed)

* “I trust X for Y”
* Domain-local meaning

That’s it.

No user certs.
No TLS certs.
No global CA hierarchy.

---

## 8. What Happens During Rescue (Concrete)

Let’s ground this.

### Rescue day

* Rescue domain exists
* No certs yet
* Everything works

### Later, you decide it matters

1. Create personal domain authority
2. Sign rescue snapshots retroactively
3. Publish selected artifacts

History remains valid — it just gains **witnesses**.

---

## 9. Why This Is Robust

* No cert = still works
* Lost cert = data still exists
* Revoked cert = history still readable
* Multiple roots = allowed

This avoids:

* “all-or-nothing PKI”
* bricked data
* forced trust

---

## 10. One sentence to remember

> **Certificates don’t make things true.
> They make them accountable.**

---

If you want next, I can:

* Specify exact cert encoding (X.509-like vs custom)
* Show how certs are imported via USB
* Define revocation without CRLs
* Show how auth-host stays simple

You’re converging on a very clean trust model.