feat: post-quantum signature support (SLH-DSA / FIPS 205)

[avrabe]

Context

wasmsign2 uses Ed25519 for Wasm module signatures. portal-co/wasmsign3 is an experiment replacing this with SLH-DSA (FIPS 205, stateless hash-based signatures via Shake128s) — a post-quantum scheme.

for safety-critical and long-lived embedded targets, post-quantum readiness may become a compliance requirement. rather than a separate tool, sigil could support SLH-DSA as an additional signing backend alongside Ed25519 and Sigstore keyless.

Scope

• evaluate SLH-DSA parameter sets (Shake128s, Shake256s, etc.) for signature size vs. security tradeoffs
• add SLH-DSA as a signing/verification backend in wsc-lib
• ensure no_std compatibility (the slh-dsa crate supports default-features = false)
• maintain backwards compatibility with existing Ed25519 signatures

References

• FIPS 205 — SLH-DSA
• slh-dsa crate
• portal-co/wasmsign3 — experimental SLH-DSA implementation for Wasm signatures

[avrabe]

Status: deferred — verified upstream dependency blocker

Investigated during the v0.8.x cleanup cycle. The pqc.rs scaffold comment ("pending a stable pure-Rust no_std crate") is confirmed accurate. Here is the precise, evidence-backed blocker so a future revisit doesn't have to re-derive it.

slh-dsa ↔ signature compatibility

slh-dsa version	requires signature	usable in sigil?
0.0.3	^2.2	resolves against the current stack, but it is a 0.0.x crate with no API-stability promise (the crate's version history is non-linear: 0.1.0 → 0.0.3 → 0.2.0-rc)
0.1.0 (max stable)	^2.3.0-pre.4	✗ needs a signature pre-release
0.2.0-rc.5 (newest)	^3.0.0-rc.10	✗ needs signature 3.x

sigil's current stack: signature 2.2 via ecdsa 0.16 / p256 0.13.

Why the RustCrypto bump doesn't land cleanly either

Integrating slh-dsa 0.2.x requires bumping sigil to the signature 3.0 generation. As of 2026-05-19:

• Foundation crates are stable: signature 3.0.0, spki 0.8.0, der 0.8.0, pkcs8 0.11.0, sec1 0.8.1, rfc6979 0.5.0.
• But ecdsa 0.17 and p256 0.14 — the exact crates the keyless Sigstore ECDSA signing path depends on — have no stable release: only ecdsa 0.17.0-rc.18 and p256 0.14.0-rc.9.
• And slh-dsa's only signature 3.x version is 0.2.0-rc.5 — itself a release candidate.

Bumping now would migrate the production Sigstore signing path onto release-candidate crypto — not an acceptable posture for this tool.

Unblock condition

Revisit when both hold:

1. ecdsa 0.17 and p256 0.14 publish stable releases (actively developed — currently rc.18 / rc.9).
2. slh-dsa publishes a release built against stable signature 3.x.

Then: bump the RustCrypto stack (signature 2→3, ecdsa 0.16→0.17, p256 0.13→0.14, spki 0.7→0.8, …) as its own reviewed PR, then add the SLH-DSA keygen/sign/verify backend. The pqc module already carries the parameter-set scaffold (PqcAlgorithm, key/sig sizes, HybridSignature, PqcConfig); only the crypto operations remain.

Keeping this issue open as a roadmap item with the blocker now precisely documented.