Summary

  • Le RFC 9909 sépare les OID de Pure SLH-DSA de ceux de HashSLH-DSA ; une clé identifiée dans un mode ne peut pas servir à produire ou vérifier une signature identifiée dans l’autre.
  • Le reçu utile conserve l’encodage exact : paramètres absents, octets de clé sans enveloppe supplémentaire, keyUsage compatible, résultat cryptographique, chemin de certification et décision applicative distincts.

Le premier vérificateur affichait « algorithme connu ». Le second savait associer l’OID à SLH-DSA. Pourtant, le certificat du banc d’essai fut rejeté. Aucun incident réel ni produit nommé ne se cache derrière cette scène : elle sert à isoler une erreur d’interprétation que le RFC 9909 rend mesurable.

Dans le premier objet, SubjectPublicKeyInfo portait l’OID d’un jeu Pure, tandis que la signature du certificat annonçait la variante préhachée correspondante. Dans le second, les deux noms correspondaient, mais AlgorithmIdentifier contenait un NULL. Or le profil exige que le champ parameters soit absent. Une interface peut résumer les deux objets par « SLH-DSA ». Leurs octets ne satisfont pas le même contrat.

Publié en décembre 2025 sur la voie Standards Track de l’IETF, le RFC 9909 provient du groupe LAMPS. Il adapte aux certificats, listes de révocation, clés publiques et clés privées X.509 l’algorithme stateless fondé sur le hachage normalisé par le FIPS 205 du NIST. SPHINCS+ était le nom antérieur, mais le RFC précise que SPHINCS+ et SLH-DSA ne sont pas compatibles. Une simple substitution d’étiquette détruirait donc déjà la traçabilité.

Le texte définit douze OID Pure et douze OID HashSLH-DSA. Le choix encode le niveau de sécurité — 128, 192 ou 256 bits —, la variante petite ou rapide, et la famille SHA-2 ou SHAKE. Pour HashSLH-DSA, le nom indique aussi la fonction de préhachage. Le registre CSOR du NIST publie les mêmes branches.

Cette granularité est une règle d’exécution. Le même OID identifie clé publique, clé privée et algorithme de signature. Le RFC en tire une interdiction explicite : une clé Pure ne peut pas signer ou vérifier une signature Hash, et inversement, même si l’opération paraît mathématiquement réalisable. L’interopérabilité vient d’une lecture unique, pas de la tolérance inventive d’une bibliothèque.

Le champ parameters matérialise une autre frontière. Pour les identifiants SLH-DSA couverts, il doit être absent dans les clés comme dans les signatures. Un NULL encodé n’est pas une absence. L’histoire d’AlgorithmIdentifier contient des profils où NULL était attendu et d’autres où il était omis ; une compatibilité permissive héritée peut donc produire le piège classique : l’objet passe dans une pile, échoue dans une autre, puis le tableau de bord réduit le désaccord à « support variable ».

Les octets de clé ne sont pas laissés à l’intuition. La clé publique est PK.seed || PK.root, sur 2*n octets, avec n égal à 16, 24 ou 32. SubjectPublicKeyInfo place directement ces octets dans son BIT STRING, sans nouvelle enveloppe ASN.1. La clé privée concatène SK.seed || SK.prf || PK.seed || PK.root, soit 4*n octets, dans le champ privateKey de OneAsymmetricKey.

OneAsymmetricKey peut aussi embarquer la clé publique. Cela permet de vérifier la cohérence de la paire, mais le RFC avertit que certaines fonctions d’importation ne reconnaissent pas encore cette forme. Le responsable doit donc mesurer deux propriétés opposées : contrôle de cohérence local et largeur de compatibilité à l’import. Le standard décrit le choix ; il ne prouve pas le comportement d’un HSM ou d’un magasin de clés.

L’extension keyUsage impose elle aussi de garder les rôles séparés. Lorsqu’elle est présente, elle doit autoriser au moins une fonction de signature parmi digitalSignature, nonRepudiation, keyCertSign et cRLSign. Elle ne doit pas annoncer keyEncipherment, dataEncipherment, keyAgreement, encipherOnly ou decipherOnly. SLH-DSA signe ; ce n’est pas un mécanisme d’établissement de clé. Les règles plus larges du RFC 5280 continuent de s’appliquer.

Un keyUsage conforme ne valide toutefois ni le chemin, ni la révocation, ni le nom du sujet, ni l’autorisation métier. Il prouve seulement qu’une partie du profil n’est pas contradictoire. De même, une signature valide prouve un calcul sous une clé acceptée comme entrée ; elle n’accorde pas d’elle-même la confiance à cette clé.

Le choix Pure/Hash doit être effectué avant l’émission d’un certificat d’AC. En mode Pure, le message préparé entier entre dans l’opération. HashSLH-DSA réduit ce passage par un préhachage spécifié. Le RFC indique que le message interne est parcouru deux fois et doit tenir en mémoire. Une grande CRL ou un certificat contenant de nombreux subject alternative names peut dépasser la capacité de transfert ou de mémoire d’un module externe.

Le vérificateur subit une contrainte symétrique : pour les certificats et CRL, il doit conserver l’objet entier, car un aléa extrait de la signature est traité avant le message alors que l’encodage place la signature après celui-ci. La vérification ne devient donc pas spontanément un flux à passage unique. HashSLH-DSA réduit la taille interne conservée, sans certifier une implémentation donnée.

Le RFC 9814 montre pourquoi le contexte applicatif compte. Pour CMS SignedData, il spécifie seulement le mode Pure et permet aux attributs signés de réduire la valeur transmise au signataire. Cette convention voisine ne peut pas être réutilisée comme preuve que certificats et CRL suivent le même chemin. Un algorithme commun ne fusionne pas deux profils.

« Stateless » ne signifie pas « sans limite ». Le RFC 9909 interdit de dépasser 2^64 signatures avec un arbre et recommande de compter les opérations ou de borner la durée de vie si ce plafond devient concevable. Les paires doivent être générées indépendamment ; protection de la clé privée, aléa de qualité, résistance aux fautes et aux canaux auxiliaires restent nécessaires.

Même la correction documentaire possède plusieurs états. La page d’errata du RFC 9909 recensait deux entrées lors du gel des preuves. Toutes deux étaient Reported, pas Verified. Un signalement peut déclencher une revue ; il ne remplace pas silencieusement le texte normatif.

Le reçu opérationnel devrait conserver le DER d’origine et son empreinte, les OID de clé et de signature, l’absence ou la présence de paramètres, les longueurs, l’enveloppe, keyUsage, le contexte, la chaîne, les données de révocation, les versions du validateur et du fournisseur cryptographique, puis trois résultats séparés : signature, chemin, politique applicative. Un éventuel repli est encore un autre événement.

La primauté du code en fonctionnement formulée par Heng Lu exige ce passage du symbole au résultat observé. La spécification initiale minimale maintient le contrat commun assez mince pour rester testable. Les couches de réalité empêchent enfin de confondre enregistrement d’un nom, reconnaissance syntaxique, validité cryptographique et pouvoir d’agir.

Le RFC 9909 ne promet pas qu’un certificat « post-quantique » fonctionnera. Il fournit une meilleure chose : la frontière exacte où chaque affirmation peut être réfutée. L’OID coordonne un sens. Les octets réalisent un objet. Le parseur reconnaît. Le profil contrôle. La cryptographie vérifie. Le chemin établit une confiance limitée. La politique décide. Aucun voyant ne peut parler au nom des six autres.

Sources