La signature post-quantique arrive discrètement : ML-DSA pour les documents Word dans .NET

💡 Exemple complet fonctionnel disponible sur GitHub :
sign-word-with-ml-dsa-certificates-dotnet

L’ancienne méthode était un plan de projet

Demandez ce qu’il faut pour rendre la signature de documents post‑quantique et on obtient une feuille de route : évaluer les algorithmes, choisir une bibliothèque, écrire une couche d’abstraction autour du code de signature, planifier une période de double signature, budgéter un trimestre.

La plupart de ces éléments restent vrais pour la partie organisationnelle — approvisionnement en certificats, politique, prise en charge des validateurs. La partie code s’est avérée plus petite que ne le laisse penser la feuille de route, et c’est bon à savoir avant que quiconque ne prévoie un trimestre pour cela.

La signature ML‑DSA est une fonctionnalité de GroupDocs.Signature pour .NET qui signe les documents Word avec des certificats basés sur le FIPS 204, la norme de signature post‑quantique du NIST. Elle est arrivée dans la version 26.9, et du point de vue du code appelant il s’agit simplement d’un fichier PFX différent.

Il existe une meilleure façon

Voici l’intégralité du changement de code :

using var signature = new Signature(sourcePath);

var options = new DigitalSignOptions(pfxPath)
{
    Password = certificatePassword
};

SignResult result = signature.Sign(outputPath, options);

C’est le même appel utilisé pour un certificat RSA. L’algorithme est une propriété du certificat, donc aucune option ne le sélectionne, aucune couche d’abstraction n’est nécessaire, et aucun second chemin de code n’apparaît pendant la période de transition. Pointez DigitalSignOptions vers un PFX ML‑DSA et la sortie sera une signature ML‑DSA.

Lire le certificat à partir du résultat vaut le détour lorsqu’il y a plusieurs certificats en jeu :

var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";

Choisir un niveau, avec des chiffres plutôt que des opinions

ML‑DSA propose trois ensembles de paramètres, correspondant aux catégories de sécurité NIST 2, 3 et 5. Plus le niveau est élevé, plus la clé et la signature sont grandes — et la façon sensée de décider est de signer votre propre document trois fois et d’observer :

var levels = new Dictionary<string, string>
{
    ["ML-DSA-44"] = MlDsa44Pfx,
    ["ML-DSA-65"] = MlDsa65Pfx,
    ["ML-DSA-87"] = MlDsa87Pfx
};

L’exemple écrit une copie signée par niveau et enregistre chaque taille, de sorte que le compromis est une mesure plutôt qu’un tableau issu d’une spécification. Pour un seul contrat, la différence est négligeable ; pour une archive de plusieurs millions de documents signés, c’est une question de capacité qu’il faut se poser avant de standardiser le niveau le plus élevé.

ML‑DSA‑65 est la valeur par défaut raisonnable lorsqu’aucune politique n’en impose une. Des profils comme CNSA 2.0 nomment explicitement ML‑DSA‑87, et ML‑DSA‑44 n’a de sens que lorsque la taille prime sur la marge de sécurité.

La vérification ne nécessite que le certificat public

L’histoire de la distribution reste identique à RSA, ce qui constitue le deuxième point positif :

var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
    options.Password = password;
}

VerificationResult result = signature.Verify(options);

Le destinataire n’a besoin que du fichier .cer du signataire et de rien d’autre. Le résultat n’est valide que lorsque la signature correspond au contenu et que le certificat correspond par numéro de série et empreinte, ainsi un document signé par une autre partie échoue à la vérification — ce que l’exemple montre en exécutant la vérification deux fois, une fois avec le bon certificat et une fois avec celui d’un tiers.

Comparaison côte à côte : prévu vs. réel

La dernière ligne est celle qui contraint la planification, et elle conduit à la partie honnête de cet article.

Ce qui ne fonctionne pas encore

Deux limites, toutes deux importantes à connaître avant de promettre quoi que ce soit.

La couverture des formats se limite à Word dans la version 26.9 — DOCX, DOC, ODT et le reste de la famille Word. PDF, feuilles de calcul et présentations ne peuvent pas être signés avec ML‑DSA. Pour une chaîne de traitement centrée sur le PDF, cette version sert davantage à prototyper et à mesurer qu’à migrer.

Le support des validateurs est l’autre point. Il n’existe pas encore d’identifiant XML‑DSig standard pour ML‑DSA, de sorte que Microsoft Word peut ne pas signaler la signature comme valide même si elle est cryptographiquement correcte et se vérifie correctement via l’API. Il s’agit d’une lacune normative plutôt que d’un défaut, et cela signifie que la vérification doit être effectuée dans votre code plutôt que par un relecteur ouvrant le fichier et regardant la bannière.

Il y a aussi un détail de plateforme qui ne nécessite aucune action : .NET ne peut pas lire les clés ML‑DSA partout, notamment sous Linux avec .NET 8. Lorsqu’il ne le peut pas, GroupDocs.Signature lit le certificat via le moteur Word, de sorte que la même construction fonctionne sur un ordinateur de développeur et dans un conteneur Linux sans code conditionnel.

Cela vaut‑il la peine de le faire maintenant, compte tenu de ces limites ?

Oui, pour deux raisons qui n’ont rien à voir avec le code. L’obtention de certificats est lente — les autorités de certification publiques déploient encore l’émission de ML‑DSA — donc le travail côté organisation bénéficie d’un démarrage précoce. Et « pouvons‑nous produire une signature post‑quantique dès aujourd’hui ? » est une question que les équipes de conformité commencent à poser ; pouvoir répondre avec un document signé plutôt qu’avec un plan vaut bien l’après‑midi nécessaire.

Ce que l’exemple prouve réellement

Quatre méthodes, exécutées dans l’ordre, avec le code de sortie lié au résultat. Il signe le contrat avec ML‑DSA‑65 et affiche le sujet du certificat utilisé. Il signe le même contrat aux trois niveaux et affiche les tailles obtenues. Il vérifie le fichier signé deux fois — une fois avec le certificat public du signataire (succès attendu) et une fois avec le certificat d’un autre signataire (échec attendu). Enfin, il répertorie les signatures numériques trouvées dans le résultat.

La deuxième vérification est celle qui mérite d’être copiée. Une routine qui n’a jamais été présentée qu’avec des entrées valides ne vous indique rien sur son comportement face à une entrée invalide, et pour les signatures c’est toute la question.

Exemple réel : le contrat de trente ans

Les archives à conservation longue sont le contexte où cela cesse d’être théorique. Un contrat signé aujourd’hui et conservé pendant trente ans doit rester vérifiable quel que soit l’évolution de la cryptographie pendant cette période, et « récolter maintenant, déchiffrer plus tard » est un modèle de menace documenté pour ce type de matériel.

Pour une telle archive, la démarche pratique aujourd’hui est à double voie : conserver RSA pour les formats que ML‑DSA ne couvre pas encore, commencer à signer les sorties Word avec ML‑DSA‑65 ou 87, et enregistrer quel algorithme a été utilisé pour chaque document afin qu’un audit futur puisse les différencier sans ouvrir les fichiers.

Un point à corriger dans l’exemple avant de le copier

Le dépôt fournit des certificats ML‑DSA auto‑signés afin que la démonstration fonctionne immédiatement, ce qui implique quatre fichiers PFX et un mot de passe codé en dur dans le répertoire documents/. Pour un certificat de test jetable valable uniquement dans le cadre de cet exemple, cela convient.

Ce n’est toutefois pas une pratique à reproduire dans votre propre dépôt. Générez les certificats de test à l’exécution, comme le fait l’exemple de validité de certificat de GroupDocs, ou conservez‑les hors du contrôle de version. Un clé engagée est difficile à révoquer et a tendance à survivre bien au-delà de la démo pour laquelle elle a été créée.

Conclusion

Les parties coûteuses de la migration post‑quantique sont les certificats, les politiques et les validateurs. Le code, du moins pour les documents Word sous .NET, se résume à un PFX différent et au même appel DigitalSignOptions. Clonez l’exemple, pointez‑le vers l’un de vos contrats, et vous obtiendrez trois fichiers signés, deux résultats de vérification et une comparaison de tailles en quelques minutes — une base bien meilleure pour un plan de migration qu’une simple estimation.

Ressources supplémentaires

• Projet d’exemple complet .NET sur GitHub
• Guide d’utilisation pas à pas
• Signer un document avec une signature numérique
• Vérifier les signatures numériques dans le document
• Documentation GroupDocs.Signature pour .NET
• Forum de support gratuit