PQ X.509 Assurance: Why Parse-Time Validation Fails ML-KEM

• A frozen JZLint baseline detects only 5 of 10 expected invalid ML-KEM certificates while fatally rejecting 3 valid ones — a double failure mode that breaks CA pre-issuance workflows (arXiv:2604.17003v1)
• A registry-driven framework reifying 17 final-standards requirements achieves 10/10 invalid detection with zero false positives across 48 controlled artifacts
• Parse acceptance and policy conformance diverge materially — enterprises deploying PQC certificates need operational assurance, not just syntactic validation

The Gap Between “Parses” and “Conforms” Is Breaking PQC Deployments

A Certificate Authority prepares to issue its first ML-KEM-768 certificate. The artifact parses cleanly. JZLint — the industry reference for X.509 linting — returns fatal. The certificate is valid. The lint is wrong.

Now flip the scenario. A malformed ML-DSA certificate with non-canonical SPKI encoding sails through the same linter. It parses. It lints clean. It ships.

This is the operational reality documented in arXiv:2604.17003v1: existing PQC linting tooling exhibits contradictory failure modes — over-rejecting valid certificates while under-detecting invalid ones. On a controlled corpus of 48 mutation-derived artifacts, the JZLint baseline caught 5 of 10 expected invalid cases and fatally rejected 3 of 21 valid ones.

For CISOs running certificate issuance pipelines, this is a dual-sided liability. Your pre-issuance gate either blocks compliant customers or ships non-conformant artifacts into your PKI. Both outcomes create incident response work.

The root cause: public-key linting tools were designed around RSA and ECDSA primitives with decades of accumulated edge-case coverage. introduces new surfaces — SubjectPublicKeyInfo encoding rules for lattice-based keys, private-key container import semantics, canonicality conditions on ML-KEM ciphertext encodings — that inherited tooling does not meaningfully cover.

What Registry-Driven PQ X.509 Assurance Actually Means

Registry-driven assurance is the practice of reifying every normative requirement from a cryptographic standard into a machine-readable catalog, then indexing each entry by owner (who enforces it), stage (when in the lifecycle it applies), detector kind (what mechanism finds violations), normative strength (MUST/SHOULD/MAY), and mode-specific action (block vs. warn). The framework described in arXiv:2604.17003v1 applies this approach to the final FIPS standards for ML-KEM and ML-DSA combined with PKIX profile rules.

Seventeen final-standards requirements were extracted and grouped into three operator gate packs, spanning three distinct surfaces:

The import-validation surface is the novel contribution. Traditional X.509 linting stops at the certificate boundary. But failures frequently occur when private-key containers are imported into HSMs or software keystores — and no existing PQC tool evaluates this path.

Inside the Evaluation: Mutation Corpus and Mode Semantics

The authors built a frozen mutation-based corpus: 48 artifacts, 21 valid and 27 invalid. Mutations were derived from structural and semantic deviations from the FIPS/PKIX normative floor — not random fuzzing, but targeted perturbations corresponding to specific requirement violations.

Two enforcement modes were tested:

The deployable mode downgrades exactly one exercised ML-KEM canonicality condition from block to warning. Detection coverage is preserved. This matters for rollout: strict mode is the target end-state, but deployable mode gives operations teams a path through the transition period without generating spurious incidents.

On the importer-owned private-key surface, all 7 active requirements are covered and the artifact achieves 7/7 expected invalid detections. JZLint, by design, does not evaluate this surface at all. (arXiv:2604.17003v1)

The JZLint Comparison: Two Failure Modes, One Root Cause

The cross-tool matrix produces a finding enterprise architects should not ignore:

JZLint simultaneously under-detects and over-rejects. This is not a calibration problem. It is a coverage problem: the tool’s rule set was not derived from the final ML-KEM and ML-DSA standards but from earlier drafts and RSA/ECDSA analogues. The authors frame the result as evidence that parse acceptance and policy conformance diverge materially — a certificate passing parse-time validation tells you nothing about whether it conforms to the normative floor.

Regulatory and Market Context

NIST finalized FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) in August 2024. The CNSA 2.0 timeline requires national security systems to support these algorithms in software/firmware signing by 2025 and prefer them by 2030. Commercial CAs are already issuing PQC test certificates; browsers and TLS libraries are prototyping hybrid key exchange.

The economic asymmetry is sharp. Re-issuing a non-conformant PQC certificate after relying-party rejection costs operational hours and erodes customer trust. Blocking valid certificates at pre-issuance because of a broken linter generates support tickets at scale. The cost of rebuilding a linting pipeline around a registry-driven framework is bounded and one-time. The cost of shipping without one compounds with every certificate issued.

will determine which CAs remain trust-anchored through 2030.

The BeQuantum Perspective: Assurance as a Workflow, Not an Artifact

The registry-driven model aligns with how BeQuantum’s PQC Layer approaches certificate governance. Validation is not a single gate — it is a sequence of stage-indexed checks: pre-issuance policy conformance, SPKI canonicality at publication, import validation at keystore ingress, and continuous re-evaluation as the normative floor shifts.

The Digital Notary component anchors each assurance decision with blockchain-verifiable attestation, producing an audit trail that survives the certificate itself. When a requirement’s normative strength changes — for example, if a SHOULD is promoted to a MUST in a future FIPS revision — the registry update propagates into the gate pack without re-engineering the pipeline.

The takeaway is architectural: organizations treating PQC linting as a drop-in replacement for RSA linting will inherit the JZLint failure profile. Organizations treating assurance as a registry-driven workflow spanning certificate, SPKI, and import surfaces will not.

What You Should Do Next

1. Within 30 days, audit your CA pre-issuance pipeline for PQC readiness. Identify which linting tool gates ML-KEM and ML-DSA issuance today. If it is JZLint or a derivative frozen against pre-final drafts, assume the dual failure mode above applies to your pipeline.

2. Within 90 days, add private-key import validation to your keystore ingress. This surface is not covered by any public linting tool. Even a minimal seven-requirement gate pack derived from the final FIPS standards closes the largest unguarded PQC attack surface in most enterprise PKIs.

3. Before your first production PQC certificate issuance, run a mutation corpus against your validation stack. Mutation-based testing catches the specific class of defects — non-canonical SPKI, malformed algorithm identifiers, private-key container parsing errors — that parse-time validation misses by construction.

FAQ

Q: Can we rely on parse-time validation for ML-KEM and ML-DSA certificates if the parser is updated for PQC?

A: No. The arXiv:2604.17003v1 evidence shows parse acceptance and policy conformance diverge materially. A parser confirms the bytes decode into a structure; it does not confirm the structure satisfies the 17 final-standards requirements. Policy conformance requires an explicit registry-driven gate.

Q: Why does the deployable mode downgrade a canonicality condition to a warning?

A: Operational rollout requires a path where detection coverage is preserved but one specific ML-KEM canonicality condition does not generate a hard block. This avoids disrupting active traffic during transition while still surfacing the violation in logs for remediation. Detection is unchanged — only the enforcement action differs.

Q: Is JZLint unusable for PQC?

A: JZLint remains useful within its actual coverage — RSA and ECDSA profiles where its rule set is mature. For ML-KEM and ML-DSA, the frozen baseline produces both false positives on valid certificates and false negatives on invalid ones. Treat it as a starting point, not a pre-issuance gate.

Last updated: 2026-04-22. Primary source: From Public-Key Linting to Operational Post-Quantum X.509 Assurance (arXiv:2604.17003v1).