amduat-api/notes/ASL SOPS Bundle Layout.md

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-<domain-id-short>.sops.yaml

---

4. High-Level Structure

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:
  ...

Only contents.* is encrypted.

---

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 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:

authority:
  dam:
    version: "0.1"
    domain_id: <DomainID>
    root_public_key: <repeat for integrity>
    issued_at: <iso8601>
    expires_at: <iso8601 | null>
    roles:
      - domain_root
    metadata:
      human_name: "personal-domain"
      dns_claim: null

---

5.3 DAM Signature

authority:
  dam_signature:
    algorithm: ed25519
    signed_bytes: sha256
    signature: <base64>

Signature is over the canonical DAM encoding.

---

6. Policy Section

Defines what this domain is asking for.

policy:
  policy_hash: <sha256>
  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

admission:
  target_domain: <CommonDomainID>
  mode: courtesy | permanent
  intent: |
    Personal rescue operation.
    Data recovery from legacy laptop.    

---

7.2 Courtesy Lease Request (Optional)

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.

optional:
  artifacts:
    - artifact_id: <hash>
      description: "Bootstrap provenance note"
      encoding: inline-base64
      content: <base64>

⚠️ Usually discouraged. Prefer ingestion post-admission.

---

8.2 Human Notes

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.