4 KiB
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/1ASL/DAM/1ASL/OCS/1ASL/POLICY-HASH/1
Informative references:
ASL/OFFLINE-ROOT-TRUST/1ASL/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)
- Offline-first
- Self-contained
- Minimal trust surface
- Explicit separation of authority vs policy
- Human-inspectable before decryption
- 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)
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
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:
authority:
dam: <DAM object>
6. Policy Section (Normative)
policy:
policy_hash: <hash>
policy_document: <DomainPolicy object>
Rules:
- The
policy_hashMUST match the canonical hash ofpolicy_document. - The policy document MUST be compatible with ASL/POLICY-HASH/1.
7. Admission Section (Normative)
admission:
requested_scope: <scope>
courtesy_lease: <optional>
admission_request: <DAP admission object>
Rules:
admission_requestMUST 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:
- The SOPS envelope cannot be decrypted by allowed keys.
policy_hashdoes not matchpolicy_document.- The DAM is missing or invalid.
- 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.