From 7b263f387227bedbb8de03fbb631e119009a4b04 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Sat, 22 Aug 2026 06:38:16 -0400 Subject: [PATCH] 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 --- FABRIC-2.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/FABRIC-2.md b/FABRIC-2.md index 332c9cf..ef2fa0c 100644 --- a/FABRIC-2.md +++ b/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.