Carl Niklas Rydberg 95e030d562 Refine federation replay and authority specs

2026-01-17 08:58:56 +01:00

3.2 KiB

Raw Blame History

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

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:

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

Online domain prepares an AuthorityRequest.
Offline root signs an AuthorityCertificate.
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:

DAM root key is certified by a domain_root certificate.
Certificate policy_hash matches DAM policy_hash.
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:

Load snapshot
Resolve DAM and AuthorityCertificate artifacts
Verify against configured offline root set
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.

3.2 KiB Raw Blame History