From 2bbf1ffd83bf3d488094ea876d77f6e0744afea4 Mon Sep 17 00:00:00 2001 From: codex Date: Tue, 27 Oct 2026 21:15:22 +0100 Subject: [PATCH] RPF-WP-0064: phase B plan and confirmation for net-kingdom NK-WP-0049-T43 Co-Authored-By: Claude Sonnet 5.5 Assistant: claude-code Assistant-Model: sonnet Assistant-Process: 4515@bnt-lap001 Assistant-Session: 0bf96127-6e04-41be-bfda-d11717c3f354 --- WORK-RECORDS.md | 1 + ...-0064-isolated-original-openbao-restore.md | 73 +++++++++++++++++++ 2 files changed, 74 insertions(+) diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index b47cf80..8d600de 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -202,6 +202,7 @@ | task | RPF-WP-0064-T06 | done | — | workplans/RPF-WP-0064-isolated-original-openbao-restore.md | | task | RPF-WP-0064-T07 | done | — | workplans/RPF-WP-0064-isolated-original-openbao-restore.md | | task | RPF-WP-0064-T08 | done | — | workplans/RPF-WP-0064-isolated-original-openbao-restore.md | +| task | RPF-WP-0064-T09 | todo | — | workplans/RPF-WP-0064-isolated-original-openbao-restore.md | | task | RPF-WP-0065-T01 | done | — | workplans/RPF-WP-0065-netkingdom-role-claim-bindings.md | | task | RPF-WP-0065-T02 | done | — | workplans/RPF-WP-0065-netkingdom-role-claim-bindings.md | | task | RPF-WP-0065-T03 | done | — | workplans/RPF-WP-0065-netkingdom-role-claim-bindings.md | diff --git a/workplans/RPF-WP-0064-isolated-original-openbao-restore.md b/workplans/RPF-WP-0064-isolated-original-openbao-restore.md index f05a467..f0518f7 100644 --- a/workplans/RPF-WP-0064-isolated-original-openbao-restore.md +++ b/workplans/RPF-WP-0064-isolated-original-openbao-restore.md @@ -435,3 +435,76 @@ list. Also hand over the phase B offer terms (contained network with the isolated KeyCape, same custody, its own admission). The handoff makes no continuity claim. A pointer to the receipt goes to RPF-WP-0036-T03 as one isolated restore receipt; it does not count as recurring assurance. + +## Phase B plan and confirmation (2026-10-27, reply to net-kingdom message 5da58a3d) + +Source: net-kingdom `docs/nk49-phase-b-plan.md` (NK-WP-0049-T43); founder decision of 2026-10-27 names +railiance-platform as creator and tearer-down of the single `--internal` network and as keeper of the restored +OpenBao for the admitted window. **Preparation only.** This confirmation authorizes nothing, starts nothing and +creates no network. Every start needs a new founder-signed window; the `-03` admission (`3ef17fd1…4cc9`) and the +T40 window carry nothing over. + +**Confirmed:** railiance-platform can own (a) network create/inspect/egress-refusal proof/removal, and (b) the +phase A restore followed by keeping OpenBao up unsealed on that network for the admitted window, with a phase B +receipt. Subject to the changes and reviews below. + +**What the adapter does today (`7084b57`, attempt -03):** `--network none`, `lo` only, listener +`127.0.0.1:8200` with `tls_disable`, `api_addr`/`cluster_addr` on loopback, generate-root enabled +unauthenticated on that loopback listener, `check_network` requires `none`, receipt schema lists +`phase_b_network` as a not-claimed field, the verifier rejects phase B, teardown always runs (or by reaper), 45 +minute deadline from first custody input, no volumes. + +**What must change (new mode, phase A path stays byte-identical in behaviour):** +1. Admission and preflight: new signed phase B admission naming the network name, subnet, OpenBao alias + (`bao-restored`), admitted container set, window and adapter commit; preflight refuses a pre-existing + network or stale `rpf64-*` objects. +2. Network lifecycle: create `docker network create --internal` with a label naming the attempt; prove + `Internal=true`, no gateway, empty attached set; prove egress refused (public address, non-admitted name) + from a probe container before admission continues; at the end remove the network last and show it gone. The + reaper removes only objects carrying this attempt's label, never a network it did not create. +3. Listener: OpenBao must listen on the internal address (`0.0.0.0` inside the namespace, reachable only via the + internal network), `api_addr` accordingly, `--network --network-alias bao-restored`. Raft + `cluster_addr` stays loopback (single node). +4. `check_network` variant: exactly one named internal network, inspected `Internal=true`, attached set equals + the admitted containers, subnet route and no default route; the `lo`-only check is replaced for this mode. +5. Readback credential: phase A uses generate-root from the entered shares. In phase B the + unauthenticated-generate-root setting must **not** be exposed on the internal listener. Plan: keep it on a + separate loopback-only listener used for readback, or disable it after readback; the credential is revoked and + shown dead before the consumer is admitted to the network. The consumer only ever uses the JWT role. +6. Lifetime: do not tear down after readback; stay up until the founder window ends, a consumer-done signal, or + abort. The 45 minute limit runs from first custody input, so OpenBao starts last among long-lived pieces + (as the plan orders), and the consumer run follows at once. Hard deadline plus reaper stay. +7. Receipt schema v-next, verifier and adversarial fixtures for the phase B receipt (network facts, egress + refusal, revocation before consumer admission, teardown including network removal); no secret values, no KV + data. `phase_b_network` moves from not-claimed to claimed only in that mode. +8. TLS trust (net-kingdom item 4): OpenBao must trust the ISRG Root X1 chain to fetch + `https://kc.coulomb.social/jwks`; verify in the native rehearsal whether the pinned image's CA bundle suffices + and do not assume it. No self-signed substitute and no injected trust file without owner review. +9. Rehearsal: native run with synthetic material on a throwaway internal network plus a stand-in JWKS server; + offline tests extended. + +**Needs review:** all of the above is a new adapter commit and a new pin (T06 owner confirmation); the listener +and generate-root change (item 5) is the security-sensitive point and wants the same review depth as the phase A +adapter; admission schema change; independent verification of the phase B receipt from a clean clone. Network +subnet and container naming must be agreed with net-kingdom so the attached-set check matches. + +**Objections / conditions:** +- OpenBao stays up with an unsealed backend reachable by the consumer for hours versus the 45 minute phase A + bound; the founder must accept the longer exposure explicitly in the window (24 h maximum proposed; I suggest + a much shorter window). +- Ordering: network exists before the isolated KeyCape starts; whichever party starts second must not alter the + attached set. If NetKingdom's KeyCape cannot attach to a pre-created network, the plan fails closed. +- Docker is the only supported runtime here; the consumer runner is attached by the consumer owner and checked + by me by inspection only. +- No live action, no network creation, no custody input until the window, the new admission and pin exist. + +```task +id: RPF-WP-0064-T09 +status: todo +priority: medium +depends_on: [RPF-WP-0064-T08] +``` + +Phase B source preparation: implement items 1-9 above as a separate mode, rehearse natively with synthetic +material, obtain owner review and the new pin, then wait for a new founder-signed phase B window (T05-style +admission). No live run is part of this task.