Request for technical feedback on CIRCL-based ML-DSA cross-implementation verification

Hello CIRCL maintainers,

I am looking for narrowly scoped technical feedback on the use of CIRCL as an independent ML-DSA verifier in an open reproducibility project.

I maintain an open verification project called QSP.

Current public Stage391 repository:

https://github.com/mokkunsuzuki-code/stage391

Public verification page:

https://mokkunsuzuki-code.github.io/stage391/

This is not a vulnerability report, certification request, endorsement request, or request for a review of the whole QSP project.

The specific reason I am contacting CIRCL is that QSP Stage387 introduced a second ML-DSA verification implementation using CIRCL in order to reduce dependence on a single verifier implementation.

The relevant design goal was:

same public key
+
same signed target
+
same signature
+
independent ML-DSA implementation
=
cross-implementation verification evidence

Stage387 then carries forward into the independent reproduction and assessment path now exposed by Stage391.

Current Stage391 assessment commit:

a74b7f47f8caabf37a910ea9f4da2b87c0cd5f15

Canonical Stage391 result SHA-256:

ed644d11bd49f67f89cfda50364d619066b4da3a36bf1fb26b38e111b6092b23

Current authoritative state:

third_party_submission_pending

verification_status:

waiting_for_external_submission

No independent external assessment is currently claimed.

My question is intentionally narrow:

Is the way QSP uses CIRCL as an independent ML-DSA verification implementation technically meaningful as cross-implementation evidence?

I would especially value feedback on any of the following:

1. whether the CIRCL verification path is being used correctly,
2. whether the compared ML-DSA inputs are sufficient for meaningful interoperability evidence,
3. whether important FIPS 204 / ML-DSA parameters or encodings are missing from the comparison,
4. whether the test demonstrates verifier independence in a meaningful way,
5. identification of any concrete methodological flaw,
6. or an independent reproduction of the CIRCL-based verification path.

A full review of QSP is not required.

Negative feedback is fully acceptable. A mismatch, incorrect assumption, or methodological criticism would be as valuable as agreement.

The relevant QSP work includes:

- Stage386: public-key binding and evidence portability
- Stage387: ML-DSA multi-implementation interoperability
- Stage390: independent assessment intake
- Stage391: external reproduction adjudication

A self-contained third-party reproduction package is prepared, but I am not attaching it unsolicited.

If a maintainer would like to inspect or reproduce the exact evidence, I can provide the fixed archive and SHA-256 record.

Related external requests:

mldsa-native:
https://github.com/pq-code-package/mldsa-native/issues/1393

PQCA Readiness Tracking WG:
https://github.com/PQCA/wg-readiness-tracking/issues/41

Open Quantum Safe:
https://github.com/orgs/open-quantum-safe/discussions/2533

OpenSSF Supply Chain Integrity:
https://github.com/ossf/wg-supply-chain-integrity/issues/88

Thank you for any technical criticism or direction.

Best regards,
Motohiro Suzuki

Start by reviewing the QSP Stage387 and Stage391 materials, including the CIRCL-based verification path and the cited assessment commit. Compare the public key, signed target, signature, ML-DSA parameters, and encodings against the relevant FIPS 204 requirements; done means providing concrete technical feedback or an independent reproduction addressing the listed questions.

Written by the indexing model from the issue text.