Firmas poscuánticas y certificados TLS públicos: comprobaciones de preparación independientes

Qué es

Estado al 25 de octubre de 2026. NIST publicó FIPS 204, que especifica ML-DSA, y FIPS 205, que especifica SLH-DSA, el 13 de agosto de 2024. Son estándares de firma digital. Volver a consultar las erratas de NIST, el estado de publicación en el IETF y los requisitos aplicables del CA/Browser Forum antes de planificar cambios de certificados. La página de FIPS 204 incluye una nota de planificación del 31 de julio de 2026 sobre problemas menores que se prevé corregir en el futuro.

La estandarización del algoritmo, la codificación del certificado, la autenticación TLS y la aceptación en los sistemas de confianza pública son hitos independientes. Un intercambio de claves poscuántico no convierte la clave pública de un certificado existente ni la firma de su emisor en una firma poscuántica.

Por qué importa

Ya existe un estándar de integración con X.509: RFC 9881, publicado en octubre de 2025, define las convenciones de ML-DSA para certificados y listas de revocación de certificados. Abarca la variante pura de ML-DSA y excluye HashML-DSA de ese perfil. Por tanto, sería incorrecto afirmar que todo el trabajo sobre certificados ML-DSA sigue siendo una propuesta sin publicar.

La integración con TLS tiene su propio estado. El sistema de seguimiento del IETF muestra draft-ietf-tls-mldsa-06, fechado el 11 de septiembre de 2026, como trabajo en curso en la cola del RFC Editor; el registro de seguimiento se actualizó por última vez el 12 de octubre de 2026. Esto no equivale a un RFC de TLS ya publicado.

Para los certificados TLS convencionales de confianza pública, los Baseline Requirements del CA/Browser Forum, versión 2.3.1 del 4 de octubre de 2026, siguen restringiendo las codificaciones pertinentes a algoritmos clásicos. La sección 7.1.3.1 permite claves públicas RSA y ECDSA del sujeto del certificado, y la sección 7.1.3.2 especifica codificaciones de firmas clásicas. Ninguna de las dos secciones proporciona un perfil de emisión para ML-DSA o SLH-DSA. Esto explica que se sigan exigiendo certificados clásicos dentro de ese marco; no es un estudio de todas las CA, los sistemas experimentales de confianza o las PKI privadas.

Cómo aplicarlo

• Registrar por separado el acuerdo de claves, la clave pública del sujeto del certificado, la firma del emisor y la autenticación durante la negociación. Exigir pruebas para cada afirmación en lugar de aceptar una única etiqueta poscuántica para toda la conexión.
• Para un experimento con certificados ML-DSA, identificar la variante exacta del algoritmo y el perfil de certificado. RFC 9881 proporciona la base de codificación; por sí solo no acredita la aceptación por un programa público de certificados raíz ni por todos los clientes.
• Antes de un despliegue público, consultar los TLS Baseline Requirements vigentes, la política de la CA correspondiente y las políticas de confianza de los clientes previstos. Seguir los cambios de algoritmos aprobados y sus fechas de entrada en vigor. Un borrador o la mera asignación de un identificador de algoritmo no demuestran que esté listo para desplegarse.
• Mantener las pruebas con PKI privadas separadas de los supuestos sobre emisión pública. Registrar los resultados de validación de cadenas, autenticación, renovación, revocación e interoperabilidad del software concreto utilizado. Los TLS Baseline Requirements públicos excluyen expresamente de su ámbito las PKI empresariales de uso exclusivamente interno.
• Seguir las correcciones de FIPS 204, la página de publicación de FIPS 205, las erratas de los RFC y el estado de los documentos del grupo de trabajo de TLS. Actualizar el inventario cuando cambie el comportamiento desplegado, no solo cuando se anuncie una especificación.

Trampas

No deducir el soporte de firmas a partir del soporte de intercambio de claves ni tratar la lista de algoritmos de una biblioteca como prueba de confianza por parte de los navegadores. Del mismo modo, la estandarización de SLH-DSA por NIST no establece un perfil de certificado TLS público. Aquí no se afirma que exista una fecha universal de despliegue en navegadores, un plazo de migración para las CA ni una determinada cobertura de despliegues experimentales. Eso requiere pruebas primarias actuales e independientes.