The Native-Signature Boundary in Post-Quantum Distributed Authorization

1 Introduction

• The signature scheme can determine key generation, party state, preprocessing, partial-signature production and combination, and share refresh.For distributed signing, an unchanged verification API can conceal replacement of the custody protocol.Source: §1 · pp. 1–2
• ML-DSA and SLH-DSA are standardized for conventional signing rather than as threshold protocols, while candidate distributed approaches differ substantially in their scheme-specific machinery.Threshold lattice signatures may require different sampling, rejection, abort, and proof machinery; standardized hash-based signatures face additional constraints.Source: §1 · p. 2
• Programmable authorization lets member keys migrate independently, but its approval evidence is not one native signature accepted by an unchanged legacy account.A trusted HSM can translate that approval into native output by signing with a complete key, introducing a trust boundary.Source: §1 · p. 2
• The paper compares designs by native-verifier compatibility, resistance to unilateral authorization, and whether the signature scheme can change without replacing threshold protocol and state.These questions distinguish output format, compromise boundary, and threshold-layer dependence.Source: §1 · p. 2
• Without a complete native key, native output requires placing the signing relation in a specialized threshold protocol or generic secure-computation circuit; keeping the threshold layer independent requires a programmable verifier or trusted translator.Generic MPC may keep its execution engine stable, but its signing circuit and other scheme-specific artifacts still change.Source: §1 · p. 2

2 Scope and method

• The paper contributes a conceptual taxonomy and comparison framework for where signature-scheme dependence sits when authorization is distributed and the destination verifier may be programmable.It is not a systematic literature review, performance survey, or construction paper.Source: §2 · p. 3
• The classification is architectural rather than exhaustive, covers public material available through August 2026, and prioritizes standards and peer-reviewed work while identifying less mature sources.Its representative families include specialized threshold protocols, generic MPC, distributed hash-based signing, programmable authorization, and trusted signers.Source: §2 · p. 3
• Generic MPC evaluates a signature scheme’s signing algorithm as a circuit in a general-purpose secure-computation framework rather than using a scheme-specific threshold protocol.A custody offering may expose multiple paths, such as the documented HSM and MPC options described for Zodia Custody.Source: §2 · p. 3
• The comparison follows each authorization path across setup, state, approval, combination, verification, maintenance, policy, evidence, and integration.It asks which lifecycle components depend on the scheme, whether a complete native key exists, and what the destination verifies.Source: §2 · p. 3
• The classification excludes performance rankings because protocol cost depends on parameters, adversary model, network, implementation, and hardware.The paper also assumes components enforce their specified rules and does not claim one architecture dominates.Source: §2 · pp. 3–4

3 Comparison dimensions

• Native-signature compatibility means authorization produces one signature accepted by the conventional verifier without auxiliary proofs, threshold-specific state, or a modified verification rule.This specializes the NIST Threshold Call’s interchangeability criterion [8, Sec. 3.3.2].Source: §3 · p. 4
• Unilateral-signing resistance requires that no participant, dealer, or trusted component can authorize alone and that fewer than t authorization parties cannot produce an accepted authorization.The criterion concerns the compromise boundary, not output format or sharing mechanism.Source: §3 · p. 4
• Threshold-layer agility means changing signature schemes without replacing the threshold relation, protocol, or threshold secret state, while distributed approval and maintenance semantics remain unchanged.The boundary is stronger than API or verifier agility; a stable interface can conceal replacement of shares and preprocessing.Source: §3 · pp. 4–5

3.1 Migration impact surface

• The migration impact surface tracks lifecycle components whose implementation, state, wire semantics, trust assumptions, failure procedures, or security arguments must change with the scheme.It spans key generation and setup, state, approval and combination, verification, maintenance, policy, evidence, and integration; the set matters more than its size.Source: §3.1 · p. 5

3.2 The native-signature boundary

• Native verification fixes a scheme-specific relation, so some component must produce an accepted output using native signing material.The broad placements are a specialized threshold protocol, a generic MPC signing circuit, or a component holding or reconstructing the complete key; otherwise the destination verifies a different relation.Source: §3.2 · pp. 5–6
• Table 1 applies the three definitions, with “Agile” referring to the threshold authorization layer rather than every scheme-dependent component.Its hash-based classification is construction-dependent: one cited stateful construction uses a trusted dealer, while the PRAWNS preview leaves distributed key generation open.Source: Table 1 · p. 6

4 Classification of authorization designs

• No surveyed design combines native output, unilateral-signing resistance, and threshold-layer agility; the empty cell illustrates a recurring tension, not an impossibility theorem.The classification applies the same three definitions across the design families.Source: §4.1 · p. 6, §4 · p. 6

4.1 Interpreting the empty cell

• Native output with unilateral-signing resistance embeds signing in a specialized protocol or MPC circuit, while decoupling scheme dependence requires non-native verification or a trusted complete-key signer.Generic MPC may keep its engine and backend stable, but replacing the signing circuit and native key shares means it does not provide threshold-layer agility.Source: §4.1 · pp. 6–7

4.2 Specialized native threshold signatures

• Specialized threshold ECDSA, FROST, and lattice signatures produce standard signatures for unchanged native verifiers without requiring a participant to hold the complete key.Their distributed protocol, key shares, and any scheme-specific preprocessing, refresh, or security arguments change with the signature scheme.Source: §4.2 · p. 7

4.3 Generic MPC signing

• Generic MPC can evaluate signing algorithms on shared key material, but practical security and correctness depend on the protocol and construction, and migration changes the circuit and key shares.Hash evaluation may be prohibitive, while lattice implementations must account for protocol cost, abort behavior, and signature distribution.Source: §4.3 · p. 8

4.4 Distributed hash-based signatures

• Distributed hash-based signing remains tied to the hash-based signing relation; constructions vary in setup, reference-state, and key-generation assumptions.The cited stateful LMS/XMSS transformations use a trusted dealer and large common reference value, while PRAWNS leaves distributed key generation unresolved.Source: §4.4 · pp. 8–9

4.5 Programmable authorization

• Programmable multisignature lets member keys migrate independently and supports mixed-scheme quorums, but its output is not one signature accepted by an unchanged legacy verifier.It requires an enforcement layer that checks the authorization relation; key-aggregating multisignatures instead produce a native signature.Source: §4.5 · pp. 9–10
• Dual-gate authorization separates member-signature schemes from a Shamir-shared authorization seal, preserving threshold state and refresh while member keys and adapters change.Its output is not native, but it provides unilateral-signing resistance and threshold-layer agility in the classification.Source: §4.5 · pp. 9–10

4.6 Threshold-authorized HSM signing

• Threshold-authorized HSM signing produces native output and can keep the approval gate stable, but a complete-key signer does not provide unilateral-signing resistance.A compromise permitting unauthorized use of the HSM-held key bypasses the external quorum.Source: §4.6 · p. 10

5 Migration comparison

• Adding destination verification support does not make a custody system capable of producing the new artifact; the SLH-DSA impact profile is counterfactual, not a deployment claim.No cited purpose-built construction currently provides a complete dealerless threshold instantiation of SLH-DSA.Source: §5 · p. 10
• A replaceable API can conceal materially different internal migration work: programmable designs change member keys and adapters, while HSM signing replaces the hardware-held key and signing implementation.The programmable threshold layer does not change, but the destination no longer verifies one native signature.Source: §5 · pp. 10–11
• For ML-DSA, specialized lattice threshold protocols and generic MPC circuits have different migration impacts; SLH-DSA illustrates the more extensive distributed-evaluation path.Destination support remains separate from the ability to produce the new artifact.Source: §5 · p. 11

5.1 Hybrid operation and historical evidence

• Policy-selected hybrid quorums verify member signatures independently, so their components remain separable and security depends on the weakest permitted quorum unless policy requires a post-quantum subset.Historical verification also requires retaining old verifiers or checkpoints for native designs, and policy versions, member registries, algorithm identifiers, and threshold-state commitments for programmable designs.Source: §5.1 · p. 11

6.1 Separation of claims

• Format/API choice, verifier migration, MPC circuits, member-key replacement, native output, threshold-state replacement, and approval gates are distinct agility claims.A system may support one without satisfying the others.Source: §6.1 · p. 12

6.2 Locating a deployment in the design space

• A native-only destination rules out programmable authorization; without a complete-key holder, migration reaches the distributed protocol or signing circuit.A trusted signer can preserve the approval gate while replacing its native key and implementation.Source: §6.2 · p. 12
• With programmable verification, compare a scheme-specific threshold protocol against limiting migration to member keys, registries and adapters, acceptance policy, and evidence encoding.Source: §6.2 · p. 12
• A certified HSM preserves a stable approval gate and native output but adds an explicit trust anchor; generic MPC shifts review to circuits, key generation, correctness, and cost.Those are the artifacts that change with the algorithm in the generic-MPC case.Source: §6.2 · p. 12

6.3 Limitations

• The classification is definition-sensitive: this stricter threshold-layer test treats circuit, native-key, and scheme-specific validation changes as material custody events.An operator may call a stable MPC engine agile when only its loaded circuit changes.Source: §6.3 · p. 12
• The paper gives no performance ranking or impossibility result; its SLH-DSA profile is hypothetical, and other cryptographic and infrastructure layers have independent migration paths.The PRAWNS discussion relies on an initial public research description, leaves distributed key generation unresolved, and imposes a quorum-intersection bound.Source: §6.3 · p. 12

• Specialized threshold signing embeds the native relation in the distributed protocol, generic MPC places it in a circuit, and programmable authorization uses a different verifier-accepted artifact.Source: §7 · p. 13
• Threshold-authorized HSMs translate agile approval into native signing while concentrating the native key in hardware.Source: §7 · p. 13
• No surveyed placement is universally preferable: preserving native output and unilateral-signing resistance keeps scheme-dependent artifacts inside distributed signing, while moving them outside requires a programmable verifier or complete-key trust anchor.Source: §7 · p. 13