R-214 — Multi-conduit-receipt M-of-N timestamping

R-214 — Multi-conduit-receipt M-of-N timestamping

Status: research; proposes a protocol shape and verifier discipline. Non-normative until adopted into EXT.

Motivates: [THREATS §4.15] residual: "A captured conduit can still forge time. Multiple-conduit-receipts (M-of-N) raise the bar but do not close it. Real-time anchoring (e.g. cross-checking against signed STHs) is the next escalation."

[EXT §5.5] mandates at least one conduit_receipt on state-transition envelopes (birth, molt, deprecation). R-214 specifies the M-of-N escalation: when, why, with what diversity, and how verifiers handle the result.

1. Problem

A single conduit-receipt anchors the envelope's timestamp to one third party's view. If that conduit is captured (compelled, compromised, or colluding), it can:

• Issue a backdated receipt — the captured conduit signs a receipt with a ts earlier than reality. Used to "rescue" a deprecated sigil's pre-deprecation envelopes that the attacker wants to keep alive.
• Issue a forward-dated receipt — same mechanism, used to "freeze" envelopes inside a future-effective window.
• Refuse to receipt — the captured conduit declines to receipt envelopes from a target sigil, denying it any third-party time anchor for state transitions.

The single-receipt design is sufficient for casual time-correctness (most envelopes, most use cases) but inadequate for adversarial dispute resolution.

2. Threat model — what M-of-N defends against

M-of-N raises the bar against:

• Single-jurisdiction compulsion. A state actor compelling all conduits in jurisdiction J cannot forge an M-of-N receipt drawn from N>M conduits in jurisdictions ≠ J.
• Single-operator compromise. An attacker who compromises one conduit's signing key cannot produce M-of-N receipts unless they compromise M conduits.
• Single-conduit refusal. A target sigil whose primary conduit refuses receipts can still complete a state transition by collecting receipts from any M of N alternative conduits.

What it does NOT defend against:

• Collusion of M conduits. If the attacker controls M jurisdictionally-distinct conduits, M-of-N alone does not detect it. The diversity-policy and real-time-anchoring layers below address this.
• Real-time-anchoring failure. If all M conduits' clocks are uniformly skewed (e.g. by an NTP attack), M-of-N receipts agree on a wrong time. The STH-anchor check addresses this.

3. Design

3.1 Receipt set in the envelope

A state-transition envelope's signatures array MAY contain multiple conduit_receipt signatures. Per [EXT §6.4] progressive signing, each receipt signs the envelope-as-it-arrived plus all prior signatures.

For M-of-N, the envelope carries N receipts. The verifier checks at least M of them satisfy:

1. Each receipt's alg and scope are valid per [EXT §6].
2. Each signing conduit is on the verifier's accepted-conduit list (or has a Charter / LOTS the verifier accepts).
3. The N conduits collectively satisfy a diversity policy (§3.3 below).
4. The receipts' timestamps cluster within an acceptance window (§3.4 below).
5. Optionally: the cluster median time agrees with an independently-obtained STH timestamp (§3.5 below).

3.2 Per-class policy: when M-of-N is required

The protocol does not require M-of-N on every envelope. It applies tiered:

Why default 2-of-3: in cryptographic and certification design, 2-of-3 is the smallest M-of-N that still defeats single-party compromise while remaining tractable for the originator (the originator must reach 3 conduits, not 5 or 7). N=3 with M=2 also tolerates one conduit being temporarily unreachable — the originator submits to all 3, accepts whichever 2 respond first.

Default policies are configurable. A deployment with stricter requirements may require 3-of-5 for deprecation; a deployment with looser requirements may stay at 1-of-1 (current EXT §5.5). The Charter declares the deployment's choice (Herald Charter §2 issuance policy per R-203).

3.3 Diversity policy

M-of-N is hollow if the M conduits collude. The receipt set MUST satisfy declared diversity rules. Reference rule:

diverse(R₁, R₂, ..., Rₘ) ⟺
  jurisdiction(R₁) ≠ jurisdiction(R₂) ≠ ... ≠ jurisdiction(Rₘ)
  AND
  legal_entity(R₁) ≠ legal_entity(R₂) ≠ ... ≠ legal_entity(Rₘ)

Stricter deployments can add:

• infrastructure_provider: HSM operator, cloud region, key-custodian organisation. Two conduits both running on the same cloud region's HSM cluster fail this.
• operator_cluster: from D-307 SR-001's "ownership cluster" Charter declaration. Avoids two vendor-Heralds being treated as diverse.

Source of diversity declarations: each conduit MUST publish a Charter (analogous to Herald Charter, R-203). Verifiers consult the Charter to extract jurisdiction, legal entity, infrastructure, ownership cluster. Conduit Charters are out of EXT v0.2; they are flagged as a follow-on (D-318 candidate or new D-task).

3.4 Time-agreement window

Receipts collected from M conduits will not agree on ts exactly. Reference rule:

• The originator collects receipts within 60 seconds of submitting the envelope to the first conduit.
• For each receipt's ts, the verifier computes the median of the cluster.
• A receipt whose ts deviates from the median by > 30 seconds is flagged (not auto-rejected, since clock skew on a legitimate conduit can produce such deviation; the flag goes to monitors).
• A receipt whose ts deviates by > 5 minutes is rejected as evidence of clock skew or active manipulation.

Anti-collusion property: a colluding cluster of M conduits can agree on a forged median, but a single non-colluding conduit's ts will differ — making the forged-median-and-real-non-colluding-conduit pattern detectable. If all M+1 conduits agree on the same wrong time, that's the residual case (not addressed by this layer).

3.5 Real-time anchoring (STH cross-check)

The cluster median ts should be independently verifiable against an out-of-band time anchor. Reference mechanism:

• The originator obtains a fresh Signed Tree Head ([EXT §2.5]) from at least one HERALD CT log within 5 minutes of the receipt-collection window.
• The STH's ts is recorded alongside the receipt cluster.
• The verifier checks: |cluster_median_ts − STH_ts| < MMD where MMD is the log's Maximum Merge Delay (default 24h per EXT §2.6, but typical real values are 30min-2h).

Why this works: the CT log's STH series is a pre-existing time witness independent of the receipt cluster. To forge both the cluster and the STH, an attacker must also compromise the CT log — which is detectable via STH gossip ([EXT §2.5]).

The STH cross-check is optional at the receipt layer (it adds latency; not all senders will have a fresh STH on hand). It is mandatory for receipts used in dispute resolution per the verifier's policy.

3.6 Encoding

No new wire format. M-of-N receipts are simply N receipts in the existing signatures array. The envelope's signatures array's required count for the envelope's class is per the table in §3.2. Each receipt is a conduit_receipt-scoped signature per EXT §6.

A new attestation type m_of_n_receipts_metadata MAY be added to the envelope's attestations carrying:

{ "type": "m_of_n_receipts_metadata",
  "value": {
    "policy":        "<deployment-policy-id>",
    "M":             <int>,
    "N_observed":    <int>,
    "diversity_certified_by": "<sigil of conduit verifying diversity, optional>",
    "median_ts":     <Unix seconds>,
    "sth_anchor": {
      "log_id":    "<bytes>",
      "sth_ts":    <Unix seconds>,
      "sth_signature": "<bytes>"
    }
  }
}

This metadata is non-normative for receipt validity (the receipts themselves are the proof) but useful for verifiers' efficient lookup.

4. Verifier discipline

Reference verifier algorithm for an envelope class requiring M-of-N:

1. Filter envelope.signatures to those with scope == "conduit_receipt".
2. For each receipt R_i:
   a. Verify R_i.signature against the conduit's pubkey.
   b. Look up the conduit's Charter; extract jurisdiction, legal_entity, etc.
3. Reject if fewer than M valid receipts present.
4. Compute median_ts over the M receipts' ts values.
5. Reject any receipt with |R_i.ts − median_ts| > 5min.
6. Confirm the M receipts satisfy the diversity policy.
   If not, reject.
7. If real-time anchoring required: fetch fresh STH from log.
   If |median_ts − STH_ts| > MMD: reject.
8. Accept the envelope's effective ts as median_ts.

Step 8 is important: the verifier uses median_ts, not the originator's self-declared ts, as the time-anchor for downstream checks (e.g. "was this sigil alive at time X").

5. Performance and latency

M-of-N adds latency. Per-conduit receipt round-trip: typically 200ms – 2s. For 2-of-3:

• Sequential: ~6s (3 conduits × 2s).
• Parallel: ~2s (slowest of 3 responds within the time window).

Most originators should submit in parallel. The 60-second collection window is generous; even a fanout-of-3 with one slow conduit completes well within it.

For state-transition envelopes (birth, molt, deprecation), latency is acceptable: these are infrequent events (perhaps once per sigil-quarter for molt, once per sigil-lifetime for birth/deprecation). For application-layer envelopes (where M-of-N is not required), the existing 0-of-N (or 1-of-N) default applies.

6. Privacy

What does M-of-N leak that 1-of-N does not?

• Originator's choice of N conduits. Each conduit observes the envelope (transient routing). All M conduits know about the envelope, not just one.
• Diversity policy choice. The deployment's policy reveals what it considers "diverse" — implicitly, what threats it's defending against.

Mitigations:

• The originator can submit to N conduits via independent connections. The conduits do not see each other's traffic unless they collude.
• Diversity policy is published in the deployment's Charter; this is intentional transparency.

Net: M-of-N's privacy budget is comparable to 1-of-N times M. No new categorical leakage.

7. Migration path from EXT §5.5

EXT §5.5 currently mandates "at least one conduit_receipt" on state-transition envelopes. Migration:

1. v0.2.x (current): keep 1-of-1 as the default. Verifiers MAY require M-of-N per their policy.
2. v0.3: raise default for deprecation to 2-of-3; default for revoke_attestation to 2-of-3. Application-layer remains 0-of-N. Birth/molt remain 1-of-N as a backward-compat hedge.
3. v0.4 / v1.0: consider raising birth and molt to 2-of-3 if real-world deployment data shows captured-conduit attacks are observed. Otherwise remain at 1-of-N.

The migration is a registry update + a verifier-policy update. No envelope-format change is needed at any phase — the M-of-N is just a count requirement on the existing signatures array.

8. Anti-pattern: the "false-diversity" attack

Attack: an attacker stands up M conduits in distinct jurisdictions, each owned by the same entity but registered through shell companies. Charters declare different jurisdiction and legal_entity, but the operator is one party.

Defence:

• Conduit Charters MUST declare beneficial ownership (the natural-person or legal-entity controlling at least 25% of the operator). Aligned with conventional KYC requirements.
• Reputation systems aggregate historical behaviour across conduits — collusion patterns are detectable as cross-conduit timing-correlation, response-correlation, or signature-key-related-derivation anomalies.
• Independent third-party auditors verify operator separation. Out-of-protocol but in-ecosystem.

The protocol can require declarations; it cannot prevent lies. THREATS doctrine: legibility, not prevention. If the lie is told in the Charter, the attacker is committing a substantive misrepresentation that is litigable in the operator's declared jurisdiction. That's still a meaningful defence.

9. Open questions

1. Should diversity-policy be per-deployment or per-envelope? Current design: per-deployment (in the Charter). Alternative: per-envelope (the originator declares which diversity dimensions matter). Per-envelope is more flexible but more complex; suggest staying per-deployment until real-world friction demands flexibility.
2. What about NTP-poisoned clusters? If all M conduits' clocks are simultaneously skewed by an NTP attack, the median is wrong but consistent. The STH cross-check is the partial defence; it can detect skew >MMD but not finer. R-task follow-on: NTP-poisoning detection in conduit clusters.
3. STH-anchor selection. Which CT log's STH does the originator use? Current proposal: at least one of the logs the deployment trusts (per Charter). For maximum independence, the originator could use a CT log from a different jurisdiction than the receipt cluster — making clock-skew compromise expensive across yet another diversity dimension. Suggest making this a deployment policy, not a protocol requirement.
4. Half-received receipts. What if the originator receives M-1 receipts within the 60-second window and one straggler at 90s? The straggler is still cryptographically valid. Reference policy: accept stragglers up to a 300-second hard cutoff; flag as "delayed receipt" if > 60s but ≤ 300s. The verifier's median computation may produce a wider range; the 5-minute deviation cap kicks in.
5. What if a conduit receipts but its Charter is stale? The Charter staleness rule (12 months per EXT §3.5 / R-203) applies. A conduit with stale Charter is non-conformant; its receipt does not count toward M, but the originator may still keep it for evidentiary purposes (the receipt is still cryptographically valid; just doesn't satisfy the diversity policy).

10. Cross-references

• [SPEC §3.1] author-provided ts (the trust gap M-of-N closes)
• [EXT §5.1] conduit_receipt envelope shape
• [EXT §5.5] mandatory single receipt for state transitions
• [EXT §6] multi-signature semantics (the encoding M-of-N reuses)
• [EXT §6.3] domain-separation per scope
• [EXT §2.5] STH gossip (used for real-time anchoring)
• [EXT §2.6] LOTS (informs Charter-based diversity verification)
• [THREATS §4.15] backdated ts (the motivating walkthrough)
• [THREATS §4.4] split-view attack (parallel structure for STH-cross-check)
• D-307 SR-003 (state-actor compulsion — diversity policy is the legibility mechanism)
• D-307 SR-005 (compelled refusal — M-of-N gives originator a route around single-conduit refusal)
• R-203 Herald Charter template (shape for Conduit Charters)
• R-215 genesis-pinning gossip (parallel structure: cross-source verification of chain-anchored facts)

11. Implementation roadmap

If adopted into EXT:

1. EXT §5.6 — M-of-N receipt policy (new section, ~half a page).
2. EXT §5.7 — Conduit Charter requirements (parallel to Herald Charter; small section).
3. SPEC §3.4 amendment — multiple receipt signatures (clarification only; the existing array supports multiple).
4. Verifier-discipline pseudocode as appendix (the §4 algorithm above).
5. Test vectors — M-of-N envelope examples, including edge cases (median computation, time-window boundary, diverse vs non-diverse cluster). Belongs in T-001 / T-027 conformance suite.
6. Reference implementation — extends T-002 / T-003 / T-004 reference libraries' conduit-receipt support. Estimated ~1 week per language.

Closes

• R-214 (this task).
• THREATS §4.15 residual (multi-conduit hardening) — design now exists.
• D-307 SR-003 partial mitigation (state-actor compulsion via diversity-policy in receipt clusters).

Surfaced follow-on tasks

• D-319 — Conduit Charter requirements. Parallel to Herald Charter (R-203); needed for the diversity-policy lookup. Small D-task.
• R-221 — NTP-poisoning detection in conduit clusters. Open question (4) above.
• T-task in conformance suite — M-of-N test vectors. Median computation, time-window edge cases, false-diversity detection.

— R-214 research output, by driver-claude, 2026-05-05.