Résumé

  • Le RFC 9955, document informatif de l’IETF publié en juillet 2026, montre que les propriétés d’une signature hybride forment plusieurs spectres. Compatibilité ancienne, infalsifiabilité hybride, non-séparabilité forte, vérification simultanée, performance et facilité d’homologation ne peuvent pas toujours être obtenues ensemble.
  • Une signature identique peut donner une garantie hybride au vérificateur qui contrôle toutes ses composantes et une garantie classique seulement au système ancien qui en ignore une. Le nombre de signatures hybrides émises ne mesure donc pas la protection effectivement appliquée au point de décision.
  • Un reçu de vérification hybride devrait conserver, sans secret, l’objet contrôlé, les résultats de chaque composante, l’emplacement de l’indice d’intention hybride, les clés et leurs usages, la version du vérificateur, la politique d’acceptation, la portée de l’homologation et l’échéance de toute exception. Il s’agit d’une proposition de pratique locale, non d’une exigence du RFC 9955, de l’IETF ou du NIST.

La garantie vieillit avec son contexte

Les signatures à longue durée de vie ont une particularité : elles seront souvent relues par un système qui n’existait pas au moment de leur création. Le document, son empreinte et ses signatures peuvent être conservés parfaitement, tandis que la politique de vérification disparaît. Une ligne de journal indiquant valid ne dit pas si deux algorithmes ont été contrôlés, si une chaîne de certificats portait l’intention hybride, ni si une exception de compatibilité autorisait l’abandon d’une composante.

Le RFC 9955 fournit le vocabulaire qui manque à cette ligne de journal. Ce texte de consensus de l’IETF est informatif : il ne choisit pas de combinaison concrète, n’impose pas une migration sectorielle et ne crée aucune inscription IANA. Il classe plutôt les objectifs et les compromis. Une signature hybride peut chercher à rester sûre tant qu’une composante résiste, à empêcher la séparation des composantes, à servir des lecteurs anciens, à être vérifiée en une seule décision ou à réutiliser des modules déjà homologués. Ces qualités ne se déduisent pas les unes des autres.

La première conséquence de gouvernance est temporelle. Conserver l’objet signé ne suffit pas. Il faut aussi conserver la décision du vérificateur qui lui a donné effet.

« Hybride » décrit une construction, pas toujours l’acceptation

Le RFC distingue nettement l’émission et la vérification. La compatibilité ascendante vers les anciens systèmes est une propriété du côté du vérificateur. L’émetteur peut avoir produit deux signatures sur le même message. Un logiciel récent les contrôle toutes les deux ; un lecteur ancien ne valide que la composante traditionnelle. Pour le premier, l’infalsifiabilité peut dépendre du fait qu’au moins une composante reste sûre. Pour le second, la décision repose sur celle qu’il connaît.

Les deux logiciels reçoivent pourtant les mêmes octets. Un registre de migration centré sur l’émetteur affichera « hybride » dans les deux cas. Un registre centré sur la décision montrera deux niveaux d’assurance.

Ce n’est pas une anomalie que le RFC prétend interdire. Les infrastructures critiques, les racines de confiance et les archives ne changent pas d’un seul geste. La compatibilité peut être un choix raisonnable. Mais le RFC précise son prix : la compatibilité ancienne et la non-séparabilité forte s’excluent. Une construction fortement non séparable doit échouer si l’on retire une composante ; un lecteur ancien a justement besoin de pouvoir accepter ce qui lui reste intelligible. Et quand ce lecteur saute effectivement une composante, l’infalsifiabilité hybride n’est plus la propriété de cette vérification.

La politique honnête ne consiste donc pas à bannir toute exception. Elle consiste à nommer la population concernée, l’assurance abandonnée, le responsable et la date de fin.

Où se trouve la preuve d’intention ?

Le mot « artefact » désigne, dans le RFC 9955, la trace de l’intention hybride qui demeure lorsqu’une composante est retirée. La position de cette trace détermine l’acteur dont dépend la détection.

Elle peut être incluse dans la signature elle-même, donc au niveau algorithmique. Elle peut se trouver dans un certificat ou dans la négociation d’algorithmes, donc au niveau du protocole. Elle peut enfin être un libellé du message, donc relever de la politique applicative.

Dans le dernier cas, le contrôle présente une circularité délicate. L’authenticité du message dépend de la signature, mais l’interprétation de la signature dépend d’un texte du message indiquant que deux composantes étaient exigées. Le vérificateur doit être autorisé à lire cet indice et programmé pour lui donner un effet. S’il l’ignore, la trace existe encore pour l’enquête, sans provoquer nécessairement l’échec cryptographique.

C’est l’idée de non-séparabilité faible : la séparation laisse une trace, mais une composante isolée peut encore être valide. La non-séparabilité forte déplace la conséquence dans la construction : aucune signature de composante exploitable ne peut être extraite. La vérification simultanée ajoute une contrainte d’exécution : un vérificateur normal ne peut annoncer le succès d’une composante puis s’arrêter avant de connaître le résultat de l’autre.

Un certificat combiné déplace encore la responsabilité. Il élimine certaines ambiguïtés du message, mais fait dépendre le raisonnement de la provenance des clés et de toute la chaîne pertinente. Une configuration locale la déplace vers l’exploitation. Dans ces deux situations, l’algorithme seul ne peut pas raconter la garantie.

Ainsi, le nom commercial d’un mécanisme, ou même le mot « concaténé », reste insuffisant. Il faut savoir où demeure l’intention et comment le vérificateur la traite.

La réutilisation des clés agrandit la frontière

Une composante séparée peut viser un autre vérificateur que le destinataire prévu. Le même matériel de clé peut être accepté par une autre application ou un autre protocole. Imposer la vérification des deux composantes dans le service principal ne ferme donc pas automatiquement cette autre porte.

Le RFC 9955 décrit une réponse possible : interdire la réutilisation des clés de composante et préciser les usages permis dans les certificats. Mais il classe correctement cette réponse. C’est une obligation de politique, non une garantie cryptographique. Sa solidité dépend de toutes les entités susceptibles d’utiliser ces clés.

L’inventaire pertinent n’est plus seulement celui des algorithmes. Il relie la clé publique, le certificat, les protocoles, les vérificateurs, leurs versions et leurs règles d’acceptation. Une équipe ne peut pas vérifier son application centrale, ignorer le reste du parc et déclarer la séparation impossible.

Le miroir entre politique et système réel devient ici très concret. Une phrase d’architecture telle que « ces clés ne servent qu’au mode hybride » vaut exactement ce que valent les contrôles qui l’imposent sur l’ensemble de la population.

L’homologation répond à une autre question

Les projets post-quantiques rencontrent aussi un impératif administratif : employer des algorithmes et modules approuvés. Cette contrainte est légitime, mais elle ne doit pas absorber le raisonnement de sécurité.

Le RFC 9955 place le besoin d’homologation sur un spectre séparé. Une construction fusionnée peut offrir une non-séparabilité forte ou une vérification simultanée, tout en exigeant une analyse et une validation nouvelles. À l’inverse, une enveloppe qui appelle des modules de composante comme des boîtes noires peut conserver plus facilement leur statut existant, sans acquérir par ce fait les propriétés de la fusion.

La FAQ post-quantique du NIST indique que la vérification d’une double signature exige le succès de toutes les composantes et que les normes actuelles peuvent l’accueillir lorsqu’au moins un algorithme de composante est approuvé. FIPS 204 normalise séparément ML-DSA. Ces affirmations ont une portée précise. Elles ne permettent pas de transformer le statut d’un module en homologation indifférenciée de toute la promesse hybride, de la politique de clés et du comportement du vérificateur.

Une organisation peut choisir la facilité de validation et accepter davantage de dépendances de politique. Elle doit simplement l’écrire comme tel.

Le reçu de la vérification réelle

L’objet signé contient déjà les signatures. Le dossier d’exploitation doit conserver autre chose : la preuve de ce que le point d’acceptation a contrôlé.

Un reçu de vérification hybride devrait lier :

  1. l’empreinte de l’objet, son contexte, la construction hybride et sa version attendue ;
  2. les algorithmes de composante, les identifiants publics non secrets des clés et les chaînes de provenance réellement validées ;
  3. l’emplacement de chaque artefact d’intention hybride et la confirmation que le vérificateur pouvait le lire ;
  4. le vecteur de résultats exigé, le résultat observé de chaque composante et la décision finale ;
  5. la propriété recherchée — non-séparabilité faible ou forte, vérification simultanée — et la preuve que l’exécution la respectait ;
  6. la version du logiciel, l’empreinte de configuration et la révision de politique ;
  7. les restrictions d’usage des clés et la population sur laquelle elles sont effectivement appliquées ;
  8. le statut d’homologation rattaché au composant ou au module exact qu’il couvre ;
  9. la cohorte de réception, l’éventuelle exception ancienne, son propriétaire et son échéance ;
  10. le traitement des erreurs et la possibilité qu’un résultat partiel influence la décision ;
  11. l’heure du contrôle, la durée de conservation et le déclencheur d’une nouvelle vérification ;
  12. l’autorité capable de rejeter, mettre en quarantaine ou annuler l’acceptation si la garantie ne peut être reproduite.

Ce reçu reste sans secret. Il conserve des empreintes, des versions, des identifiants bornés et des références vers des journaux protégés, jamais une clé privée ni le contenu confidentiel du document. Il ne transforme pas une combinaison fragile en construction robuste. Il empêche une preuve pauvre d’autoriser une affirmation riche.

Le test qui mérite d’être acheté

Avant une bascule, il faut soumettre un corpus identique à chaque famille réelle de vérificateurs. Le test doit inclure l’absence de chaque composante, l’échec de la première puis de la seconde, la modification des artefacts, une chaîne de certificats différente et une tentative d’utiliser une clé de composante dans un autre contexte accepté.

Le rapport ne doit pas seulement noter succès ou échec. Il doit indiquer quelles opérations ont eu lieu, dans quel ordre, sous quelle politique et avec quelle information révélée. On peut alors confronter la preuve à la formulation de la promesse.

« Tous les émetteurs produisent deux signatures » est mesurable. « Tous les destinataires importants vérifient les deux » en est une autre. « La construction est fortement non séparable » en est une troisième. « Un composant est homologué » en est une quatrième. Le principe de spécification initiale minimale impose de ne pas les réunir avant que le dossier ne montre les jointures.

Limites

Aucune attaque par retrait de signature, aucune défaillance de produit et aucun marché public fautif ne sont rapportés ici. Les sources décrivent des normes et des compromis, pas leur fréquence de déploiement. La non-séparabilité forte n’est pas présentée comme le choix universel ; elle peut coûter la compatibilité et compliquer l’homologation. Un reçu n’anticipe pas les découvertes cryptanalytiques futures.

Il préserve seulement une vérité souvent perdue : le jour où l’objet a été accepté, quel vérificateur a accordé quelle confiance, et pourquoi.

Sources