Resumen

  • El RFC 9802 normaliza identificadores y codificaciones de HSS, XMSS y XMSSMT para certificados y CRL X.509, pero no incluye el historial de índices de firma ya consumidos.
  • Verificar una firma demuestra una relación matemática con la clave pública. No demuestra que una copia antigua, otro dispositivo o una restauración no hayan reutilizado el mismo componente de un solo uso.

La restauración que volvió a abrir el pasado

El lunes, una autoridad guarda una imagen de su equipo de firma con el índice siguiente en 41.200. Durante la semana, el dispositivo principal emite certificados y listas de revocación hasta 41.259. El viernes, una avería lleva al equipo de continuidad a restaurar la imagen del lunes. El equipo recuperado firma un objeto distinto usando 41.200.

La clave pública coincide y el objeto X.509 está bien formado. La firma antigua y la nueva pueden superar una prueba aislada. Sin embargo, dos mensajes distintos han empleado la misma clave OTS. El RFC 9802 advierte que esa pareja puede volver computacionalmente viable la falsificación.

El documento, publicado como estándar de la IETF en junio de 2025, resuelve una tarea real: asigna OID y formatos ASN.1 a HSS, XMSS y XMSSMT en la PKI de Internet; define la representación de claves y firmas para certificados y CRL y limita los bits de Key Usage. El registro oficial y el historial del IETF delimitan esa obra.

Pero un identificador responde qué lógica debe interpretar unos bytes. No responde cuántas copias del estado existieron ni qué índices consumió cada una.

La cronología forma parte de la clave

En una firma sin estado, la continuidad suele reducirse a conservar el secreto. En HSS y XMSS hay que conservar además una secuencia que no retrocede. El RFC 8554 exige que una clave LM-OTS firme como máximo un mensaje; HSS agrupa muchas de esas claves en niveles. El RFC 8391 construye XMSS y XMSSMT con WOTS+, árboles de Merkle y direcciones que distinguen los componentes.

El presupuesto puede alcanzar cifras enormes, pero sigue siendo finito. Más importante: cada posición debe tener un único destino. La unidad recuperable no es sólo el material secreto. Incluye el próximo índice confirmado, las reservas, las firmas liberadas, los índices quemados y la época de recuperación. Restaurar sólo una parte devuelve una identidad criptográfica con memoria incompleta.

NIST SP 800-208 recomienda LMS/HSS y XMSS/XMSSMT bajo restricciones operativas y módulos criptográficos de hardware. El RFC 9802 incorpora esa disciplina y propone llevar un registro de firmas o índices, consultarlo antes de liberar una firma, reservar estados futuros y mantener un volumen que pueda auditarse. Si se descubre reutilización, la respuesta incluye congelar nuevas firmas, revisar las anteriores y valorar la revocación.

Estas son funciones de operación. Un certificado no reserva índices, no cerca a un dispositivo secundario y no arbitra qué copia puede volver a funcionar.

La alta disponibilidad no puede clonar el contador

Duplicar una clave sin estado en dos módulos protegidos puede ser una solución de disponibilidad. En un esquema con estado, dos copias con el mismo punto de partida son dos posibles propietarios del mismo futuro. El RFC 9802 señala que las técnicas corrientes de copia y restauración producirán reutilización OTS con alta probabilidad si no conservan correctamente el estado.

El retroceso abre posiciones gastadas después de la instantánea. La división activa permite que dos equipos avancen en paralelo. La ambigüedad de entrega crea una tercera vía: el firmante consume y persiste un índice, genera la firma y pierde la respuesta; otro sistema repite el trabajo. Que nadie haya confirmado la recepción no demuestra que el índice continúe disponible.

Una arquitectura segura puede usar una sola autoridad de estado, rangos disjuntos reservados de forma irreversible, contadores monotónicos de hardware o una ceremonia de restauración que sitúe el primer índice nuevo por encima de todo rango histórico. Son decisiones locales. La prohibición de volver al pasado es el mínimo común.

Siete recibos, no uno

El RFC 5280 establece la validación de rutas de certificación, restricciones, usos y CRL. Con el RFC 9802, un verificador puede reconocer estos algoritmos y decidir si la firma corresponde a la clave presentada.

Esa prueba no enumera dispositivos paralelos, fotografías de almacenamiento, reservas abandonadas ni salidas que nunca llegaron a este verificador. Tampoco prueba que el presupuesto cubra toda la vida del certificado. Conviene separar: formato interpretable; firma válida; ruta y revocación aceptadas; índice reservado una sola vez; consumo persistido; ausencia de otra copia capaz de usarlo; resultado final de la aplicación.

La PKI observa sobre todo los tres primeros. El operador debe aportar los siguientes. El usuario de la firma decide el último.

La idea de primacía del código en ejecución de Lu Heng impide que la publicación del OID sustituya a la realidad del firmante. La especificación mínima con decisiones futuras localizadas separa la sintaxis común de las elecciones operativas sobre estado y recuperación. La tesis de BTW.Media como capa de realidad obliga a mostrar esa maquinaria invisible en vez de usar el sello verde de validación como conclusión universal.

Fuentes