From Public-Key Linting to Operational Post-Quantum X.509 Assurance for ML-KEM and ML-DSA: Registry-Driven Policy, Mutation-Based Evaluation, and Import Validation

Abstract: Final FIPS and PKIX standards for ML-KEM and ML-DSA fix the normative floor, but operational assurance in post-quantum X.509 still depends on accountable checks across certificate-profile semantics, SubjectPublicKeyInfo representation, and private-key-container import. We present a workflow-centric assurance framework for ML-KEM and ML-DSA in the narrow executable profile pkix-core. The framework reifies 17 final-standards requirements into an assurance registry indexed by owner, stage, detector kind, normative strength, and mode-specific action; groups them into three operator gate packs; spans certificate/profile, SPKI/public-key, and private-key-container/import surfaces; and evaluates them through a frozen mutation-based corpus with bounded public-appendix and cross-tool supporting evidence. Across a controlled corpus of 48 artifacts (21 valid, 27 invalid), the artifact detects all expected invalid cases in both strict and deployable modes with zero false positives. Strict blocks all 17 active requirements; deployable preserves the same detection coverage while downgrading exactly one exercised ML-KEM canonicality condition from block to warning. On the importer-owned private-key surface, all 7 active requirements are covered, with 7/7 expected invalid detections and no open detector gaps. On a comparable certificate subset, a frozen JZLint baseline meets 5/10 expected invalid detections and fatally rejects 3 valid ML-KEM certificates, whereas the local artifact meets 10/10 with no fatal valid rejections. A bounded public appendix and a cross-tool matrix further show that parse acceptance and policy conformance diverge materially. Overall, the results support an operational X.509 assurance workflow for CA pre-issuance and private-key import that extends prior PQ public-key linting work.

• The paper introduces a registry-driven operational assurance framework that translates 17 standard-derived requirements into owner- and stage-specific policy actions, validated via mutation-based testing.
• It demonstrates methodological robustness by detecting all invalid artifacts (27/27) with zero false positives, outperforming tools like JZLint in post-quantum certificate evaluation.
• The work highlights the importance of explicit operational accountability by partitioning assurance tasks across CAs and importers to prevent structural and semantic failures in PQ systems.

Operational Post-Quantum X.509 Assurance for ML-KEM and ML-DSA: A Registry-Driven Model

Context and Motivation

The transition to post-quantum (PQ) cryptography at the public key infrastructure (PKI) layer is now defined by finalized standards: FIPS 203 and 204 for ML-KEM/ML-DSA, and RFC 9881/9935 for X.509 PKIX conventions. However, these standards alone are not sufficient for operational assurance—specific semantic and representation failures remain possible even when core cryptographic and encoding requirements are met. There is no standard-defined, operator-accountable workflow for partitioning assurance duties across certification authorities (CAs), artifact importers, and runtime consumers. Consequently, operational failures arise at the certificate-profile, SPKI, and private-key container surfaces, and current public-key linting tools for PQ algorithms offer no reproducible assurance pipeline with attribution to particular owners, stages, and policy actions.

Contribution and Model

This paper defines and implements an operational post-quantum X.509 assurance framework for ML-KEM and ML-DSA. The core novelty is a registry-driven artifact ("pkix-core") that reifies 17 requirements extracted from standards into an assurance registry indexed by owner (e.g., CA, importer), stage (certificate/profile, SPKI/public-key, private-key/import), detector kind, normative strength, and per-mode action (strict, deployable). These requirements are organized into three "gate packs" corresponding to operator-facing assurance bundles, and the workflow is evaluated over a frozen, mutation-based corpus of 48 artifacts with precise coverage diagnostics.

The registry clarifies:

• What requirement is checked, and why,
• At which stage and by whom,
• With what consequence under strict or deployment-oriented (deployable) policy.

A key claim is that assurance must become operationally accountable—not just a collection of lints with ambiguous enforcement.

Technical Architecture

Registry and Policy Model

The assurance registry formalizes 17 requirements split into five certificate/profile, five SPKI/public-key, and seven private-key/import checks. Each requirement is accompanied by normative provenance mapping to its clause in standards documents, operational placement in workflow, evaluation linkage to expected detections and corpus mutations, and explicit policy actions per mode.

• Certificate/profile requirements include positive and negative keyUsage rules, algorithm-specific signature AlgorithmIdentifier semantics, and explicit policy closures (e.g., PKIX exclusion of HashML-DSA).
• SPKI/public-key requirements focus on absent parameters, payload lengths, OID and key agreement, and encode/decode canonicality.
• Private-key/import requirements assure container format/lenghts, seed-expanded consistency, and, for ML-KEM, expanded-key hash relation. The importer-owned surface is explicitly modeled, separating concerns from CA-side pre-issuance gating.

Each requirement—structural, policy, import-crypto—has fully defined mappings to required mode behaviors and supporting evidence in the corpus.

Corpus Design and Evaluation

A deterministic, hash-pinned corpus contains 21 valid, 27 invalid artifacts spanning all surfaces and parameter sets. The mutation families exercise profile and representation failure modes, with detailed provenance.

The framework is evaluated in both strict (all violations block) and deployable (all block except one canonicality warning) modes, with success criteria:

1. All expected invalid artifacts are detected (27/27),
2. No false positives on valid artifacts,
3. Stage-local coverage with no open detector gaps.

Results are robust: all active requirements are fully covered, with zero false positives and tight correspondence between policy metadata and empirical outcomes. Redundant detections are de-duplicated at the requirement level.

Baseline and Cross-Tool Analysis

The paper benchmarks its registry-driven workflow against a frozen snapshot of JZLint (as the most capable prior certificate-level linter). On an apples-to-apples certificate-only comparison, JZLint detects only 5/10 expected invalids and fatally rejects 3 valid ML-KEM certificates. In contrast, the proposed artifact detects all 10/10, with no valid-certificate failures. The cross-tool behavior matrix (local, JZLint, OpenSSL, pkilint) shows substantial divergence between parse acceptance and policy conformance, and highlights runtime fragility of existing tools on modern PQ certificates—especially for ML-KEM.

A bounded public appendix with 26 external artifacts (8 certificates, 18 keys, two providers) further demonstrates external validity and toolchain divergence on real-world samples.

Operator Workflow

The executable assurance workflow is partitioned by gate pack and owner:

• CA must run both certificate/profile and SPKI/public-key gate packs pre-issuance, with clear pass/block/warn outcomes from registry-driven artifacts.
• Importer must run private-key-container/import validation before key use, leveraging a narrow, substrate-anchored bridge (frozen libcrux) for crypto-relevant consistency and hash validation.

All registry data, command lines, and evaluation outputs needed for audit or operation are emitted in machine- and human-readable forms. Strict mode is available for audit/posture replay; deployable is default for low-noise operational use, downgrading only the ML-KEM encode/decode identity check (canonicality) to warning.

Theoretical and Practical Implications

This work demonstrates that the translation from standards to deployable assurance must (a) explicitly model owner-staged boundaries, (b) attribute requirements explicitly in a registry, and (c) bind each requirement to evaluable evidence. It shows that parse acceptance, structural validity, profile conformance, and import fitness are non-equivalent judgments—overloading certificate parsing for all assurance tasks yields fatal gaps. Positive semantics (e.g., mandatory signing bits) and policy closure (e.g., disallowing HashML-DSA) are essential, not just prohibited-bit checks.

Bold claims:

• Certificate-only linting is fundamentally insufficient for ML-KEM and ML-DSA operational assurance, both empirically and architecturally.
• Parse acceptance and policy conformance by existing fielded tools are not congruent; significant classes of structural and semantic invalidities are missed by classical approaches.
• Proper operational assurance for post-quantum X.509 artifact flows is only possible with registry-driven, owner- and stage-assigned workflows.

The method—registry-driven requirement extraction, assignment, and mutation-backed coverage—generalizes across both semantic and representation-layer PQ standards, and can be extended as further artifact families and stages are standardized.

Limitations and Future Directions

• Scope is intentionally limited: ML-KEM, ML-DSA, final PKIX layer, three gate packs, no runtime-consumer coverage.
• Registry's policy actions, and baseline comparisons, are specific to the implemented/frozen artifacts and host environment.
• Public appendix and cross-tool layers are bounded and non-prevalence-supporting.

Future work includes expanding the registry to runtime-consumer boundaries, scaling to broader PQ artifact families and hybrid profiles, and extending policy-matrix expressivity for deployment.

Conclusion

By codifying X.509 PQ artifact assurance as an attributional, registry-driven, mode-aware workflow, this work provides both a rigorous theoretical model and a practical deployment playbook. It fills gaps left by prior PQ linting, certificate-only evaluation, and informal toolchain adaptation. The implication for assurance engineering is clear: post-quantum transition at the PKI layer must move toward reproducible, operator-accountable, and evidence-backed enforcement at each boundary, rather than relying on parse-based or monolithic certificate linters. The approach and toolchain localization set a methodological baseline for the evolving PQ infrastructure landscape.

Reference:

"From Public-Key Linting to Operational Post-Quantum X.509 Assurance for ML-KEM and ML-DSA: Registry-Driven Policy, Mutation-Based Evaluation, and Import Validation" (2604.17003)