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

Resumen Técnico: De la Validación de Claves Públicas a la Garantía Operacional Post-Cuántica en X.509

1. Planteamiento del Problema

Aunque las normas finales FIPS 203/204 (algoritmos) y RFC 9881/9935 (convenios PKIX/X.509) para las criptografías post-cuánticas ML-KEM y ML-DSA han establecido un "piso normativo" definitivo, esto no garantiza por sí solo la garantía operativa en despliegues reales.

El problema central identificado es que las normas especifican la forma de los algoritmos y artefactos, pero no asignan responsabilidades de ejecución, ni definen cómo deben propagarse las violaciones en un flujo de trabajo operativo. Se han detectado fallos en tres superficies críticas que van más allá de la simple sintaxis:

1. Superficie de Certificado/Perfil: Semántica PKIX (ej. uso de keyUsage, prohibición de HashML-DSA).
2. Superficie SPKI/Clave Pública: Representación de la clave, longitudes exactas, parámetros ausentes y condiciones de canonicidad.
3. Superficie de Contenedor/Importación de Clave Privada: Validación de la consistencia entre la semilla y la clave expandida, formatos de contenedor y longitudes internas.

Las herramientas actuales de "linting" (validación estática) de claves públicas son insuficientes porque no distinguen quién es el responsable (Autoridad Certificadora vs. Importador), en qué etapa se debe verificar, ni cómo actuar bajo diferentes políticas de despliegue.

2. Metodología y Enfoque

El artículo propone un marco de trabajo llamado pkix-core, un perfil ejecutable y estrecho diseñado para ML-KEM y ML-DSA. La metodología se basa en los siguientes pilares:

• Modelo de Garantía Operacional: Se traduce el texto normativo en un registro de requisitos (registry) donde cada requisito se asigna a un propietario (CA pre-emisión o importador de artefactos) y una etapa específica.
• Paquetes de Puerta (Gate Packs): Los requisitos se agrupan en tres paquetes operativos:
  1. ca-certificate-profile (5 requisitos).
  2. ca-spki-public-key (5 requisitos).
  3. import-private-key (7 requisitos).
• Modos de Política: El sistema opera en dos modos:
  • Strict (Estricto): Bloquea cualquier violación de los 17 requisitos activos.
  • Deployable (Desplegable): Mantiene la misma cobertura de detección, pero degrada ciertas condiciones (específicamente una condición de canonicidad de ML-KEM) de "bloqueo" a "advertencia" para reducir el ruido en entornos de producción sin perder la evidencia subyacente.
• Evaluación Basada en Mutaciones: Se utiliza un corpus congelado de 48 artefactos (21 válidos y 27 inválidos) generados mediante mutaciones deterministas. Esto permite probar la detección de fallos específicos sin depender de herramientas externas no controladas.
• Validación de Importación: Se integra un puente de validación estrecho basado en una instantánea congelada de libcrux para verificar la consistencia semántica de las claves privadas (semilla vs. clave expandida), algo que el análisis de certificados por sí solo no puede hacer.

3. Contribuciones Clave

1. Modelo de Garantía Operacional: Definición de un flujo de trabajo para ML-KEM y ML-DSA organizado por propietario y etapa, en lugar de una simple lista de validaciones.
2. Artefacto de Política Basado en Registro: Implementación de 17 requisitos activos distribuidos en tres superficies de artefactos y tres paquetes de puertas, con semántica explícita para los modos strict y deployable.
3. Evaluación Controlada: Demostración de detección completa de artefactos inválidos esperados (27/27) con cero falsos positivos en el conjunto de datos válidos (21/21).
4. Validación de Claves Privadas como Superficie de Primer Nivel: Extensión de la garantía más allá del material del certificado para incluir la validación de contenedores de claves privadas, cubriendo los 7 requisitos propiedad del importador.
5. Evidencia Disciplinada: Comparación con una línea base congelada (JZLint) y un apéndice público acotado, demostrando que la aceptación del análisis sintáctico (parse) no equivale a la conformidad con la política.

4. Resultados Principales

• Cobertura de Detección: El artefacto local detectó el 100% de los artefactos inválidos esperados en ambos modos.
• Falsos Positivos: No se registraron falsos positivos en los 21 artefactos válidos.
• Comparación con la Línea Base (JZLint):
  • En una comparación justa (solo certificados), la línea base congelada detectó solo 5 de 10 casos inválidos esperados.
  • La línea base rechazó fatalmente 3 certificados válidos de ML-KEM (fragilidad en tiempo de ejecución), mientras que el artefacto local no rechazó ninguno.
  • La línea base falló en capturar semánticas positivas (ej. exigir al menos un bit de firma en ML-DSA) y se centró principalmente en la prohibición de bits incorrectos.
• Divergencia Parse vs. Política: La matriz de herramientas cruzadas (57 artefactos) mostró que herramientas como OpenSSL pueden aceptar artefactos estructuralmente válidos que violan políticas de perfil, evidenciando la necesidad de un flujo de trabajo de garantía específico.
• Validación de Importación: Se lograron las 7/7 detecciones esperadas en la superficie de claves privadas, incluyendo consistencia de semillas y hashes de claves expandidas.

5. Significado e Impacto

El trabajo demuestra que la seguridad post-cuántica en X.509 no se resuelve simplemente con la aceptación de la sintaxis o con herramientas de linting aisladas. La contribución fundamental es metodológica: ofrece un patrón reproducible para convertir el texto de normas finales en decisiones operativas asignables, auditables y rejugables.

• Para las Autoridades Certificadoras (CA): Proporciona una receta operativa clara para las puertas de pre-emisión, asegurando que los certificados cumplan con la semántica PKIX correcta antes de ser emitidos.
• Para los Importadores: Establece un mecanismo para validar la integridad interna de las claves privadas antes de su importación, previniendo fallos que surgirían en tiempo de ejecución.
• Para la Industria: El marco pkix-core y sus resultados sugieren que la garantía operativa requiere separar la detección de defectos de la acción política (bloqueo vs. advertencia) y asignar responsabilidades claras a lo largo de la cadena de suministro de criptografía.

En conclusión, el artículo cierra la brecha entre las normas teóricas finales y la implementación práctica, demostrando que la garantía post-cuántica requiere un flujo de trabajo gestionado por políticas, no solo validadores de sintaxis.