💡 Ejemplo completo disponible en GitHub:
sign-word-with-ml-dsa-certificates-dotnet
La forma antigua era un plan de proyecto
Pregúntale qué se necesita para que la firma de documentos sea post‑cuántica y obtendrás una hoja de ruta: evaluar algoritmos, elegir una biblioteca, escribir una capa de abstracción sobre el código de firma, planificar un período de firma dual, presupuestar un trimestre.
La mayor parte de eso sigue siendo cierto para la mitad organizativa — adquisición de certificados, políticas, soporte de validadores. La mitad de código resultó ser más pequeña de lo que sugiere la hoja de ruta, y eso vale la pena saber antes de que alguien asigne un trimestre para ello.
La firma ML‑DSA es una capacidad de GroupDocs.Signature para .NET que firma documentos Word con certificados basados en FIPS 204, el estándar de firma post‑cuántica de NIST. Llegó en la versión 26.9, y desde el punto de vista del código que la llama es un archivo PFX diferente.
Existe una forma mejor
Aquí está todo el cambio de código:
using var signature = new Signature(sourcePath);
var options = new DigitalSignOptions(pfxPath)
{
Password = certificatePassword
};
SignResult result = signature.Sign(outputPath, options);
Esa es la misma llamada que se usa para un certificado RSA. El algoritmo es una propiedad del certificado, por lo que no hay una opción que lo seleccione, no se necesita una capa de abstracción y no aparece una segunda vía de código para el período de transición. Apunta DigitalSignOptions a un PFX ML‑DSA y la salida será una firma ML‑DSA.
Leer el certificado del resultado vale la pena mientras hay varios certificados en juego:
var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";
Elegir un nivel, con números en lugar de opiniones
ML‑DSA viene en tres conjuntos de parámetros, que se corresponden con las categorías de seguridad NIST 2, 3 y 5. Más fuerte significa más grande — tanto la clave como la firma — y la forma sensata de decidir es firmar tu propio documento tres veces y observar:
var levels = new Dictionary<string, string>
{
["ML-DSA-44"] = MlDsa44Pfx,
["ML-DSA-65"] = MlDsa65Pfx,
["ML-DSA-87"] = MlDsa87Pfx
};
El ejemplo escribe una copia firmada por nivel y registra cada tamaño, de modo que la compensación es una medida más que una tabla de especificación. Para un solo contrato la diferencia es insignificante; para un archivo de varios millones de documentos firmados es una cuestión de capacidad que vale la pena plantear antes de estandarizar el nivel más alto.
ML‑DSA-65 es el valor predeterminado razonable cuando ninguna política prescribe uno. Perfiles como CNSA 2.0 nombran explícitamente ML‑DSA-87, y ML‑DSA-44 solo tiene sentido cuando el tamaño importa más que el margen.
La verificación solo necesita el certificado público
La historia de distribución no cambia respecto a RSA, lo que es la segunda buena noticia:
var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
options.Password = password;
}
VerificationResult result = signature.Verify(options);
Un destinatario solo necesita el .cer del firmante y nada más. El resultado es válido solo cuando la firma coincide con el contenido y el certificado coincide por número de serie y huella digital, por lo que un documento firmado por otra parte falla la comprobación — lo que el ejemplo demuestra al ejecutar la verificación dos veces, una con el certificado correcto y otra con el de otra persona.
Lado a lado: esperado vs. real
| Lo que asume un plan de migración | Lo que 26.9 realmente requiere | |
|---|---|---|
| Cambio de código | capa de abstracción sobre la firma | una ruta PFX diferente |
| Superficie de API | nuevos métodos post‑cuánticos | DigitalSignOptions, sin cambios |
| Selección de nivel | configuración de la biblioteca | qué certificado cargas |
| Verificación | nuevas herramientas para los destinatarios | el .cer público del firmante |
| Trabajo de plataforma | manejo de claves por SO | ninguno - la biblioteca retrocede internamente |
| Cobertura de formatos | todos los formatos | solo formatos Word, por ahora |
La última fila es la que restringe la planificación, y lleva a la parte honesta de este artículo.
Lo que aún no funciona
Dos limitaciones, ambas útiles de conocer antes de prometer cualquier cosa.
La cobertura de formatos es solo Word en la 26.9 — DOCX, DOC, ODT y el resto de la familia Word. PDF, hojas de cálculo y presentaciones no pueden firmarse con ML‑DSA. Para una canalización centrada en PDF, esta versión sirve para prototipado y medición más que para migración.
El soporte de validadores es el otro. Aún no existe un identificador XML‑DSig estándar para ML‑DSA, por lo que Microsoft Word puede no reportar la firma como válida aunque sea criptográficamente correcta y se verifique correctamente a través de la API. Eso es una brecha de estándares más que un defecto, y significa que la verificación debe estar en tu código en lugar de en un revisor que abra el archivo y mire el banner.
También hay un detalle de plataforma que no requiere acción: .NET no puede leer claves ML‑DSA en todas partes, incluido Linux en .NET 8. Cuando no puede, GroupDocs.Signature lee el certificado a través del motor de Word, de modo que la misma compilación se ejecuta en un portátil de desarrollador y en un contenedor Linux sin código condicional.
¿Vale la pena hacerlo ahora, dadas esas limitaciones?
Sí, por dos razones que no tienen nada que ver con el código. La adquisición de certificados es lenta — las autoridades de certificación públicas aún están implementando la emisión de ML‑DSA — por lo que el trabajo del lado organizativo se beneficia de comenzar temprano. Y “¿podemos producir una firma post‑cuántica hoy?” es una pregunta que los equipos de cumplimiento están empezando a plantear; poder responder con un documento firmado en lugar de con un plan vale la tarde que lleva.
Lo que realmente demuestra el ejemplo
Cuatro métodos, ejecutados en orden, con el código de salida ligado al resultado. Firma el contrato con ML‑DSA-65 e imprime el asunto del certificado usado. Firma el mismo contrato en los tres niveles y muestra los tamaños resultantes. Verifica el archivo firmado dos veces — una con el certificado público del firmante, esperando éxito, y otra con el certificado de otro firmante, esperando fallo. Luego enumera las firmas digitales encontradas en la salida.
La segunda verificación es la que vale la pena copiar. Una rutina que solo se ha mostrado con entrada válida no dice nada sobre si rechazaría una entrada inválida, y para firmas esa es toda la cuestión.
Ejemplo del mundo real: el contrato de treinta años
Los archivos de retención a largo plazo son donde esto deja de ser teórico. Un contrato firmado hoy y conservado durante treinta años debe seguir siendo verificable a lo largo de lo que ocurra con la criptografía en ese intervalo, y “cosechar ahora, descifrar después” es un modelo de amenaza documentado para exactamente ese tipo de material.
Para un archivo así, el movimiento práctico hoy es de doble vía: mantener RSA para los formatos que ML‑DSA aún no cubre, comenzar a firmar la salida Word con ML‑DSA-65 o 87, y registrar qué algoritmo se usó por documento para que una auditoría futura pueda distinguirlos sin abrir los archivos.
Una cosa a corregir en el ejemplo antes de copiarlo
El repositorio incluye certificados ML‑DSA autofirmados para que la demostración funcione de inmediato, lo que implica cuatro archivos PFX y una contraseña codificada en documents/. Para un certificado de prueba desechable válido solo dentro de ese ejemplo, está bien.
No es un patrón para llevar a tu propio repositorio. Genera certificados de prueba en tiempo de ejecución, como hace el ejemplo de validez de certificados de GroupDocs, o mantenlos fuera del control de versiones. Una clave comprometida es incómoda de revocar y tiende a sobrevivir al demo para el que se escribió.
Conclusión
Las partes costosas de la migración post‑cuántica son los certificados, las políticas y los validadores. El código, al menos para documentos Word en .NET, es un PFX diferente y la misma llamada DigitalSignOptions. Clona el ejemplo, apúntalo a uno de tus propios contratos, y tendrás tres archivos firmados, dos resultados de verificación y una comparación de tamaños en pocos minutos — lo que constituye una base mejor para un plan de migración que una estimación.