Résumé

  • Sans attributs signés, RFC 9814 fait signer le contenu par Pure SLH-DSA ; avec ces attributs, il fait signer leur encodage DER, tandis que le contenu n’est relié que par l’attribut message-digest.
  • Le gain de traitement en flux et la réduction de l’entrée HSM créent une chaîne de responsabilité : octets reçus, algorithme de hachage, type de contenu, attributs canoniques, algorithme de signature, clé et politique doivent rester vérifiables séparément.
  • Ce schéma n’est pas le mode préhaché de SLH-DSA. Une terminologie imprécise peut provoquer un mauvais identifiant, une mauvaise reconstruction et une fausse assurance d’audit.

Le flux arrive avant son enveloppe de preuve

Prenons un vérificateur qui reçoit une sauvegarde de plusieurs gigaoctets par fragments. Il ne peut pas conserver indéfiniment chaque octet dans une mémoire rapide. Il alimente donc une fonction de hachage, compte les octets et conserve un identifiant immuable de l’objet. Ce n’est qu’à la fin qu’il reçoit le SignerInfo de CMS. Si des attributs signés sont présents, le contrôle SLH-DSA porte sur une petite valeur DER. Le vérificateur peut achever l’opération sans rejouer tout le flux, à condition que le condensat calculé soit exactement celui inscrit dans les attributs.

Cette commodité est parfois résumée par « la signature porte sur le hash ». C’est trop court. RFC 9814, standard IETF publié en juillet 2025, impose Pure SLH-DSA avec un contexte vide pour SignedData. Le condensat externe appartient au mécanisme CMS des attributs ; il ne transforme pas l’algorithme en HashSLH-DSA. La valeur signée contient aussi le type CMS et les autres attributs, sous une forme canonique.

Il existe donc deux chemins de preuve, et un produit qui les confond ne peut pas être évalué correctement.

Sans signedAttrs, le message reste le contenu

Lorsque SignerInfo.signedAttrs est absent, l’entrée de Pure SLH-DSA est le contenu lui-même. L’algorithme reçoit le message conformément à son mode pur et utilise le contexte vide fixé par RFC 9814. Le champ CMS digestAlgorithm n’est pas un ordre de préhachage pour cette opération. Sa présence structurelle ne permet pas de remplacer le contenu par Hash(contenu).

Cette distinction compte pour les interfaces distantes. Un service qui n’accepte que des condensats ne peut pas prétendre avoir mis en œuvre ce chemin en enveloppant un hash arbitraire. Il lui faut soit transporter le contenu selon l’interface attendue, soit choisir le chemin avec attributs signés et en respecter toutes les contraintes.

Pour la réception en flux, l’inconvénient est clair : un simple condensat CMS conservé à mesure de l’arrivée ne suffit pas nécessairement à alimenter ultérieurement la vérification Pure SLH-DSA. Le message cryptographique est toujours le contenu. Il faut planifier la conservation, la relecture ou l’interface de vérification en conséquence.

Avec signedAttrs, la preuve devient une jointure

En présence d’attributs signés, CMS calcule un condensat du contenu. Sa valeur est placée dans l’attribut obligatoire message-digest. L’attribut obligatoire content-type indique la nature CMS du contenu. L’ensemble des attributs est encodé en DER, puis cet encodage devient le message de Pure SLH-DSA.

La vérification doit donc répondre à plusieurs questions indépendantes :

  • quels octets ont alimenté le hachage, dans quel ordre et avec quelle longueur ;
  • quel algorithme de hachage a produit la valeur annoncée ;
  • le type de contenu signé correspond-il au type réellement reçu ;
  • quels attributs complets ont été encodés, et quels octets DER en ont résulté ;
  • l’identifiant Pure SLH-DSA est-il autorisé et cohérent avec la clé publique ;
  • la signature sur ces octets DER est-elle valide ;
  • le certificat et la politique rendent-ils cette clé acceptable pour la décision métier.

Un seul voyant « signature valide » ne répond qu’à une partie de cette liste. De même, un journal HSM attestant l’usage d’une clé ne prouve pas que l’adaptateur a lu la bonne version du fichier ni qu’il a associé le bon type de contenu.

La valeur message-digest doit être recalculée sur le contenu effectivement reçu. Le content-type doit être comparé au type encapsulé ou déclaré pour le contenu externe. Cette seconde comparaison peut sembler formelle, mais elle commande souvent le choix du parseur, la rétention, le traitement automatique et l’autorisation. Des octets identiques interprétés comme deux objets métier différents ne produisent pas le même engagement.

La forme DER appartient au fait signé

Une liste lisible d’attributs ne suffit pas à reconstruire l’entrée de signature. DER transforme la structure ASN.1 en une suite canonique d’octets. Les règles de balisage, de longueur, de classement et d’encodage des valeurs font partie du message signé. Un export d’audit qui ne garde que les champs affichés peut perdre ce qu’il faudrait pour reproduire la validation.

L’organisation devrait conserver l’objet CMS original et soit les octets DER exacts soumis au signataire, soit une méthode déterministe, testée et indépendante pour les reconstruire. Les attributs inconnus ne doivent pas disparaître d’un écran puis d’une archive. Les doublons ou encodages non canoniques doivent produire un résultat explicite, non une normalisation silencieuse dont personne ne possède la trace.

Cette exigence révèle un centre de pouvoir souvent ignoré : le constructeur d’attributs. La clé privée peut être enfermée dans un HSM certifié ; si un composant ordinaire choisit le fichier, calcule le hash et fabrique l’ensemble DER, ce composant contrôle le sens de la signature. Sa chaîne logicielle, ses droits et ses journaux sont des éléments de sécurité de premier rang.

Protéger l’histoire des algorithmes

RFC 9814 définit douze identifiants de signature correspondant aux jeux de paramètres Pure SLH-DSA. Leurs paramètres doivent être absents. Le vérificateur contrôle la cohérence entre l’algorithme de signature et celui de la clé publique. Lorsque les attributs sont présents, l’algorithme de hachage choisi pour message-digest et les entrées du jeu SignedData.digestAlgorithms doivent également être cohérents.

Le standard recommande l’attribut signé CMSAlgorithmProtection, défini par RFC 6211. Il place les identifiants de hachage et de signature dans la matière protégée, afin de réduire le risque qu’un intermédiaire substitue une autre lecture algorithmique aux champs extérieurs. Parce qu’il s’agit d’un « SHOULD », l’absence est possible ; elle doit néanmoins déclencher une politique explicite et une télémétrie. L’absence silencieuse ne constitue pas une politique de compatibilité.

RFC 9909 traite de l’usage de SLH-DSA dans les certificats X.509. Le certificat, son chemin et ses contraintes restent indispensables, mais ils ne prouvent pas la jointure entre contenu et attributs. À l’inverse, un condensat parfaitement raccordé au contenu ne rend pas la clé automatiquement digne de confiance. Les couches se rencontrent au verdict, sans pouvoir se remplacer.

Ressemblance de préhachage, différence de mode

Sur un schéma d’architecture, le chemin avec attributs paraît préhaché : un gros objet entre dans un hacheur et une petite valeur arrive au HSM. Mais Pure SLH-DSA ne signe pas seulement ce condensat. Il signe le DER des attributs, qui inclut le condensat, le type et d’autres assertions. HashSLH-DSA est un mode normalisé distinct, avec sa propre sémantique et ses identifiants.

Une documentation qui emploie « préhash » pour les deux crée un risque d’interopérabilité. Le développeur peut encoder le mauvais OID ; l’équipe d’exploitation peut croire que le HSM a vérifié le contenu ; l’auditeur peut omettre les octets DER. Le vocabulaire opérationnel doit nommer le chemin complet : « Pure SLH-DSA sur les attributs CMS signés, le contenu étant relié par message-digest ».

Une architecture en flux exige des reçus en chaîne

Pour chaque opération, le dossier de preuve devrait contenir l’identité immuable du contenu, sa version et sa longueur, l’algorithme et le condensat calculé, le type de contenu, l’ensemble complet des attributs, l’encodage DER à signer, l’identifiant SLH-DSA, la clé et le certificat, la signature, la version de politique et des verdicts distincts pour chaque contrôle.

Les reprises de flux sont un test critique. Après une coupure, le hachage reprend-il au bon octet ? L’objet distant a-t-il changé entre deux lectures ? Un identifiant de stockage désigne-t-il une version immuable ou seulement un nom courant ? Le nombre d’octets doit faire partie du reçu, car un condensat sans contexte de lecture ne décrit pas le chemin qui l’a produit.

Les essais d’acceptation doivent muter séparément un octet du contenu, le condensat, le type, un attribut supplémentaire, l’encodage, les identifiants algorithmiques, la clé et le certificat. Le système doit nommer l’étape qui échoue. Il faut aussi tester l’absence de CMSAlgorithmProtection, les paramètres présents alors qu’ils doivent être absents, le contenu détaché, les fichiers volumineux et la validation de chemin échouant après une signature cryptographiquement correcte.

RFC 9814 ne promet ni performances HSM, ni adoption industrielle, ni qualité d’un fournisseur. Il ne rend pas non plus quantiquement sûr le chiffrement, le chemin de certification ou le reste de CMS. L’aléa, les canaux auxiliaires, les fautes, la garde des clés et la limite de moins de 2^64 signatures par clé restent des responsabilités distinctes.

La « spécification initiale minimale » défendue par Heng Lu fournit ici une discipline utile : exposer le plus petit contrat qui permette à plusieurs acteurs de tester le même fait. La couche de réalité n’est pas la mention « conforme RFC 9814 » ; c’est la possibilité de refaire le passage des octets au condensat, du condensat au DER, puis du DER à la signature et au verdict.

Sources