diff --git a/FABRIC-2.md b/FABRIC-2.md index 4f2b5d4..1bed29f 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -2747,23 +2747,26 @@ bootstrapping question, 2026-08-22:** kernel. (c) A user with no SDK at all — presumably runs pre-built capsules only, no authoring capability. This refines the trust-tier question from item 17/spitball above: it's not a single core/contrib boundary, it's at least three capability levels. -20. **Snakeoil cert, embedded per-build — this resolves Milestone 7's open bootstrapping - question, at least for dev/test builds.** Every capsule and named blob gets signed with a - "snakeoil" cert (the standard term for a self-signed, non-production dev/test - certificate) that is itself embedded directly into each build — not loaded as a capsule - at runtime, not verified against an external CA at boot, part of the trusted build - process itself. This sidesteps the "how does the CA public key get into the kernel - without being just another unverifiable capsule" problem Milestone 7 raised, for the - dev/test case specifically: there's no runtime verification-against-external-root step at - all for snakeoil-signed content, because trust is established at build time, not boot - time. The real external-CA chain from Section U items 10-14 presumably still applies for - genuinely distributed/production builds; snakeoil is the dev/test answer, not a - replacement for it. +20. **Corrected, precise chain (Captain Bob's exact words): "my own real root CA → + snakeoil embedded cert → blob & capsule + MANIFEST.md."** This is one continuous chain, + not two separate paths as the previous draft of this item implied. The "snakeoil" cert is + not self-signed or independently trusted — it's an intermediate certificate signed by + Captain Bob's own real root CA (a real root he controls, "snakeoil" here naming its + informal/private-project status, not that it's untrusted or self-signed), and *that* + signed intermediate is what gets embedded into each build and does the actual per-blob/ + per-capsule signing. This resolves Milestone 7's bootstrapping question precisely, not + just "for dev/test": the CA public key never needs to get into the kernel at boot at all, + because the intermediate cert is already CA-signed and embedded at build time — trust is + established once, at build time, by whoever controls the root CA and produces the build, + not re-verified against an external root every boot. `MANIFEST.md`/`MANIFEST_AUTO.md` is + explicitly named as part of this same chain, not a separate tracking system bolted on + after — matching item 12's existing finding that its xxHash64 column is already the + documented Ed25519 anchor point. 21. **Two paths into a build, nothing else.** A capsule or named blob makes it into a build - only by (a) being signed with the build's own snakeoil cert, or (b) going through code - review and inclusion in either the build or the single source repo. This substantially - simplifies Milestone 8's still-open trust-tier decision (item 17's spitballed - directions) — "in the reviewed source repo" is itself the trust signal for + only by (a) being signed via the chain above (the embedded, CA-signed intermediate cert), + or (b) going through code review and inclusion in either the build or the single source + repo. This substantially simplifies Milestone 8's still-open trust-tier decision (item + 17's spitballed directions) — "in the reviewed source repo" is itself the trust signal for production-track content, rather than needing a separate signature-authority-tier scheme layered on top. Worth revisiting Milestone 8's punch-list items against this before picking one of the four originally-spitballed directions; at least one of them @@ -3233,18 +3236,20 @@ RAMDRIVE/DISK devices first without waiting for USB). ### Milestone 7 — Kernel/capsule PKI signing chain (Section U items 10-14, Section V area E) -- [ ] Generate (offline, outside the kernel/repo entirely) the CA root keypair — "stays +- [ ] Generate (offline, outside the kernel/repo entirely) the real root CA keypair — "stays unrevocable," never embedded, never loaded by any kernel code -- [ ] Generate an intermediate certificate, signed by the CA -- [ ] Embed the intermediate cert as a capsule blob (mechanically proven already via the - font-capsule precedent — no new embedding infrastructure needed, just a new payload) -- [ ] Implement kernel-boot-time verification of the embedded cert against a hardcoded CA - public key (the CA key itself has to be baked into the kernel some way that isn't - "just another capsule," since capsules are exactly what's being validated — this is a - real bootstrapping/chicken-and-egg design question not yet addressed anywhere in - Sections U/V/W) +- [ ] Generate the "snakeoil" intermediate certificate, signed by that real root CA (Section + U's fourth addendum: this is a real CA-signed intermediate, not a self-signed/untrusted + cert despite the name — "snakeoil" names its informal/private-project status) +- [ ] Embed the already-CA-signed snakeoil intermediate as a capsule blob at build time + (mechanically proven already via the font-capsule precedent — no new embedding + infrastructure needed, just a new payload) — **bootstrapping question resolved (Section + U fourth addendum): there is no kernel-boot-time verification of a hardcoded CA public + key needed at all.** Trust is established once, at build time, by whoever holds the real + root CA and produces the build — the embedded intermediate is already signed before it + ever reaches the kernel, so there's no runtime chicken-and-egg to solve. - [ ] Implement per-capsule signature verification (Ed25519) at capsule-load time, checked - against the now-verified intermediate cert + against the embedded (already-trusted) intermediate cert directly - [ ] Add a signing step to the `mkcapsule` build tool (or a separate signing tool) that produces a signature alongside each capsule's existing xxHash64 - [ ] Extend `MANIFEST_AUTO.md`'s generation to add a signature-status column, matching the