Résumé

  • RFC 9955 décrit des objectifs de conception pour les signatures hybrides ; plusieurs composants transmis ne démontrent pas que tout récepteur les a tous vérifiés.
  • La compatibilité ascendante peut autoriser un seul contrôle ; la non-séparabilité forte et la vérification simultanée exigent une construction et un comportement plus précis.

Un message porte une signature classique et une signature post-quantique. Un journal peut correctement indiquer « signature hybride reçue ». Mais ce journal ne dit pas encore quelle règle le récepteur a appliquée. A-t-il imposé les deux contrôles ? A-t-il emprunté un chemin de compatibilité pour un vérificateur ancien ? A-t-il conservé un artefact permettant une revue ultérieure ? Ce sont des faits différents, détenus par des systèmes et des responsables différents.

RFC 9955, RFC IETF Informationnel publié en juillet 2026, ne choisit ni combinateur universel ni déploiement. Il classe les propriétés qu’un schéma de signature numérique hybride peut rechercher : authentification hybride, composabilité des preuves, degrés de non-séparabilité, compatibilités et vérification simultanée. Le document insiste ainsi sur les compromis que le mot « hybride » rend trop facilement invisibles.

Une signature hybride est multi-algorithme. Le RFC examine l’idée qu’une propriété d’authenticité puisse demeurer lorsqu’au moins un composant reste sûr, selon la propriété effectivement revendiquée par le schéma. Cette idée ne transforme pas le nombre de composants envoyés en preuve d’un résultat identique chez tous les destinataires. L’émetteur produit une structure ; le récepteur conserve sa politique, son implémentation et la trace de ses contrôles.

La séparation rend cette frontière concrète. Un artefact est une preuve de l’intention d’hybrider qui peut subsister après le retrait d’un composant. Avec la non-séparabilité faible, un composant séparé peut encore vérifier, tandis qu’un artefact dans le message, le protocole, le certificat ou la politique permet d’identifier la séparation après examen. C’est une information précieuse, non un échec automatique de vérification. Avec la non-séparabilité forte, la séparation fait échouer la vérification du composant.

Le compte rendu doit donc nommer la propriété réellement fournie, plutôt que conclure à partir de deux blocs de signature visibles.

La compatibilité avec les anciens récepteurs rend le point opérationnel. RFC 9955 décrit la possibilité de ne vérifier qu’un composant, généralement classique, et d’ignorer le composant post-quantique. Ce peut être un choix de transition légitime ; ce n’est pas la preuve que tous les récepteurs ont exécuté deux vérifications. La vérification simultanée va plus loin : les informations des deux composants doivent être présentes et un vérificateur honnête ne peut réussir après le seul premier contrôle. Elle ne protège pas contre un vérificateur volontairement conçu pour contourner les contrôles.

Il faut aussi garder les périmètres techniques distincts. RFC 9954 porte sur l’échange de clés hybride dans TLS 1.3, tandis que RFC 9955 traite du spectre des signatures numériques. RFC 9794 fournit un vocabulaire ; aucun de ces textes n’atteste le comportement d’un déploiement nommé.

Daniel Kade emploie les couches de réalité de docs/heng-lu-note.md comme discipline éditoriale, non comme norme IETF. Conserver séparément l’entrée signée, le schéma déclaré, la version de politique du récepteur, les résultats par composant, l’exception de compatibilité, la décision d’acceptation et une observation d’audit empêche un champ commode de se faire passer pour un verdict de sécurité.

Sources