Resumen

  • RFC 9814 ofrece dos recorridos: sin atributos firmados, Pure SLH-DSA firma el contenido; con ellos, firma DER(SignedAttributes) y el contenido entra en la prueba a través de message-digest.
  • content-type es tan importante como el digest: une los octetos con su interpretación CMS, mientras CMSAlgorithmProtection ayuda a fijar la historia de algoritmos dentro de lo firmado.
  • Mantener un fichero grande fuera del HSM puede ser eficiente y facilitar el procesamiento en flujo, pero convierte al lector, al hasheador y al constructor DER en autoridades que deben emitir pruebas propias.

Una igualdad incompleta

Supongamos que un sistema recibe un paquete regulatorio y recalcula su SHA-256. El valor coincide con message-digest; la pantalla se vuelve verde. Más tarde se descubre que la aplicación aprobó un tipo CMS distinto del que el firmante había declarado. Los octetos no cambiaron, pero sí la operación autorizada: otro parser, otra ruta de retención, quizá otro destinatario.

El caso muestra por qué una firma no es solo una comprobación de integridad bruta. RFC 9814, publicado como estándar en julio de 2025, especifica Pure SLH-DSA con contexto vacío para CMS SignedData. Cuando existen atributos firmados, el mensaje criptográfico no es el archivo ni su digest aislado. Es la codificación DER del conjunto de atributos, dentro del cual aparecen obligatoriamente el digest y el tipo de contenido.

Para evaluar una implementación hay que empezar preguntando qué bytes llegaron a la operación SLH-DSA. La respuesta cambia según esté presente SignerInfo.signedAttrs.

Cuando no hay atributos firmados

Sin signedAttrs, Pure SLH-DSA firma el contenido. No hay una capa CMS intermedia que represente ese contenido mediante un atributo. El contexto de SLH-DSA es la cadena vacía prescrita, no una etiqueta configurable por el producto.

El campo digestAlgorithm de SignerInfo no convierte este recorrido en una firma del hash. RFC 9814 explica que el campo no participa en el cálculo de la firma cuando faltan atributos firmados. Puede existir por la forma de CMS y por necesidades de compatibilidad, pero no autoriza a sustituir el mensaje por un resumen externo. Si una pasarela acepta Hash(contenido) y lo entrega al firmante como si fuese el contenido, está ejecutando otra operación.

La consecuencia para archivos grandes es práctica. El módulo o servicio que ejecuta Pure SLH-DSA necesita el mensaje según su interfaz. Un verificador que solo conservó un digest mientras llegaba el flujo no obtiene automáticamente una verificación Pure de una sola pasada. La arquitectura debe prever relectura, almacenamiento o un recorrido de API adecuado.

Cuando sí hay atributos firmados

Con signedAttrs, CMS calcula el digest del contenido mediante el algoritmo declarado para el firmante y lo coloca en message-digest. Añade content-type, que identifica el tipo del contenido encapsulado o externo. Después codifica el conjunto de atributos con DER. Pure SLH-DSA firma esa secuencia canónica.

Esto separa el control en fases:

  1. Seleccionar una versión inmutable del contenido y leer todos sus octetos.
  2. Aplicar el algoritmo de digest permitido y registrar longitud y resultado.
  3. Construir el conjunto completo de atributos, incluido el tipo correcto.
  4. Producir exactamente una codificación DER.
  5. Firmar esos bytes con el identificador Pure SLH-DSA coherente con la clave.
  6. Validar después digest, tipo, atributos, firma, certificado y política.

Un HSM suele intervenir solo en el quinto paso. Puede acreditar que una clave protegida firmó una entrada concreta. No puede demostrar por sí solo que el objeto de almacenamiento leído en el primer paso era el aprobado por una persona, ni que el adaptador no sustituyó el tipo en el tercero.

El verificador debe recalcular el digest sobre el contenido recibido y compararlo en tiempo constante según la biblioteca aplicable. También debe cotejar content-type con encapContentInfo.eContentType. No basta con que ambos campos estén presentes. Deben ser coherentes con el objeto y con la política que decide qué tipos puede autorizar la clave.

El algoritmo de digest también forma parte del contrato

Cuando hay atributos, SignerInfo.digestAlgorithm identifica la función usada para message-digest, y SignedData.digestAlgorithms contiene los algoritmos correspondientes a los firmantes. RFC 9814 vincula además el tamaño de salida requerido con la resistencia a colisiones del conjunto de parámetros SLH-DSA. La aceptación no debería reducirse a una lista genérica de hashes «fuertes»; necesita una matriz verificable entre conjunto de parámetros, digest, perfil CMS y política local.

Cuando no hay atributos, ese mismo campo no se usa para prehashear la entrada de Pure SLH-DSA. Una implementación que comparte código entre ambos recorridos puede equivocarse precisamente aquí. Las pruebas deben demostrar que la presencia o ausencia de signedAttrs cambia la reconstrucción del mensaje, no solo una rama de visualización.

RFC 9814 define doce identificadores de firma para los conjuntos Pure SLH-DSA y exige parámetros ausentes. La verificación comprueba su coherencia con el algoritmo de clave pública. RFC 9909 proporciona la capa X.509 relacionada, pero una cadena válida no remedia un digest calculado sobre el objeto equivocado.

Protección frente a una historia algorítmica sustituida

El atributo CMSAlgorithmProtection de RFC 6211 debería incluirse dentro de los atributos firmados. Su valor protege los identificadores de digest y firma contra sustituciones en campos exteriores. No garantiza que el algoritmo sea aceptable para la política vigente; garantiza que la declaración protegida no pueda cambiarse sin romper la firma.

Como la exigencia es un SHOULD, una organización tiene que decidir cómo trata la ausencia. Puede aceptar temporalmente objetos heredados, pero debe identificarlos, medirlos y fijar una fecha o condición de retirada. Aceptar sin telemetría convierte una excepción de compatibilidad en el perfil real de producción.

También debe rechazarse la aparición de parámetros donde el identificador SLH-DSA exige que no existan. «Ignorar lo desconocido» es una mala política en una superficie donde diferentes bibliotecas podrían interpretar el mismo objeto de manera desigual.

DER no es un detalle de serialización

Los atributos se describen como campos, pero la firma cubre bytes. DER establece una representación canónica de la estructura ASN.1. Si un registro guarda solo un JSON reconstruido o una captura de pantalla, puede perder orden canónico, etiquetas, longitudes, tipos exactos o atributos no reconocidos.

Conservar el CMS original es el mínimo. Para operaciones de alta responsabilidad conviene conservar también la entrada DER exacta entregada al firmante, su hash de auditoría y la versión de la biblioteca que la produjo. Otra implementación independiente debe poder regenerarla y obtener los mismos bytes. Si no puede, la organización posee una firma pero depende del proveedor para explicar qué autorizó.

El constructor DER es, por tanto, parte de la base de confianza. Un HSM robusto no corrige un middleware que omite content-type, calcula el digest sobre una versión temporal, normaliza atributos después de la aprobación o muestra al usuario una representación diferente de la firmada.

No es HashSLH-DSA

El recorrido con atributos reduce un contenido voluminoso antes de llamar al HSM. Esa geometría se parece a una API de prehash, pero la semántica es distinta. FIPS 205 define variantes Pure y prehash; RFC 9814 selecciona Pure para CMS. El digest CMS es un atributo dentro de un mensaje DER más rico. HashSLH-DSA tiene su propia operación e identificadores.

La denominación correcta evita errores de inventario y migración. Un catálogo debería registrar «Pure SLH-DSA sobre SignedAttributes; contenido unido por digest», no solo «SLH-DSA prehash». Así un verificador futuro sabrá qué bytes reconstruir, y un equipo de compra podrá comparar productos sin aceptar palabras ambiguas.

Flujo, reintentos y evidencia

El beneficio de streaming es real: el receptor puede hashear mientras llegan los datos, liberar bloques y verificar después una estructura pequeña. El firmante puede mantener gigabytes fuera del módulo. Pero el componente de hash se vuelve una autoridad.

Los reintentos deben probarse de forma hostil. ¿Se reinicia el digest desde cero o desde un estado autenticado? ¿Un nombre de objeto apunta a la misma versión? ¿La longitud registrada coincide? ¿Se mezclan fragmentos de dos cargas? ¿El tipo se obtiene del objeto firmado o de una cabecera HTTP mutable? Cada respuesta necesita un recibo, no una suposición.

El expediente mínimo incluye identificador y versión del contenido, longitud, algoritmo y digest, tipo CMS, conjunto completo de atributos, bytes DER, identificador SLH-DSA, clave y certificado, firma, instante, versión de política y resultados diferenciados. Las mutaciones de aceptación deben cambiar por separado contenido, digest, tipo, atributo adicional, DER, algoritmos, clave y cadena. Cada fallo debe tener un nombre estable.

El estándar no promete adopción, rendimiento, capacidad de un HSM ni seguridad cuántica integral. Cifrado, cadena de certificados, aleatoriedad, canales laterales, fallos de implementación y custodia siguen fuera de esta unión. La clave SLH-DSA tiene además un límite de uso inferior a 2^64 firmas, que exige inventario y rotación.

La propuesta de Heng Lu sobre una especificación inicial mínima encaja aquí: definir una interfaz pequeña pero comprobable, capaz de mostrar la realidad entre actores. El código en ejecución merece primacía cuando otro equipo puede reproducir la unión completa; no cuando una etiqueta de conformidad reemplaza los bytes y los recibos.

Fuentes