Re: Call for Co-Editors: Post-Quantum Migration Pattern for Verifiable Credentials (Ed25519 + ML-DSA Dual-Signature Model)

Thanks Amir — your framing of crypto-agility as the primary design objective
  rather than algorithm choice resonates with what we've hit in production.

  To answer your direct question: the constraint I've come to prioritize is
  canonical-byte stability across the system's lifecycle. Signature size
  matters in log-based contexts (per Stephen's numbers); verification
  throughput matters at scale; algorithm agility matters across migration.
  But all three depend on a substrate where the serialized bytes the
verifier
  reconstructs equal the serialized bytes the issuer signed, indefinitely.
  That's the constraint that most-often breaks long-lived systems in subtle
  ways — JSON-LD canonicalization edge cases, float-roundtrip surprises,
  library-version drift, locale-dependent serialization.

  We hit this concretely in our own VC implementation last week: a `.0`
  trailing on a whole-number float survived issuance but was dropped on
  browser-side reconstruction during verification, invalidating the
  signature. The fix was structural (remove float fields from the signed
  subject) and we formalized the resulting invariant as a kernel-checked
  Lean theorem (`canonical_bytes_stable_under_roundtrip`). Trivial in
  isolation, but a class of bug that stays invisible until production.

  For the dual-signature pattern under discussion, the canonical-bytes
  question gets interesting: do both signatures commit to the same canonical
  form, or to algorithm-specific canonicalizations? If the same, what's the
  conformance test that catches divergence? If different, what's the
  migration verifier's reconciliation logic when a credential carries both?

  To share the Falcon-512 numbers I offered, from paraxiom-pqc v0.1.2
  (pure-Rust, zero-C dependency):

    Public key:           897 bytes (Falcon-512) vs 1312 bytes (ML-DSA-44)
    Signature (typical):  666 bytes (Falcon-512) vs 2420 bytes (ML-DSA-44)

  On performance: Falcon signing is meaningfully slower (~3–4×) due to the
  Gaussian sampler, and harder to make constant-time — a real concern for
  any signer in a hostile context. Verification latency is broadly
  comparable. Caveats from my earlier note stand (Falcon's weaker BUFF
  properties matter for long-lived logs).

  Happy to contribute review cycles or pattern documentation to the proposed
  work item. The canonical-bytes invariant is the constraint I'd most want
  to see captured in any migration pattern — it's where the operational pain
  lands, regardless of which PQC primitive ends up dominant.

  — Sylvain Cormier, Paraxiom Technologies Inc.

On Tue, Jun 16, 2026 at 8:16 AM Amir Hameed <amsaalegal@gmail.com> wrote:

> Thanks Stephen and Sylvain for sharing these numbers and perspectives.
>
> I think these kinds of implementation experiments are incredibly valuable
> because they give us something concrete to reason about instead of relying
> on assumptions. They expose the engineering constraints that eventually
> shape good cryptographic systems.
>
> Sylvain also makes an important point—the observed overhead is a property
> of one PQC candidate, not necessarily PQC itself. That is exactly why
> benchmarking different approaches matters.
>
> One thing I've always found interesting is that constraints usually lead
> to innovation and optimization. Instead of searching for a single perfect
> algorithm, perhaps the better objective is to design migration patterns
> that are inherently crypto-agile and allow communities to mix and match
> primitives while understanding the tradeoffs. Signature size, verification
> performance, storage growth, implementation complexity, interoperability,
> deployment costs—all of these become part of the design space.
>
> For me, ML-DSA here is simply one data point. The more interesting
> question is how we design migration patterns that remain flexible enough to
> accommodate today's choices and tomorrow's improvements without forcing
> disruptive ecosystem changes.
>
> I'm curious how others are approaching this. If you were designing a
> long-lived cryptographic system today, what operational constraints would
> you optimize for first? Signature size? Verification throughput? Storage
> growth? Implementation simplicity? Algorithm agility? Or is there another
> metric that deserves more attention than we typically give it?
>
> I suspect collecting experiences from different protocols and deployments
> could help us identify common patterns and perhaps arrive at migration
> strategies that serve the broader cryptographic community rather than any
> particular algorithm.
>
> --Amir Hameed Mir
>
> On Sun, 14 Jun 2026 at 11:53, sylvain cormier <sylvain@paraxiom.org>
> wrote:
>
>> Good data point, Stephen — One thing worth flagging so the 10x doesn't
>> get read as "the PQC cost" in general: that size/perf hit is largely an
>> ML-DSA-44 characteristic. Among the NIST signatures, ML-DSA-44 is on the
>> heavy end for size — Falcon-512 signatures are roughly 3.6x smaller (~666
>> vs ~2420 bytes), which for a log-based method like did:webvh would
>> meaningfully cut the per-entry and resolution overhead you measured. It's a
>> genuine tradeoff, not a free win — Falcon has trickier (floating-point,
>> constant-time) signing and some weaker BUFF properties (exclusive ownership
>> / non-resignability) that matter in a long-lived log context. But for
>> size-sensitive logs it's probably worth benchmarking alongside ML-DSA-44
>> before the spec settles on the PQC profile. Happy to share Falcon-512
>> numbers if useful.
>>
>> — Sylvain Cormier, Paraxiom Technologies Inc.
>>
>> On Sun, Jun 14, 2026 at 2:41 PM Stephen Curran <swcurran@cloudcompass.ca>
>> wrote:
>>
>>> As Jori mentioned, Log based verification methods provide a nice way to
>>> evolve to PQC.  We've been experimenting with the did:webvh DID Method
>>> (did:web + verifiable history -- https://didwebvh.info) to include PQC
>>> to secure a did:webvh Log and have found some interesting performance
>>> numbers (below).
>>>
>>> For background, did:webvh uses a combination of mechanisms for the
>>> needed crypto-agility in securing the DID Log:
>>>
>>>    - multikey to make sure that the verifier can determine the type of
>>>    key used (and multihash for hash)
>>>    - identification in the log of the version of the did:webvh spec in
>>>    use, including the ability to increase the spec version in any log entry
>>>    - dictating in each spec version the permitted hashing algorithms
>>>    and Data Integrity cryptosuites so the verifier knows exactly what
>>>    algorithms must be used to secure the DID Log.
>>>       - Note -- this only constrains the algorithms/key types used to *secure
>>>       the did:webvh DID Log itself *- not the verification methods
>>>       included in the secured DIDDoc. The DID Controller is free to use ANY
>>>       cryptographic key types in the DIDDoc itself. did:webvh does not put any
>>>       constraints on the DIDDoc contents.
>>>       - Currently (spec version 1.0) permits only eddsa-jcs-2022. The
>>>       next version of the spec will most likely add the stabilized ML-DSA-44
>>>       cryptosuite. Per NIST -- ML-DSA-44 is the logical PQC successor to EDDSA.
>>>    - the 1.0 spec also allows for the use of "pre-rotation" for the
>>>    securing key -- committing to the hash of the public key to be used to sign
>>>    the next log entry. When pre-rotation is in use, key rotation is required
>>>    for every entry, meaning the public key is only published on use, and never
>>>    reused -- a PQ protection in and of itself. We expect that pre-rotation
>>>    will be required in the next version of the did:webvh spec. Inspired by
>>>    KERI's pre-rotation approach.
>>>
>>> Given that, the only (experimental) change we had to make was to pretend
>>> that the v1.0 spec included ML-DSA-44, and add ML-DSA-44  cryptosuite
>>> (mldsa44-jcs-2024) support for creating and resolving the DID.  We then
>>> used the benchmark of the generation of a "10 year" DID, one that is
>>> rotated monthly (120 rotations -- no witnesses).  In comparing the EDDSA
>>> and ML-DSA performance, we have found on the same machine about 10x slower
>>> in adding a log entry (56ms to 510ms), 10x slower in resolution of the last
>>> entry (460ms to 4677ms), and had a 10x (~ increase in log file size (117kb
>>> to 1.07MB).  Those numbers were for the Rust implementation, but the
>>> TypeScript implementation performance ratios were about the same.
>>>
>>> Note that this was a quick experiment, but even that has led to
>>> interesting discussions/approach changes on how to evolve the
>>> specification. +1 to using these types of experiments to understand and
>>> account for the practical impacts of the transition -- and to use them to
>>> guide updates to specifications.
>>>
>>> The basing of did:webvh for securing the DID Log on Data Integrity
>>> cryptosuites made the necessary changes very easy -- basically, changing
>>> only the signature generation and verification. Everything else (JCS
>>> processing, proof preparation, etc.) stayed the same. OK, we also had to
>>> ease the restrictions on the permitted cryptosuites... :-)
>>>
>>> --
>>>
>>> Stephen Curran
>>> Principal, Cloud Compass Computing, Inc.
>>>
>>
>>
>> --
>>                           Sylvain Cormier - Founder
>> Paraxiom Technologies inc.
>> https://paraxiom.org
>> 514 804 8434
>>
>>
>>

-- 
                          Sylvain Cormier - Founder
Paraxiom Technologies inc.
https://paraxiom.org
514 804 8434