Back to Paper
cs.CR
Local ID: 2604.17003v2
AI Summary: gemma4:e4b
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
By José Luis Delgado Jiménez
Revision History Timeline
v14/18/2026
4/18/2026
“48 pages, 13 figures, 32 tables, 6 appendices; includes artifact, reproducibility, and cross-tool evaluation appendices”
v25/19/2026
5/19/2026
“48 pages, 13 figures, 32 tables, 6 appendices. Includes artifact, reproducibility, and cross-tool evaluation appendices”
★ Version indexed in ExplorerComparing v1 vs v2
Green = Added • Red = Removed
Title Comparison
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
Authors Comparison
No author changes.
v1 Comment
“48 pages, 13 figures, 32 tables, 6 appendices; includes artifact, reproducibility, and cross-tool evaluation appendices”
v2 Comment
“48 pages, 13 figures, 32 tables, 6 appendices. Includes artifact, reproducibility, and cross-tool evaluation appendices”
Abstract Word Diff
Final FIPS and PKIX standards for ML-KEM and ML-DSA fixsettle the normative floor, butyet operationalthey assurancedo innot by themselves provide assurance. In practical post-quantum X.509 still dependsdeployments, onfailures accountablestill checksemerge acrossat certificate-profile semantics, SubjectPublicKeyInfo representation, and private-key-containerprivate-key import.container import, while current PQ public-key linting does not yet provide a reproducible workflow that says which checks belong to the certification authority, which belong to the artifact importer, and how those checks should act under deployment-facing policy. We present aan workflow-centricoperational post-quantum X.509 assurance framework for ML-KEM and ML-DSA in thea narrow executable profileprofile, 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; groupspackages themthose requirements 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 withbacked by bounded public-appendix and cross-tool supporting evidence. Across a controlled corpus of 48 artifactsartifacts, (21comprising valid,21 valid and 27 invalid),invalid cases, the artifact detects all expected invalid casesartifacts in both strict and deployable modes with zero false positives. Strict blocks all 17 active requirements; deployable preserves the same underlying 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.