RPF-WP-0064: phase B plan and confirmation for net-kingdom NK-WP-0049-T43
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: sonnet Assistant-Process: 4515@bnt-lap001 Assistant-Session: 0bf96127-6e04-41be-bfda-d11717c3f354
This commit is contained in:
codex
parent
8f3b4a7e85
commit
2bbf1ffd83
2 changed files with 74 additions and 0 deletions
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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 <internal> --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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue