# ASL/SOPS-BUNDLE/1 -- Offline Authority and Admission Bundle

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

**Document ID:** `ASL/SOPS-BUNDLE/1`
**Layer:** L2 -- Offline authority transport (no runtime use)

**Depends on (normative):**

* `ASL/DAP/1`
* `ASL/DAM/1`
* `ASL/OCS/1`
* `ASL/POLICY-HASH/1`

**Informative references:**

* `ASL/OFFLINE-ROOT-TRUST/1`
* `ASL/DOMAIN-MODEL/1`

---

## 0. Conventions

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

ASL/SOPS-BUNDLE/1 defines an offline transport container for authority material. It does not define runtime APIs or key management behavior beyond bundle contents.

---

## 1. Purpose

The ASL SOPS Bundle is a sealed, offline-deliverable container used to transport authority material for:

* Domain admission
* Authority bootstrap
* Courtesy leasing
* Initial artifact ingestion
* Disaster recovery and rescue

It is a transport and custody format only. It MUST NOT be used for runtime access or online signing.

---

## 2. Design Principles (Normative)

1. Offline-first
2. Self-contained
3. Minimal trust surface
4. Explicit separation of authority vs policy
5. Human-inspectable before decryption
6. Machine-verifiable after decryption

---

## 3. Container Format (Normative)

* Outer format: SOPS-encrypted YAML or JSON.
* Encryption targets: age keys, PGP keys, or hardware-backed keys.
* Only `contents.*` is encrypted; metadata remains readable.

Recommended filename:

```
asl-admission-<domain-id-short>.sops.yaml
```

---

## 4. High-Level Structure (Normative)

```yaml
asl_sops_bundle:
  version: "0.1"
  bundle_id: <uuid>
  created_at: <iso8601>
  purpose: admission | rescue | recovery
  domain_id: <DomainID>
  contents:
    authority: ...
    policy: ...
    admission: ...
    optional:
      artifacts: ...
      notes: ...
sops:
  ...
```

---

## 5. Authority Section (Normative)

### 5.1 Root Authority

```yaml
authority:
  domain:
    domain_id: <DomainID>
    root_public_key:
      type: ed25519
      encoding: base64
      value: <base64>
    root_private_key:
      type: ed25519
      encoding: base64
      value: <base64>
    key_created_at: <iso8601>
```

Rules:

* Root private keys MUST NOT leave the bundle.
* The bundle SHOULD be destroyed after use.

### 5.2 Domain Authority Manifest (DAM)

The DAM MUST be embedded verbatim:

```yaml
authority:
  dam: <DAM object>
```

---

## 6. Policy Section (Normative)

```yaml
policy:
  policy_hash: <hash>
  policy_document: <DomainPolicy object>
```

Rules:

* The `policy_hash` MUST match the canonical hash of `policy_document`.
* The policy document MUST be compatible with ASL/POLICY-HASH/1.

---

## 7. Admission Section (Normative)

```yaml
admission:
  requested_scope: <scope>
  courtesy_lease: <optional>
  admission_request: <DAP admission object>
```

Rules:

* `admission_request` MUST satisfy ASL/DAP/1 admission requirements.
* Courtesy lease requests MUST be explicit and MUST NOT imply authority.

---

## 8. Optional Sections (Informative)

Optional sections MAY include:

* Artifacts for bootstrap
* Notes for operators

Optional content MUST NOT be required for admission.

---

## 9. Validation Rules (Normative)

An ASL-HOST MUST reject the bundle if:

1. The SOPS envelope cannot be decrypted by allowed keys.
2. `policy_hash` does not match `policy_document`.
3. The DAM is missing or invalid.
4. Admission request violates ASL/DAP/1 requirements.

---

## 10. Non-Goals

ASL/SOPS-BUNDLE/1 does not define:

* Online key usage or rotation
* Long-term key storage requirements
* Transport mechanisms for bundles
* Host-side UI or operator workflow

---

## 11. SOPS Role Clarification (Informative)

SOPS is used as a **transport envelope** only:

* It protects authority material in transit.
* It does not establish trust or replace signatures.
* After decryption, only the payload bytes are hashed or signed.

SOPS containers MUST NOT be treated as authority artifacts.