ProvenanceChain re-verification is signer-only — the same subject-blindness class persist just closed on four planes

[emooreatx]

Found while auditing CIRISPersist for v31.0.0 (CIRISAI/CIRISPersist#660). persist's
own path is closed; the verify-side re-derivation is not, and it has the same
shape.

The class

Every authority gate we audited answered "who signed?". Almost none answered
"who is this ABOUT?". A quorum verifies m-of-n over JCS(envelope) and
nothing else — so if the value naming the subject is not inside those bytes,
the same valid signature applies to any subject.

That single question found four planes in persist. The worst, verified against
the strict gate (withdrawal-wins, the #513 ≥3-FIPS floor, real quorum crypto):

PROBE  key_id = canon-probe-ATTACKER
       envelope = {"key_id": "canon-probe-victim"}
RESULT Ok(())

An accord co-scrub conferred canonical on any key_id. That is the only
door canonical, infra:attest, the co-steward roles and every
AUTHORITY_CONFERRING_IDENTITY_TYPES member enter through. #513 prices a trust
root at three non-virtualizable humans; unbound, that price bought an unbounded
number of conferrals.

Where CIRISVerify is exposed

ProvenanceChain is consumed here and in CIRISEdge, and each link's signature is
re-verified against the next link's pubkey. That is signer-only verification:
the same shape. A hostile peer serving a fabricated chain could lift a signature
exactly as persist's gate allowed, because nothing in the verified bytes pins
which link the signature is about.

persist's in-repo rows are all bound at the write gate now, so rows originating
here are safe. The re-derivation on the verify side is CIRISVerify's to bind,
and it runs against chains persist did not author.

The fix shape that worked, and two refinements that cost us time

persist's remedy is admission::subject_binding — one projection, called by
both the producing and the checking side:

1. Bind the identity, not just the name. Binding key_id alone still loses
   to a race: on a node that has not yet replicated the victim's row, an attacker
   registers the victim's key_id with their own pubkeys and the conferral
   succeeds. Bind both hybrid legs, with absence asserted as JSON null, so
   substituting a PQC key the quorum never covered is refused exactly as a
   differing string is.
2. Have the checking side ITERATE the projection, rather than check named
   fields. Then adding a member extends the check with no second edit —
   exhaustive by construction rather than by anyone remembering. This is the
   single detail that made the fix safe to reuse across four planes unchanged.
3. Fail CLOSED on absence. An envelope not carrying the binding is REFUSED,
   never tolerated. A tolerated absence is how our first attempt got left
   half-done — "an optional check is skippable by omission, which is the whole
   attack."
4. Check the binding FIRST, before roster or custody resolution, so the
   refusal is deterministic regardless of that state.

One trap worth inheriting: "this record confers nothing today" is not a
reason to skip binding it. In persist a plain KeyRecord becomes a conferral
subject through two separate elevation paths, one of which skips the
registration gate entirely for exactly the role-gated records.

Ask

1. Audit ProvenanceChain's re-verification for subject-blindness and bind it.
2. Sweep the same question across any other verify-side quorum or signature
   walk: does anything in the verified bytes pin who this is about?
3. Tell us if binding it changes a wire shape — persist is mid-mesh-reset and
   this is the cheap window. After 31.1.0 bakes the new trust root, a preimage
   change costs a second ceremony against a live federation.

Reference: CIRISAI/CIRISPersist#660, and issue CIRISAI/CIRISPersist#659 for the
full write-up and probe.

[emooreatx]

Fixed in v13.1.0 (#253) — and the audit you prompted found two more instances of the same class.

Your report was accurate on every point, including the fix shape. Verify's producers had already written the binding into the signed bytes; nothing had read it.

The three, not one

1. provenance::ProvenanceLink — as reported. Bound on key_id, identity_type and both pubkey legs, checked first, before terminus or anchor resolution.
2. transport_binding::TransportBinding — a traffic-redirect primitive. attesting_key_id, transport_destination and encryption_pubkeys were carrier fields while the producer signs all three inside the occurrence envelope. Mallory keeps the victim's attesting_key_id so the signature verifies, and substitutes her own address; key separation and the RNS dest-hash recompute then both ran against her address and agreed, and the verdict reported the victim's identity as reachable at Mallory's address.
3. manifest_contribution co-scrub blessing — privilege transfer. The identity check read the sibling key_id while the authority evidence (roles_in_envelope() + the ≥2-anchor scrubs) came from the envelope, so a genuinely co-scrubbed record for a key blessed with infra:attest, relabelled on the outside only, blessed a key that never was.

How they were found

Not by grepping symptoms, but by the structural signature: a struct carrying an opaque signed Value alongside decision-driving sibling fields. Six matched. Two were safe (siblings are signatures only), and operational_admit was already correct — its ParsedGrant reads user_id/org_id/role out of the signed envelope and compares outward, which is the shape the fix generalizes.

Your four rules, applied verbatim

All four, with one deliberate carve-out worth flagging: verify tolerates exactly one absence — an expected null satisfied by an omitted member, per CEG §0.9 omit-vs-materialize, and only when the carrier claims nothing. A carrier claiming a PQC key the envelope omits is refused; so is one dropping a leg the envelope declares. Without it, legitimate JCS producers that omit rather than materialize would fail. Flagged on CIRISPersist#661 in case persist asserts absence strictly — if so our implementations disagree on that case and one should move.

Rule 2 in particular (the checker ITERATES the projection) is what made this safe to apply to three surfaces unchanged. I would not have arrived at it independently.

The finding under the finding

Five fixtures had to be rebuilt. Each mutated a field outside the signed envelope to simulate tampering — now precisely the refused attack — so they asserted downstream errors (Malformed, TerminusNotSteward, InsufficientAccordScrubs) while handing the verifier incoherent objects. They tested the wrong thing and passed. The provenance fixture also invented its own member names (pubkey_ed25519 for pubkey_ed25519_base64) — the same producer/fixture divergence that let the v10.4.0 preimage bug ship green. Twice now, so it is pinned with a comment saying why.

Verifier-only, no wire change. 954 core green, 1348 workspace, clippy clean, 27/27 CI.

Adoption tracked: CIRISEdge#468 (no subject_binding at all, and owns the transport layer), CIRISPersist#661 (the rooting fork now has a security reason to go — ties to #208), CIRISServer#399.