FABRIC-2.md Section U second addendum: kernel/capsule signing design,

extending items 7-8 -- still brainstorming, nothing implemented

Five more points captured: (10) intermediate cert embedded as a capsule
blob (CA stays external/unrevocable), reusing the capsule system's
already-proven arbitrary-binary-payload capability (the font capsule is
existing precedent); (11) two-stage validation chain, both stages net
new code; (12) confirmed via tools/mkcapsule.c's own header comment
that Ed25519 signing hanging off the xxHash64 manifest column was
already the documented Phase 8 plan, independent of this conversation
-- strong validation of the whole direction; (13) signing granularity
is per-capsule, matching the existing hash column's 1:1 file
granularity exactly; (14) content-type detection via magic numbers
rather than a new MIME-type field, and confirmed to be the same
mechanism as item 7's foreign-drive detection -- one shared
byte-sniffing primitive plausibly serves both.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-2.md

@@ -2653,3 +2653,38 @@ virtio-blk's build-out for comparison.
    attached to that VM and only that VM → "I have permission to use a [thumb drive as a
    credential] tool. I'm gonna use a console. Simple as that" (Captain Bob, describing the
    intended user experience end state).
+
+**Second addendum, same session — kernel/capsule signing, extending items 7-8 above:**
+
+10. **Kernel-embedded certificate, CA stays external.** The CA root stays "unrevocable" —
+    external, offline, never embedded, never loaded by the kernel. An intermediate certificate
+    (signed by the CA) gets baked into the kernel image as a capsule blob, using the capsule
+    system's *existing* proven ability to carry arbitrary binary payloads — confirmed by
+    checking the actual manifest: `fonts:JetBrainsMono-Regular.ttf` (270224 bytes) is already
+    embedded exactly this way today, right alongside `.4th` FORTH source, with its own
+    xxHash64 entry in `capsules/MANIFEST_AUTO.md`. Embedding a cert as a capsule blob is not
+    new infrastructure, just a new consumer of infrastructure that already works.
+11. **Chain of validation: kernel validates its own cert against the CA at boot, then
+    validates every capsule it loads against that cert.** Both steps are net-new code — no
+    signature/certificate verification exists anywhere in the tree today. This is distinct
+    from, and additional to, the content-integrity hashing that already exists (item 12).
+12. **Confirmed: `MANIFEST_AUTO.md`'s xxHash64 column is content-integrity, not
+    authenticity — and Phase 8 signing was already the documented plan for it, independent of
+    this conversation.** `tools/mkcapsule.c`'s own header comment states, verbatim: *"The
+    xxHash64 column is the anchor for future Ed25519 fingerprints (Phase 8)."* This whole
+    design thread (cert-as-capsule-blob, signature-per-capsule, extending the manifest) is
+    confirmed to already be the intended direction, not something invented fresh this
+    session — strong validation, not a new decision.
+13. **Signing granularity: per-capsule, matching the existing hash column exactly.** One
+    signature per capsule file (`ACL.4th` signed separately from `zuse.4th`, separately from
+    the font, etc.) — same 1:1 granularity `MANIFEST_AUTO.md` already uses for hashes, no new
+    grouping concept (e.g. no "sign a class of capsules together" batching).
+14. **Content-type detection: magic numbers, not a MIME-type field.** Today, a capsule's
+    content type is determined purely by its file extension string, "preserved verbatim,
+    meaningful only at load time" (`mkcapsule.c`'s own wording) — no MIME-type field exists,
+    and Captain Bob's explicit call is not to add one. Instead, content type gets identified
+    by sniffing the actual bytes (magic numbers), same technique `file`(1) uses. **This is the
+    same mechanism as item 7's foreign-drive detection** — both are "identify what you're
+    holding by its actual bytes, not by a trusted external label" (a file extension in one
+    case, a drive's claimed filesystem type in the other) — plausibly one shared
+    magic-number-sniffing primitive serves both jobs rather than two separate ad hoc checks.