Résumé

  • La révision 05 de draft-ietf-openpgp-nist-bp-comp affirme avoir remplacé les identifiants expérimentaux 100–107 par 37–44. Le registre IANA consulté le 1er octobre 2026 affichait encore 37–99 comme non attribués. Il s’agit d’un constat daté, non d’une preuve sur l’issue du processus d’attribution.
  • Les huit constructions sont facultatives. Reconnaître le nombre ne prouve ni le support, ni l’activation, ni la bonne version de clé, ni l’exécution complète.
  • Une signature composite n’est valide que si ECDSA et ML-DSA réussissent. Un KEM composite exige les deux calculs, la validation complète du point elliptique, le bon contexte de combinaison et un déballage AES-256 intègre.

Le premier gel doit porter sur le sens du nombre

Avant d’examiner une performance ou un calendrier de migration, le comité devrait geler quatre objets : la page du registre, la révision du texte, le jeu de vecteurs et la version du logiciel. Sans cet ensemble, un journal qui dit « algorithme 41 » reste ambigu.

Le texte de la révision 05 explique que les valeurs expérimentales 100 à 107 ont été remplacées par les valeurs 37 à 44, présentées comme attribuées. Les rendus HTML et XML décrivent les mêmes associations et les vecteurs régénérés. Pourtant, le registre OpenPGP de l’IANA, figé pour cette enquête le 1er octobre, inscrivait encore « Unassigned » pour 37–99.

Le seul énoncé défendable est donc temporel : ces deux surfaces publiques n’étaient pas encore alignées au moment de la capture. On ne sait pas, à partir de ces pages, si une mise à jour était en attente, si le texte anticipait une décision ou si une autre étape administrative s’appliquait. Il serait tout aussi imprudent d’annoncer une attribution que d’affirmer un refus.

Le statut du document impose la même retenue. Sa fiche Datatracker le présentait comme un Internet-Draft actif du groupe OpenPGP, daté du 24 septembre 2026. L’API documentaire ne donnait pas de statut RFC visé, alors que l’en-tête du brouillon disait Informational. L’historique indiquait qu’une version révisée restait nécessaire avant le feu vert de la présidence. Ce n’est ni un RFC ni une norme approuvée.

Une table de huit lignes cache plusieurs décisions

Les valeurs 37 à 40 désignent quatre KEM : ML-KEM-768 avec ECDH P-384, ML-KEM-1024 avec ECDH P-521, puis les mêmes niveaux ML-KEM avec brainpoolP384r1 et brainpoolP512r1. Les valeurs 41 à 44 désignent quatre signatures associant ML-DSA-65 ou ML-DSA-87 à ECDSA sur ces courbes NIST ou Brainpool.

Dans le brouillon, chaque algorithme est un MAY. Une bibliothèque peut en choisir un seul ; une politique peut refuser Brainpool ; un équipement peut connaître le code sans disposer du fournisseur cryptographique ; une application peut accepter une clé mais refuser son usage. L’identité numérique fixe une composition et des longueurs, pas son déploiement.

Les objets doivent en outre être de version 6 ou ultérieure. Les signatures composites exigent une signature v6 ou plus récente et un condensat d’au moins 256 bits. Le cadre de paquets et de clés vient de RFC 9580. Les briques ML-KEM, ML-DSA et le combinateur multi-clés utilisé par le nouveau texte sont introduits dans RFC 9980. Une trace sérieuse conserve donc le numéro, la version de l’objet, le condensat, les longueurs et la version du parseur.

Le KEM ne se résume pas au déballage final

Côté chiffrement, le logiciel exécute ECDH et encapsule avec ML-KEM. Il injecte les deux secrets partagés, le point éphémère ECDH, la clé publique ECDH et l’identifiant d’algorithme dans multiKeyCombine. La clé obtenue sert ensuite à envelopper la clé de session avec AES-256 key wrap.

Côté réception, il faut relier l’identifiant du PKESK à celui de la clé secrète locale, découper les composants aux longueurs exactes, exécuter les deux décapsulations, reconstruire le contexte, puis vérifier l’intégrité de 64 bits du déballage. Avec un PKESK v3, l’algorithme symétrique reste en clair à côté de la clé enveloppée ; la longueur déballée doit lui correspondre, sinon le traitement s’arrête.

FIPS 203 définit ML-KEM et SP 800-56A révision 3 encadre l’établissement traditionnel par courbe elliptique. La réussite du déballage se situe à la fin de cette chaîne. Elle ne dit pas, à elle seule, que chaque contrôle en amont a eu lieu. Le reçu KEM doit distinguer l’analyse, la validation EC, les deux calculs, les entrées du combinateur et le verdict d’intégrité.

Le point elliptique est une entrée hostile

La révision 04 a explicité un contrôle particulièrement important. Les courbes NIST et Brainpool employées sont sous forme de Weierstrass courte. Avant toute multiplication par un scalaire secret, le point reçu doit être validé complètement : il ne doit pas être le point à l’infini, ses coordonnées doivent appartenir au corps et il doit satisfaire l’équation de la courbe.

Cette règle vaut pour la clé publique ECDH du destinataire pendant l’encapsulation et pour le point éphémère reçu pendant la décapsulation. Le défaut impose l’abandon. Le texte avertit qu’un point hors courbe choisi par un attaquant peut conduire à une attaque de courbe invalide et à la récupération du secret ECDH.

Le socle classique est documenté par FIPS 186-5, les courbes recommandées de SP 800-186, les courbes Brainpool de RFC 5639 et les règles de validation de SEC 1 version 2. Une longueur correcte ne prouve aucune de ces propriétés. Il faut enregistrer le type de courbe, la routine et ses trois verdicts, sans jamais exposer le scalaire.

Pour la signature, « composite » signifie ET

Une signature contient un résultat ECDSA et un résultat ML-DSA sur le condensat OpenPGP. Les deux doivent être valides. Si ECDSA réussit mais que ML-DSA est absent, non pris en charge ou incorrect, le composite échoue. La conclusion est identique lorsque les rôles sont inversés.

Le parseur doit connaître les longueurs fixes de R et S propres à la courbe ainsi que les 3 309 octets de ML-DSA-65 ou les 4 627 octets de ML-DSA-87. FIPS 204 définit ML-DSA ; RFC 9794 fournit le vocabulaire plus général des constructions hybrides traditionnelles et post-quantiques. Aucun des deux ne transforme un verdict partiel en verdict composite.

Les nouveaux vecteurs de signature détachée sont donc utiles pour reproduire l’encodage et les calculs. Ils ne prouvent ni l’identité du signataire réel, ni son autorisation, ni la provenance de la clé, ni la décision de l’application. Ces décisions doivent rester séparées dans la télémétrie.

Le constat ne porte sur aucun produit

Les vingt sources de ce dossier ne démontrent l’adoption, les performances, l’interopérabilité, un paquet observé, un incident ou une vulnérabilité dans un produit nommé. Elles décrivent un mécanisme en cours de travail et les standards adjacents. La révision peut changer ; le registre peut évoluer ; les implémentations peuvent retenir zéro ou plusieurs options.

La preuve minimale reste donc composée : capture du registre, identité exacte du brouillon, reçu de parse, validation du point EC, résultat de chaque primitive, contexte du combinateur ou du condensat, puis décision de politique. Un test réussi n’est pas un recensement du parc.