Cut registry-consensus validation to ciris-canonical founder-quorum (retire single-steward-key root; end-state, no backward-compat)

[emooreatx]

Cut registry-consensus validation to the ciris-canonical founder-quorum — retire the single-steward-key root

Directive (maintainer): end-state cutover, NO backward-compat. "It is fine if it breaks, we need to get to the end state, just cut over." Do not build a dual-accept migration window.

The change

Today the single registry authority key is one secret vaulted + replicated US↔EU — the AV-14 single-point-of-compromise in HA clothing. It is being retired. Registry authority becomes the 2-of-3 founder-quorum of the three fabric occurrences' operational keys (lens + registry-us + registry-eu), the ciris-canonical governed infrastructure community (CEG 1.0-RC2 §5.6.8.10 / §8.1.13.3; CIRISRegistry/MISSION §2.1.1).

So the query type that validates registry consensus changes:

• FROM — single-key verification (steward_key.rs, §10.2 response-auth): pin one steward fingerprint, verify signatures against that key.
• TO — founder-quorum verification (infrastructure_community.rs): verify_founder_quorum over ciris-canonical — the machinery already shipped in v5.0.0 (Canonical encoding for M-of-N bootstrap key set + rotation ceremony tooling #31). This is wiring + re-rooting, not new crypto.

Concretely:

1. Re-root the consumer pin: from a steward fingerprint → the community_key_id = "ciris-canonical" trust anchor.
2. Resolve + quorum-verify (CEG 1.0-RC2 §8.1.13.1.1(a)): resolve_community("ciris-canonical", now) → founder-subset eval {m : m.role == founder} → require 2-of-3 signatures; comparator = quorum_weight DESC → signed_timestamp DESC → canonical_bytes_hash (the same one the resolver already pins).
3. Retire steward_key.rs as the registry-consensus trust root. It does not vanish — each occurrence still exposes its own identity (now /v1/identity, the §5.6.8.8.2 six-key aggregate) — but it is no longer the root of registry-consensus trust. The quorum is. No fallback to the single-key path.

Why this is correct (CEG 1.0-RC2, grounded)

• ciris-canonical is cohort_subkind: infrastructure → plaintext Commons, no DEK (§8.1.13.3 Open-Q1 ruling): the trust root is world-auditable by design, so quorum verification reads cleartext member/founder data.
• An infrastructure community's authority is the founder-quorum (§8.1.13.1.1(a) founder-subset eval), not any single key. Using the occurrences' operational keys as the quorum shares is conformant — a member key is just the occurrence's identity key; the quorum threshold supplies the privilege gate (so no separate offline authority key, and no §5.6.8.8.2/AV-17 reuse issue — same signing purpose).

Cross-repo dependency (not a blocker on starting the verifier wiring)

Registry must emit the ciris-canonical community Contribution naming the three occurrences as founders (role == founder). That gates on the three having distinct operational keys — i.e. splitting the shared vaulted key into registry-us / registry-eu operational keys (lens already has its own). That's the fabric-node key split; Verify's new query validates against the community once it's emitted. Verify-side wiring (route registry-consensus → verify_founder_quorum, re-root the pin) can land ahead of it against test fixtures.

Acceptance

• Registry-consensus validation calls verify_founder_quorum over ciris-canonical; the single-steward-key path is no longer consulted for it.
• Consumer pin is community_key_id, not a steward fingerprint.
• 2-of-3 founder-quorum enforced via §8.1.13.1.1(a) resolution; no single-key fallback.
• steward_key.rs retained only as per-occurrence identity surface, not the consensus root.

[emooreatx]

Update — CEG 1.0-RC3 grounds this cutover normatively, and adds one requirement: the pin must be re-rootable

CEG 1.0-RC3 (tag v-ceg-1.0-rc3) added the normative trust-model text this issue depends on. Two things land:

1. The cutover is now spec-backed. §5.6.8.10 (RC3) states registry-consensus authority is the founder-quorum over the ciris-canonical infrastructure community, and that registry is trust-only — "the founder-quorum is a closed mutual-trust set (the core trust each other)." So routing registry-consensus validation through verify_founder_quorum (retiring the single-steward-key root) is now the spec-conformant shape, not just an ops decision. Verification is pure trust (inbound acceptance of the quorum's verdicts); there is no consent dimension for the registry role (RC3 trust≠consent note).

2. NEW requirement — the validator MUST be re-rootable, not hardcoded to ciris-canonical. RC3 §5.6.8.10 makes it normative that ciris-canonical is a default, NOT a forced root: "a conformant consumer MUST be able to re-root — untrust the canonical group, pin a different cohort_subkind: infrastructure community instead or in addition, or run with none." So the registry-consensus validator MUST:

• take the pinned community_key_id as a parameter (default ciris-canonical, operator-re-rootable) — do NOT compile-in ciris-canonical as the only root;
• validate the founder-quorum (§8.1.13.1.1(a) founder-subset eval) over whichever infrastructure community is pinned;
• support pinning multiple trust-root communities, or none.

A hardcoded ciris-canonical root would be non-conformant under RC3 (it's a walled-garden root; the federation property is default-plus-re-root). The verify_founder_quorum machinery (#31, v5.0.0) already takes a community as input, so this is "thread the pinned community_key_id from operator config" rather than new crypto.

Net unchanged from the original ask (end-state cutover, no backward-compat): single-steward-key root retired; registry-consensus = founder-quorum; consumer pin = community_key_id. RC3 just (a) makes it normative and (b) requires that pin be re-rootable config, not a constant.

(Adjacent, FYI: RC3 also added §0.10 NodeCode — the canonical key_id shorthand CIRIS-V1-… — the human-facing render of the key_ids this verifier handles.)

[emooreatx]

Increment 1 landed — the single M-of-N policy rule (commit 6cdae31)

The reusable invariant is in, ahead of the trust-root cutover. One rule, applied everywhere a quorum is declared: a policy is valid iff 2·M > N (strict majority), 1 ≤ M ≤ N. No M==1 carve-out.

• threshold::QuorumPolicy{m,n} + parse("quorum:M/N") + is_valid()/validate(); verify_quorum_policy(...) validates fail-closed (deadlock rejected before counting), requires the founder roster to equal the declared N, then runs the founder-quorum.
• New errors DeadlockPolicy (the 2M ≤ N split-brain shapes) + RosterMismatch.
• Locked by test: 1/1·2/2·2/3·3/4·3/5 valid; 1/2·2/4·2/5·3/6 rejected. 555 core lib tests pass.

Design note (maintainer-decided): no 1/2 escape hatch. A 1-of-N "any one" shape is the single-point-of-compromise, not a small-install convenience — so a 2-install operator runs 2/2, and a fumbled add-the-second-install ceremony resets rather than degrading to a 1-of-2 SPOF. This is ciris-canonical's entrenched quorum:2/3 evaluated through one rule that also governs the accord, partner_record, and keyset rotation.

Held: the trust-root cutover — gated on the three founder keys

The breaking part is staged but deliberately not landed, because it needs the real keys, not placeholders:

• Re-root the consensus pin: bootstrap_stewards.json (single ciris-registry-main-v1) → the three ciris-canonical founders + community_key_id.
• constructor.rs manifest check: .any() (1-of-N — the AV-14 SPOF) → the community's 2/3 via verify_quorum_policy (needs the manifest to carry a 2-of-3 signature set — a Registry-emit change).
• Demote steward_key.rs to a per-occurrence identity surface; no single-key fallback.
• 3-founder fixtures; retire the v2.1.x single-steward lock test.

Resume trigger: Registry splits the shared vaulted key into the three distinct founder operational keys (registry-us / registry-eu / lens) and starts emitting 2-of-3-signed manifests. Pinning placeholder pubkeys or building against dummy fixtures now would either ship a fake trust root or be throwaway — so verify holds here. The policy machinery the cutover rides on is already in (verify_quorum_policy), so resumption is wiring + fixtures, no new crypto.

cc Registry — this is the verify side waiting on the fabric-node key split.