144 lines
3.2 KiB
Markdown
144 lines
3.2 KiB
Markdown
# 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.
|