amduat-api/tier1/asl-ocs-1.md

# ASL/OCS/1 -- Offline Certificate System

Status: Draft
Owner: Architecture
Version: 0.1.0
SoT: No
Last Updated: 2025-01-17
Tags: [certificates, authority, offline]

**Document ID:** `ASL/OCS/1`
**Layer:** L2 -- Certificate semantics (no encoding)

**Depends on (normative):**

* `ASL/OFFLINE-ROOT-TRUST/1`
* `ASL/DAM/1`
* `ASL/POLICY-HASH/1`

**Informative references:**

* `PER/SIGNATURE/1` -- PER signature validation

---

## 0. Conventions

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, and **MAY** are to be interpreted as in RFC 2119.

ASL/OCS/1 defines certificate semantics as immutable artifacts. It does not define encodings.

---

## 1. Purpose

The Offline Certificate System (OCS) anchors domain authority in offline root keys and allows deterministic, offline verification of authority.

---

## 2. Core Principle

Certificates are **immutable ASL artifacts**, not live credentials.

They are:

* Signed once
* Snapshot-pinned
* Replayable
* Verified offline

---

## 3. Authority Certificate Artifact

### 3.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
    version        : u32
}
```

### 3.2 Semantics

* `domain_root`: certifies a domain root key for DAM issuance.
* `principal`: certifies a principal key for roles under a policy hash.
* `roles[]` MUST be empty for `domain_root` certificates.
* `policy_hash` MUST match the DAM policy hash for the domain when used.

---

## 3.3 Authority Request (Normative)

An authority request is a deterministic, offline-signable object:

```text
AuthorityRequest {
    subject_type
    subject_pubkey
    domain_id
    roles[]
    policy_hash
}
```

The offline signer MUST validate the request against the offline root trust rules before issuing a certificate.

---

## 4. Offline Signing Workflow

1. Online domain prepares an AuthorityRequest.
2. Offline root signs an AuthorityCertificate.
3. Certificate artifact is imported and snapshot-pinned.

No online checks are required after import.

---

## 5. Certificate Visibility and Idempotency

* AuthorityCertificate artifacts MUST be visible in the snapshot that uses them.
* Replaying the same snapshot + certificate set MUST yield identical authority results.
* Duplicate certificates for the same subject_id MUST be rejected within a snapshot.

---

## 6. DAM Validation Chain

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 signature validates against the offline root set.

---

## 7. Revocation Model

There is no live revocation. Revocation is performed by publishing a new DAM and new certificates, and referencing them in new snapshots.

---

## 8. Federation Verification

When receiving state from another domain:

1. Load snapshot
2. Resolve DAM and AuthorityCertificate artifacts
3. Verify against configured offline root set
4. Apply policy hash compatibility rules

---

## 9. Summary

ASL/OCS/1 defines immutable authority certificates signed by offline roots and bound to policy hashes, enabling deterministic, offline trust validation.