PQC-ready is not PQC-verified: ML-DSA downgrade and interoperability failures across two independent software verifiers

Standardization is not the end of assurance. An algorithm can be standardized, shipped, and still have to be replaced or re-verified on short notice, and a hybrid signature can pass its own unit tests and still fail the first independent implementation that receives it. We encountered the second problem while adding ML-DSA-65 to a public offline evidence format: a development signer and verifier using the same JavaScript library agreed with each other, while an independent Python FIPS 204 implementation rejected the signature. That failure changed both our dependency baseline and our working definition of "PQC-ready."

This deep dive presents the resulting reproducible artifact: a signer that covers the same canonical bytes with RSA-4096 and ML-DSA-65, an RFC 9881 SubjectPublicKeyInfo, and independent TypeScript and Python verification paths. The shared public corpus now contains thirteen conformance packages: five accepted packages and eight deliberate rejection controls. A separate six-package downgrade lab is replayed under two relying-party policies by both implementations, producing twenty-four verifier-policy observations with no verdict or first-failure-code mismatch.

The session concentrates on three implementation boundaries.

1. Self-interoperability is not cross-implementation evidence. We show the cross-implementation probe that exposed the dependency-version failure and explain why a positive FIPS 204 vector belongs in continuous integration.
2. ML-DSA key bytes are not yet a deployable certificate interface. We encode id-ml-dsa-65 according to RFC 9881, require absent AlgorithmIdentifier parameters, and retain the earlier raw-key convention only for read compatibility.
3. Downgrade resistance has two layers. Removing the PQC entries from a hybrid package is rejected because a signed witness still names them. A legitimately created classical-only transition package, however, remains acceptable unless the relying party selects an explicit require-pqc policy. Before the result is shown, attendees choose which layer they expect to reject each package.

The announced program addresses interoperability at the level of cryptographic modules and hardware. This session works one layer up, where two independent software verifiers read the same bytes and disagree about them; nothing in the announced program yet puts two independent verifiers on one signature and reports where they part company.

Attendees leave with a concrete test matrix for their own hybrid formats: positive cross-implementation verification, one-bit signature controls, key-encoding checks, structural stripping tests, and an explicit rule for when classical-only evidence must stop being accepted. The code, prepared packages, expected results, and continuous-integration workflow are public under Apache-2.0 at https://github.com/tyche-institute/eatf-verifier/releases/tag/v0.6.1 (opens in a new tab) . This is an interoperability report and research reference implementation, not a product or trust service.