Design: collaborative threshold CA for mesh via DKG + ZKP

[disentangle-network]

Problem

launch mesh init generates the ML-DSA-87 CA private key as a flat file on the operator's local disk. Single point of trust, architecturally inconsistent with the decentralized design. The CA key holder can mint arbitrary mesh identities.

Requirements

Core: genesis-managed CA lifecycle

• Genesis manages CA key generation, storage (envelope-encrypted), signing, rotation
• Raw CA private key never leaves genesis's trust boundary
• launch mesh init delegates to genesis CLI instead of running nebula-cert directly
• launch mesh add requests cert signing from genesis (signing happens internally)

Target: threshold CA via Distributed Key Generation (DKG)

• Multiple genesis instances across clusters collaboratively generate a threshold CA key
• No single genesis instance ever holds the complete CA private key
• k-of-n genesis instances must cooperate to sign a node certificate
• Each partial signing verified via zero-knowledge proof (correct key share usage without revealing the share)

Trust anchor

• Genesis instances verify each other via the protocol's DID + TMC consensus
• Only topologically verified nodes can participate in DKG
• Real human relationships between operators required to establish initial trust graph
• This is a feature: the network's security IS its social topology. You cannot join without real connections.

Bootstrap sequence (resolves circular dependency)

Mesh needs CA -> CA needs collaborative genesis -> genesis needs mesh to collaborate.

1. Single genesis instance generates bootstrap CA (degraded trust, acceptable for initial setup)
2. Mesh comes up using bootstrap CA, clusters connect
3. Genesis instances discover each other via mesh
4. Genesis instances run DKG ceremony (verified by DID + TMC)
5. New threshold CA replaces bootstrap CA
6. All node certs re-signed under threshold CA
7. Bootstrap CA revoked

Cross-project touchpoints

• protocol: ZK proof primitives, DID identity, TMC consensus for genesis verification
• genesis-operator: DKG implementation, threshold signing, envelope encryption
• launch: mesh init/add delegation to genesis
• nebula-pq: cert format compatibility with threshold-signed certificates

Open questions

• DKG protocol selection: Pedersen, Feldman, FROST -- need PQ-compatible variant for ML-DSA-87
• Threshold: 2-of-3? 3-of-5? Configurable?
• Communication channel during DKG: via nebula mesh? separate bootstrap channel?
• Certificate revocation under threshold CA
• Key resharing when new clusters join (redistribute shares without regenerating CA)
• Integration with existing protocol ZK primitives

Status

Design phase. Needs research into existing PQ-compatible DKG implementations before specifying.

[disentangle-network]

Research Findings + Design Refinements

Key Discovery: Threshold ML-DSA-87 Exists

Threshold-ML-DSA -- Go implementation built on Cloudflare CIRCL (same library nebula-pq uses). Supports ML-DSA-87 with up to 6 parties, 3 communication rounds per signing. By PQShield researchers (del Pino, Espitau, Niot, Prest). Presented at NIST's 6th PQC Standardization Conference, accepted at CCS 2025. Research-grade but functional.

• ePrint 2026/013 (full paper)
• ePrint 2025/872 (compact lattice threshold sigs)
• NIST is actively standardizing threshold PQ (NISTIR 8214C, MPTS 2026 workshop)

Phased Approach

Phase 1 -- Classical threshold, PQ certs (deployable now):

• FROST DKG (RFC 9591, production-ready) for the CA ceremony
• Threshold group uses FROST Schnorr to collaboratively sign nebula certs
• Node certs still use ML-DSA-87 individually
• Rationale: ceremony is synchronous, private-mesh, authenticated humans. Harvest-now-decrypt-later on DKG messages requires an attacker recording traffic on the private nebula mesh during the ceremony. If they have that access, there are bigger problems than quantum.

Phase 2 -- Full PQ threshold CA:

• Replace FROST Schnorr with Threshold-ML-DSA-87
• CA key, CA signatures, and node certs all PQ
• 6-party max (sufficient: genesis quorum IS a small high-coherence group where real social trust provides Sybil resistance)

Phase 3 -- Dynamic membership:

• Proactive share refresh (ZcashFoundation/frost has refresh_dkg APIs)
• CHURP-style dynamic committee for cluster joins/leaves
• Key resharing without CA regeneration

Marmot-Informed Design Refinements

The Marmot integration analysis identified structural parallels that tighten the design:

1. Admission flow timing is critical (from MIP-02 Welcome Events)
Marmot's MIP-02 defines: admin commits -> wait for relay confirmation -> send Welcome -> new member joins. Threshold CA cert issuance is the same flow: quorum signs cert -> wait for signing confirmation from k-of-n -> deliver cert to new node -> node joins mesh. If the cert is delivered before the signing round completes and all quorum members have updated state, some nodes accept the new node while others don't -- mesh fragments. This is a state fork. MIP-02 learned this the hard way and made it an explicit CRITICAL requirement. Apply the same discipline to cert issuance.

2. Cert operations should be DAG transactions (from D.1 substrate insight)
The Marmot analysis concluded that Marmot should run ON the Disentangle substrate -- protocol events ARE DAG transactions. The same logic applies: nebula cert issuance and renewal should be DAG transactions. Each cert signing by the threshold CA is a transaction that references the previous cert state as a parent. This gives:

• (a) Total ordering of all cert operations without a separate sequencing mechanism
• (b) Topological mass accumulation for genesis operators reflecting actual participation in mesh governance

3. Pre-signing for async cert renewal (from MIP-00 KeyPackage model)
Threshold-ML-DSA requires 3 communication rounds per signing. For initial genesis and occasional new node admission, operators are online and coordinated. But cert renewal (periodic for forward secrecy) requiring k-of-n genesis operators simultaneously online is a real operational constraint. Solution: pre-sign a batch of cert renewal tokens during a coordinated session, then nodes consume them asynchronously for renewal without requiring a live signing round each time. This is threshold pre-signing, which FROST supports.

4. Mass decay as quorum health signal (from D.3 dormancy analysis)
Mass decays with half-life T_1/2 = 10,000 depth units for dormant entities. For genesis operators: if a quorum member goes dormant (stops participating in cert operations, stops responding to signing requests), their topological mass decays. This is a structural signal that the quorum needs resharing -- better than waiting for explicit "operator X is gone" detection. The topology tells you before the human does. Phase 3's proactive share refresh should trigger on mass decay, not just explicit membership changes.

5. DAG-based revocation (faster than live threshold ceremony)
Cert revocation under a threshold CA means the revocation message also needs threshold authority -- another 3-round Threshold-ML-DSA ceremony per revocation event. Under active compromise, getting k-of-n operators online for 3 rounds has real latency. The identity crate's TransactionPayload::RevokeCapability provides a faster path: publish the revocation as a DAG transaction, other nodes observe it and stop accepting the revoked cert, without waiting for a new CRL signed by the threshold CA.

Bootstrap Sequence (refined)

1. Genesis operators exchange keys out-of-band (physical trust, real human relationships)
2. Stand up initial mesh with pre-shared keys or manual config
3. Run FROST DKG over this bootstrap mesh
4. Threshold CA signs ML-DSA-87 node certs
5. Mesh restarts with PQ certs
6. Bootstrap config is destroyed (forward secrecy)

Step 2->3 is the fragile moment. The bootstrap mesh has no PQ protection and no topological trust -- it is pure social trust materialized as pre-shared keys. This is fine for a 3-5 person ceremony. The transition from step 5 to ongoing operations (admitting new nodes) is where the protocol must be airtight.

The requirement for real human connections to build the network is a feature. The network's security IS its social topology. AI agents participate the same way -- vouched for by existing participants, growing trust organically through the same topological mechanisms.

Available Implementations

Library	Language	License	PQ	Maturity	Notes
Threshold-ML-DSA	Go	Research	Yes (ML-DSA-87)	Research	Built on CIRCL, 6-party max
ZcashFoundation/frost	Rust	Apache-2.0/MIT	No (classical)	Production	RFC 9591, audited, has share refresh
bytemare/frost	Go	Apache-2.0	No (classical)	Maturing	Go implementation of RFC 9591
drand	Go	Apache-2.0	No	Production	Threshold BLS, production since 2019
DEDIS Kyber	Go	MPL-2.0	No	Production	Pedersen/Rabin DKG, used by drand
tss-lib	Go	Apache-2.0	No	Production	Threshold ECDSA/EdDSA, audited
CHURP	Go	Research	No	Research	Dynamic committee proactive secret sharing

Open Questions for Spec

1. DKG protocol for Phase 1: FROST (Go: bytemare/frost) or Pedersen (Go: DEDIS Kyber)?
2. Threshold: 3-of-5 default? Configurable per-network?
3. How does genesis-operator's existing envelope encryption integrate with threshold key share storage?
4. Does the bootstrap mesh teardown (step 6) need to be explicit and enforced by genesis-operator?
5. Pre-signing batch size for cert renewal: how many renewal tokens per coordinated session?
6. Mass decay threshold for triggering proactive resharing: what mass level signals "quorum member is effectively gone"?

[disentangle-network]

Security Rationale Clarification: Threshold CA vs Topological Protection

These are orthogonal protections for different threat vectors, not primary/secondary defenses for the same one.

Topological protection (curvature) is immediate, not reactive

Edge curvature κ_J is computed at transaction commit time from already-committed ancestor sets (Definition 3.5.1). When a compromised high-mass node introduces a stranger:

• The stranger's ancestor set is tiny; the introducer's is large and well-connected
• Jaccard index ≈ 0, so κ ≈ -1
• Edge weight = clamp(1 + 3*(-1), 0.01, 1.0) = 0.01 — throttled to 1% influence from the first moment
• Every node independently computes this same curvature deterministically, regardless of observation order

There is no detection latency. The curvature signal doesn't develop or stabilize — it's deterministic from committed parent references the moment the transaction exists. The async ordering property means no coordination is needed.

Threshold CA protects non-DAG credentials

The CA certificate itself is a non-DAG credential — it exists outside the topology where curvature provides protection. A compromised genesis operator with the full CA key could sign arbitrary mesh certs without creating DAG transactions, bypassing topological scrutiny entirely.

The threshold (k-of-n) ensures you need k compromised operators to issue a fraudulent cert, limiting blast radius on this non-DAG attack surface. This is belt and suspenders: topology handles DAG-level trust, threshold handles infrastructure-level credentials.

What mass propagation actually is

Mass accumulation through the network does take time (descendants must reference a transaction). But this is normal protocol operation, not "detection latency." The new malicious identity starts at zero mass and can only accumulate through the throttled edge (1% weight). Even enormous introducer mass flows at only 1% through the bottleneck. The geometry is legible from the first moment — no state where the edge looks fine and later looks bad.