amduat-api/notes/bootable authority host image.md

Absolutely — let's think this through step by step. The goal is a bootable authority host image that’s offline, deterministic, and ready to handle domain admission, DAM signing, SOPS bundles, and PER generation. Here's a blueprint for assembling it.

---

1. Base OS

• Choose a minimal Debian/Ubuntu or SystemRescue-based environment.

  • Needs basic POSIX tools, filesystem utilities, and networking disabled (offline by default).

• Install essential tools only:

  • bash, coreutils, tar, gzip, xz, find, sha256sum
  • sops binary for offline bundle handling
  • git optional, for versioning tools inside the image

• Disable unnecessary daemons (sshd, cron) for security.

---

2. Filesystem Layout

Create the ENC-ASL-AUTH-HOST structure inside the image:

/asl-auth-host/
├─ /domains/             # domain stores
├─ /tools/               # binaries
├─ /env-claims/          # environment snapshot hashes
└─ /sops-bundles/        # encrypted bundles

• Use read-only overlay for system files

• Persistent storage can be mounted as /domains or /store (ZFS, ext4, or Btrfs)

• Optionally, set up ZFS pools for:

  • /domains/<domain-id>/store
  • /domains/<domain-id>/snapshots

• The image itself is immutable — only mounted storage is written to.

---

3. Tools to Include

• asl-auth-host binary — main authority program

• asl-rescue binary — optional rescue support for SystemRescue-style data intake

• sops — offline encryption/decryption of bundles

• Optional helper scripts:

  • make-dam.sh — create DAM artifacts
  • sign-bundle.sh — sign SOPS bundles
  • verify-env.sh — calculate env-claims

---

4. Boot Configuration

• Boot kernel options:

  • Mount persistent storage for /domains (ZFS, ext4, etc.)
  • Mount overlay read-only system (/tools, /env-claims, /sops-bundles)

• Auto-start a shell or interactive prompt for offline operation.

• Optional: menu for:

  • Create new domain
  • Sign DAM / issue certificates
  • Prepare SOPS bundle
  • Rescue/import artifacts

---

5. Domain Initialization

When first booting:

1. Generate root key pair for the domain.

2. Optionally generate DAM signer keys.

3. Create the domain directory:

   /domains/<domain-id>/
   ├─ store/
   ├─ log/
   ├─ snapshots/
   ├─ certs/
   ├─ policies/
   └─ dam/
   

4. Initialize empty log, empty store, and environment claim file:

   /env-claims/<snapshot-id>.claim
   

5. Seed the domain with common domain reference, if applicable.

---

6. Certificates and Policies

• Root keys must be encrypted at rest.
• DAMs signed using offline authority host root keys.
• Policies included in /domains/<domain-id>/policies/.
• All signed artifacts stored in /sops-bundles/ for delivery.

---

7. Optional Persistence

• If you want the host bootable from USB:

  • Overlay FS (SquashFS or ISO) for system binaries
  • Writable ZFS/Btrfs/EXT4 for /domains and /sops-bundles

• This allows the system to remain fully offline but store persistent artifacts.

---

8. Recommended Approach

• Immutable image for the offline host (SquashFS or ISO)

• Writable storage for domains (/mnt/pool) or USB disk

• Use ZFS datasets for:

  • Block storage
  • Snapshots of logs & store

• Pre-load binaries for deterministic PER generation, DAM signing, and rescue scripts.

• Environment claims stored and optionally signed before any DAM operation.

---

If you want, I can write a concrete build script outline (e.g., Debian-based ISO with overlay + ZFS pools + included binaries + directory structure), so you have a starting point to actually produce the bootable auth host image.

Do you want me to do that next?