Summary

  • RFC 9909 asigna OID distintos a Pure SLH-DSA y HashSLH-DSA y prohíbe cruzar el modo identificado por la clave con el de la firma, aunque el cálculo pudiera construirse.
  • El resultado operativo exige conservar el objeto exacto: parámetros ausentes, bytes sin envoltura adicional, keyUsage de firma y decisiones separadas de criptografía, ruta de certificación y política.

Una autoridad certificadora prepara su siguiente raíz y deja una casilla para decidir más tarde: “Pure o pre-hash, según el HSM”. Esa casilla no es compatible con RFC 9909. Al emitir el certificado de la CA, el identificador de la clave ya compromete el modo que podrán usar sus firmas.

El caso es analítico, no un despliegue ni un incidente. Sirve para ver por qué “soporta SLH-DSA” es una declaración insuficiente. Si SubjectPublicKeyInfo lleva un OID Pure y la firma se identifica como HashSLH-DSA, el perfil no permite usar esa clave para verificarla. Si los OID coinciden pero AlgorithmIdentifier contiene NULL, tampoco se ha cumplido la regla: parameters debe estar ausente.

RFC 9909 fue publicado en diciembre de 2025 como Standards Track del IETF por el grupo LAMPS. Lleva a certificados, CRL, claves públicas y paquetes de clave privada X.509 el algoritmo de firma hash-based sin estado definido por FIPS 205. El nombre SPHINCS+ pertenece a la etapa previa; el propio RFC advierte que no es compatible con SLH-DSA. Migrar etiquetas no migra objetos.

Hay doce identificadores Pure y doce HashSLH-DSA. Cada familia distingue nivel de seguridad de 128, 192 o 256 bits, variante small o fast y función interna SHA-2 o SHAKE. En el modo pre-hash, el OID también expresa la función de preprocesamiento. El CSOR de NIST mantiene esas asignaciones.

La propiedad decisiva no es la cantidad de nombres, sino su jurisdicción. El mismo OID identifica la clave pública, la privada y el algoritmo de firma. Por eso RFC 9909 dice que una clave marcada Pure no está autorizada para generar o verificar una firma Hash, ni al contrario, aun cuando matemáticamente fuera posible. El identificador fija una interpretación interoperable y elimina la negociación implícita.

Esta rigidez protege la evidencia. Un inventario que guarda sólo SLH-DSA pierde el modo, el nivel, small/fast, SHA-2/SHAKE y, en HashSLH-DSA, la función de pre-hash. Cuando dos validadores divergen, ese campo resumido no permite reconstruir la causa. Hay que capturar los OID de la clave y de la firma tal como aparecen en el DER.

También hay que registrar algo que no está. RFC 9909 exige que el componente parameters esté ausente para todos estos identificadores. Un NULL codificado ocupa bytes y tiene presencia semántica. Las bibliotecas acostumbradas a perfiles RSA antiguos pueden tolerarlo o generarlo. Que una pila lo acepte no convierte el objeto en portable; sólo documenta una extensión local del contrato.

La clave pública contiene PK.seed || PK.root, con longitud 2*n y n de 16, 24 o 32 bytes. En SubjectPublicKeyInfo esos octetos entran directamente en el BIT STRING, sin otra capa ASN.1. La privada contiene SK.seed || SK.prf || PK.seed || PK.root, 4*n bytes, dentro del OCTET STRING de OneAsymmetricKey.

OneAsymmetricKey puede incluir además la clave pública. El dato facilita una comprobación de consistencia, pero RFC 9909 señala que ciertas funciones de importación aún rechazan esa variante. No existe una respuesta universal entre más comprobación local y mayor compatibilidad de importación. El operador debe ensayar su ruta completa: generador, exportación, custodia, restauración y uso.

keyUsage aporta otra separación. Si la extensión aparece, debe contener al menos digitalSignature, nonRepudiation, keyCertSign o cRLSign. No puede contener keyEncipherment, dataEncipherment, keyAgreement, encipherOnly ni decipherOnly. SLH-DSA es firma, no establecimiento de claves. Después siguen vigentes las reglas de RFC 5280 para cadena, propósito, nombre, revocación y validación.

Pure y Hash trasladan costes diferentes. Pure procesa el mensaje preparado; HashSLH-DSA incorpora un pre-hash definido y reduce los datos que atraviesan el límite de un módulo de firma. RFC 9909 explica que el mensaje interno se procesa dos veces y debe quedar en memoria. Una CRL grande o un certificado con muchos SAN puede superar los límites de transferencia o memoria de un HSM en modo Pure.

El verificador tampoco puede suponer streaming sencillo. Para certificados y CRL necesita retener el objeto completo porque un aleatorizador extraído de la firma entra al digest antes que el mensaje, mientras el formato coloca la firma después del contenido firmado. Hash reduce el M' retenido, pero no demuestra que un producto concreto pueda emitir, importar o verificar el objeto.

RFC 9814 cubre CMS SignedData y ayuda a evitar otra falsa equivalencia. Allí se especifica Pure SLH-DSA y los atributos firmados pueden reducir el material enviado al dispositivo. Es un contrato de aplicación diferente. No autoriza a atribuir a los certificados y CRL la misma ruta ni a mezclar identificadores de CMS y PKIX sin verificar su contexto.

Sin estado tampoco significa sin contabilidad. RFC 9909 fija menos de 2^64 firmas por árbol y propone contar usos o limitar la vigencia cuando una operación pudiera acercarse al techo. Exige generar cada par independientemente. La entropía, la custodia de la clave, los fallos inducidos y los canales laterales siguen dentro de la responsabilidad del implementador.

La página oficial de errata de RFC 9909 mostraba dos entradas durante el cierre del expediente. Ambas figuraban como Reported, no Verified. Una notificación abre una revisión; no modifica por sí sola el estándar. Documento publicado, errata informada, errata verificada y código corregido son cuatro relojes.

Un recibo de aceptación útil conserva DER y hash, OID de clave y firma, estado de parameters, longitudes, envoltura, keyUsage, contexto vacío, emisor, sujeto, anclas, revocación, versión de biblioteca y proveedor criptográfico. Después registra por separado conformidad de perfil, resultado de firma, resultado de ruta y decisión de la aplicación. “Reconocido” sólo responde la primera pregunta.

La primacía del código en ejecución de Heng Lu exige observar esa cadena real. La especificación inicial mínima mantiene común lo que debe interoperar y deja a cada operador la adopción. Las capas de realidad impiden que el nombre registrado se apropie del resultado.

El valor de RFC 9909 no reside en una insignia post-cuántica. Reside en obligar a decidir pronto y probar tarde. La CA decide el modo antes de emitir. El generador demuestra los bytes. El parser reconoce. El validador separa firma y ruta. La política decide si actúa. Si falta cualquiera de esos registros, el OID no puede hablar por él.

Sources