Résumé

  • Le dernier appel du groupe OpenPGP sur draft-ietf-openpgp-nist-bp-comp-04 devait se terminer le 9 septembre 2026. Le texte reste un Internet-Draft actif, de statut visé Informational, et non une décision finale de l’IETF.
  • La révision 04 emploie 100–107 à titre expérimental. Une proposition, des branches de code et de nouveaux vecteurs utilisent 37–44, mais le registre IANA consulté classe encore 37–99 comme non attribués.
  • Pour les KEM composites, l’identifiant d’algorithme entre dans multiKeyCombine. Le renuméroter modifie la clé de chiffrement dérivée et les éléments enveloppés; pour les signatures, les octets du paquet et les empreintes changent aussi.
  • Un résultat d’interopérabilité devrait être accompagné d’un reçu d’état indiquant révision, numéro exact, commit, hash des vecteurs, version de l’implémentation et état du registre.

Le dernier appel du groupe de travail a commencé le 19 août, avec une échéance fixée au 9 septembre. Une échéance échue ne dit pas quelle suite le groupe lui a donnée. La fiche Datatracker capturée maintient le document au stade In WG Last Call et l’IESG au stade I-D Exists; elle ne mentionne ni rapporteur, ni directeur de zone responsable, ni téléconférence. L’historique du document confirme la séquence administrative, pas une approbation.

Le fond du texte est une manière d’associer des algorithmes NIST post-quantiques à des algorithmes classiques sur courbes elliptiques dans OpenPGP. La révision 04 décrit quatre KEM composites et quatre schémas de signature composites, tous facultatifs. Elle leur réserve les identifiants 100 à 107, une plage privée ou expérimentale. Elle précise que ces valeurs servent aux logiciels non diffusés et aux essais d’interopérabilité, qu’elles ne doivent pas figurer dans une version formellement publiée et que le document ne sera pas transmis à l’IANA avant que chaque algorithme dispose d’un identifiant non expérimental.

La branche avance avant le registre

Une proposition adressée au groupe aligne les huit combinaisons sur 37 à 44. Dans sa réponse, Daniel Kahn Gillmor juge le plan plausible, tout en demandant aux développeurs de conserver les numéros expérimentaux tant qu’une révision publiée du projet n’en contient pas d’autres. La nuance est essentielle: elle autorise le travail préparatoire sans faire passer une anticipation pour la référence commune.

La pull request 50 montre ce travail préparatoire. Au moment de la capture, elle est ouverte, non marquée comme brouillon et non fusionnée. Son commit de tête est 577adce5255e7382e5d4b0c9e52be626deb77126. Sur 27 fichiers, elle remplace 100–107 par 37–44 et régénère empreintes, sorties KEM et vecteurs de test.

Le langage des équipes va déjà plus vite que l’état public. Un message des auteurs présente des vecteurs fondés sur des points qualifiés d’« attribués ». Un compte rendu concernant rPGP indique que l’implémentation est passée à 37–44 et concorde avec ces vecteurs, mais que la mise à jour de la suite d’interopérabilité attend la confirmation des numéros. La merge request 255 matérialise cette prudence: elle est ouverte, en brouillon, non fusionnée, et son descriptif demande d’attendre l’attribution officielle.

Le numéro n’est pas extérieur à la cryptographie

Dans le mécanisme KEM composite, l’implémentation lit l’identifiant d’algorithme dans le paquet de clé publique, puis transmet cette valeur comme algId à multiKeyCombine. La clé de chiffrement de clé obtenue sert ensuite à envelopper le matériel de clé de session. Si l’émetteur emploie 37 et le destinataire 100, ils ne dérivent pas la même valeur, même si leurs composantes ML-KEM et ECDH sont par ailleurs identiques.

Les combinaisons de signatures connaissent une conséquence voisine. Le numéro étant encodé dans les paquets OpenPGP, sa modification change les octets à partir desquels sont calculées empreintes et autres pièces reproductibles. Les primitives ML-KEM, ECDH et de signature ne deviennent ni plus fortes ni plus faibles du seul fait du renumérotage. C’est leur liaison au protocole qui change — et les vecteurs régénérés en sont la trace vérifiable.

Trois vérités, à trois horloges

Le registre OpenPGP de l’IANA capturé, daté du 2 juillet 2026, attribue 35 et 36 au RFC 9980, laisse 37 à 99 non attribués et réserve 100 à 110 aux usages privés ou expérimentaux. Dire « attribué » dans une discussion de développement décrit donc ici une destination attendue ou un état de branche, pas encore la ligne publique du registre.

Le RFC 9580 fournit le cadre moderne des paquets OpenPGP et de leurs registres. Le RFC 8126 fixe le vocabulaire des politiques d’attribution. Leur leçon institutionnelle est sobre: la proposition, le commit, le consensus du groupe et l’enregistrement IANA sont des actes distincts. Un enregistrement ne certifie ni la sécurité ni le déploiement; une case encore vacante n’annule pas non plus la valeur d’un essai de laboratoire.

Un reçu d’état des algorithmes peut réconcilier ces horloges. Il doit nommer la révision du document et son statut, le numéro expérimental publié, le numéro proposé en branche, l’état et le commit de la PR ou MR, la ligne IANA et sa date d’observation, le hash du jeu de vecteurs, le build de l’implémentation, le numéro réellement exécuté et l’éligibilité à une diffusion formelle. Un ancien vecteur reste alors une preuve valable de l’ancien état, et non un fichier mystérieusement devenu « faux ».

Sources