Résumé

  • Sans attributs signés, ML-DSA porte directement sur les octets du contenu : SHA-512 doit figurer dans digestAlgorithm pour l’interopérabilité, mais RFC 9882 oblige le vérificateur à ignorer ce champ.
  • Avec des attributs signés, le condensat du contenu devient une donnée protégée, à recalculer et comparer ; son choix peut alors borner la robustesse de l’ensemble.
  • La preuve exploitable sépare le chemin CMS, les octets exacts, l’OID du jeu de paramètres, la protection des algorithmes, les frontières de clé et de μ, l’identité, l’autorisation et l’effet produit.

Un tableau de contrôle peut afficher « SHA-512 », « ML-DSA-65 » et « signature valide » sans mentir. Il peut néanmoins induire trois conclusions injustifiées : que SHA-512 a fourni le condensat à ML-DSA, que la clé privée n’a jamais quitté un HSM et que le titulaire du certificat avait pouvoir d’autoriser l’opération.

Publié en octobre 2025 comme proposition de norme de l’IETF, RFC 9882 décrit l’emploi dans CMS des trois jeux de paramètres normalisés par FIPS 204 : ML-DSA-44, ML-DSA-65 et ML-DSA-87. Chacun possède son propre OID de signature et les paramètres de son AlgorithmIdentifier doivent être absents. Le texte traite de ML-DSA pur, non de HashML-DSA dans CMS. L’ancien nom Dilithium ne désigne pas un format compatible.

Pour interpréter un résultat, il faut d’abord regarder si signedAttrs est présent.

En son absence, les données remises à ML-DSA sont les octets constituant la valeur de l’OCTET STRING encapContentInfo eContent, à l’exclusion du tag et de la longueur. Le message entier est traité par ML-DSA pur. Dans cette configuration, SignerInfo.digestAlgorithm n’a aucune fonction dans le calcul de la signature.

RFC 9882 exige pourtant que le signataire y inscrive SHA-512 afin de limiter les échecs d’interopérabilité. Le destinataire, lui, doit ignorer le contenu du champ. Cette valeur renseigne donc sur le respect d’une convention de compatibilité ; elle ne prouve pas l’existence d’un hachage externe du contenu. Une extraction automatisée qui lui attribue cette seconde signification fabrique une causalité absente du protocole.

Avec signedAttrs, l’objet signé change. Il s’agit de l’encodage DER intégral de la valeur SignedAttrs, tag et longueur compris, avec le tag EXPLICIT SET OF plutôt que le tag IMPLICIT [0] visible dans le message final. Les attributs comprennent au minimum le type de contenu et le condensat du message. Le destinataire doit recalculer ce dernier sur le contenu et le comparer à la valeur protégée. Le choix du condensat compte alors réellement et peut limiter le niveau de sécurité global. La prise en charge de SHA-512 est obligatoire ; celle de SHAKE256 est recommandée, sans paramètres dans son identifiant.

Une seule présence syntaxique crée ainsi deux sens opérationnels. Avant de parler de validité, un journal d’audit doit nommer la branche, reconstruire la suite d’octets soumise à la vérification et, le cas échéant, conserver le résultat de la comparaison du condensat. Sinon, il documente une étiquette, pas une exécution.

L’identité de l’algorithme forme un autre contrôle. L’OID doit correspondre au jeu de paramètres ML-DSA retenu et tout paramètre interdit doit provoquer un rejet. L’attribut CMSAlgorithmProtection, défini par RFC 6211, place les identifiants pertinents dans la zone signée. RFC 9882 recommande son inclusion contre les substitutions d’algorithmes. Sa présence et sa cohérence ne découlent pas d’une signature mathématiquement correcte : elles doivent être vérifiées.

La garde de la clé demeure hors de cette conclusion. Une clé ML-DSA compromise permet la contrefaçon. FIPS 204 prévoit par défaut une génération dite hedged, combinant de l’aléa frais avec des données aléatoires préétablies dans la clé, et autorise aussi un mode déterministe. RFC 9882 déconseille ce dernier lorsqu’il faut craindre les canaux auxiliaires ou les injections de faute. Le message CMS ne dit pas, à lui seul, quelle politique a été appliquée.

Le recours à un module matériel déplace encore la frontière. Les attributs signés permettent de lui envoyer un petit objet DER plutôt que le contenu entier. Le représentant de message μ peut également être calculé dans un autre module cryptographique avant d’être fourni au signataire. « Produit par le HSM » n’établit donc ni que le HSM a reçu les octets originaux, ni qu’il a calculé μ. Le contrat d’interface et la liaison avec l’objet conservé deviennent des éléments de preuve à part entière.

Le dossier complet commence par l’objet CMS exact, puis consigne la présence des attributs, les octets reconstruits, l’OID et l’absence de paramètres, la comparaison du condensat si elle s’applique, la protection des algorithmes et le résultat cryptographique. Il ajoute ensuite la politique d’aléa et la provenance de μ lorsqu’elles sont connues, avant d’évaluer séparément la chaîne de certificats, l’identité, le droit d’agir et l’action finale. Aucun de ces étages ne doit être absorbé par une case verte unique.

Sources