Below is a **clean, minimal, v0.1 draft** of the **ASL SOPS Bundle Layout**, designed to support: * offline authority creation * SystemRescue admission * courtesy leasing * future federation * zero dependency on DNS or live infrastructure This is a **transport + custody container**, not a runtime format. --- # ASL-SOPS-BUNDLE v0.1 **Offline Authority & Admission Package** --- ## 1. Purpose The ASL SOPS Bundle is a **sealed, offline-deliverable container** used to transport **authority material** into an ASL-HOST environment (e.g. SystemRescue) for: * Domain admission * Authority bootstrap * Courtesy lease negotiation * Initial artifact ingestion * Disaster recovery / rescue It is **not** used for runtime access or online key operations. --- ## 2. Design Principles 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 * **Outer format**: SOPS-encrypted YAML or JSON * **Encryption targets**: * age keys * PGP keys * hardware-backed keys (optional) * **No runtime secrets required** Filename convention (recommended): ``` asl-admission-.sops.yaml ``` --- ## 4. High-Level Structure ```yaml asl_sops_bundle: version: "0.1" bundle_id: created_at: purpose: admission | rescue | recovery domain_id: contents: authority: ... policy: ... admission: ... optional: artifacts: ... notes: ... sops: ... ``` Only `contents.*` is encrypted. --- ## 5. Authority Section (Normative) ### 5.1 Root Authority ```yaml authority: domain: domain_id: root_public_key: type: ed25519 encoding: base64 value: root_private_key: type: ed25519 encoding: base64 value: key_created_at: ``` Rules: * Root private key **must never leave** this bundle * Bundle should be destroyed after admission if possible * Rotation handled in later versions --- ### 5.2 Authority Manifest (DAM) Embedded verbatim: ```yaml authority: dam: version: "0.1" domain_id: root_public_key: issued_at: expires_at: roles: - domain_root metadata: human_name: "personal-domain" dns_claim: null ``` --- ### 5.3 DAM Signature ```yaml authority: dam_signature: algorithm: ed25519 signed_bytes: sha256 signature: ``` Signature is over the canonical DAM encoding. --- ## 6. Policy Section Defines **what this domain is asking for**. ```yaml policy: policy_hash: requested_capabilities: - store_blocks - publish_private_encrypted - import_foreign_artifacts requested_storage: max_blocks: 1_000_000 max_bytes: 5TB federation: allow_inbound: false allow_outbound: true ``` Policy hash is used for: * trust pinning * replay protection * lease validation --- ## 7. Admission Section ### 7.1 Admission Request ```yaml admission: target_domain: mode: courtesy | permanent intent: | Personal rescue operation. Data recovery from legacy laptop. ``` --- ### 7.2 Courtesy Lease Request (Optional) ```yaml admission: courtesy_lease: requested: duration_days: 180 storage_bytes: 2TB encrypted_only: true ``` --- ## 8. Optional Sections ### 8.1 Seed Artifacts (Optional, Rare) Used only when absolutely necessary. ```yaml optional: artifacts: - artifact_id: description: "Bootstrap provenance note" encoding: inline-base64 content: ``` ⚠️ Usually discouraged. Prefer ingestion post-admission. --- ### 8.2 Human Notes ```yaml optional: notes: | Generated offline on Debian laptop. Destroy after successful admission. ``` --- ## 9. Validation Rules (Host Side) An ASL-HOST **must**: 1. Decrypt bundle explicitly 2. Verify DAM signature 3. Recompute DomainID from root public key 4. Match DomainID exactly 5. Verify policy hash 6. Confirm admission intent 7. Apply courtesy lease limits strictly Failure at any step → **reject admission** --- ## 10. Security Posture | Threat | Mitigation | | ----------------- | ------------------------------ | | Bundle theft | Encryption + offline use | | Replay | Bundle ID + policy hash | | Identity spoofing | DomainID derived from root key | | DNS abuse | DNS is metadata only | | Key leakage | Offline generation | --- ## 11. Lifecycle Guidance Recommended flow: 1. Generate bundle offline 2. Verify contents manually 3. Transfer via USB 4. Admit domain 5. Destroy bundle 6. Rotate keys if reused --- ## 12. Explicit Non-Goals * Runtime authentication * Online key access * Federation syncing * Artifact transport at scale --- ## 13. Summary The ASL SOPS Bundle is: * a **sealed envelope** * carrying **identity + intent** * enabling **trust without infrastructure** * suitable for **rescue, bootstrap, and admission** * fully compatible with ASL-HOST and federation --- If you want next, we can: * define **key rotation bundles** * define **courtesy lease revocation** * formalize **Common admission policies** * or sketch the **SystemRescue UX flow** Just point.