Résumé

  • L’IESG a ouvert le 26 septembre le vote d’approbation de la version 05 du projet destiné à succéder à RFC 9180 et l’a inscrite à sa réunion du 8 octobre. La procédure est en cours, sans décision de publication.
  • Le projet spécifie Base 0x00 et PSK 0x01, mais réserve 0x02 et 0x03, valeurs attribuées à Auth et AuthPSK dans RFC 9180. Cette différence figurait déjà dans la version 04.
  • Le registre IANA conserve néanmoins un champ Auth pour les interfaces de RFC 9180. Ce champ décrit une possibilité du KEM, pas l’usage réel d’une application ni la preuve qu’une dépendance ancienne a disparu.

Deux applications peuvent annoncer « HPKE » et ne pas demander la même chose au destinataire. L’une chiffre simplement vers sa clé publique ; l’autre entend vérifier que l’expéditeur possède une clé asymétrique donnée. C’est pourquoi l’arrivée d’un successeur de RFC 9180 devant l’IESG ne peut pas être lue comme une simple mise à jour bibliographique. Elle oblige à séparer les fonctions communes qui doivent rester compatibles des fonctions que le nouveau texte choisit de ne plus définir.

La table des modes fournit le repère le plus net. RFC 9180 donnait quatre valeurs : Base, PSK, Auth et AuthPSK. La version 05 du projet du groupe HPKE garde les deux premières et marque les deux autres comme réservées. Son annexe affirme que les comportements spécifiés dans les deux documents doivent être identiques, puis cite explicitement le retrait d’Auth et d’AuthPSK parmi les différences. La compatibilité porte donc sur le périmètre partagé, pas sur l’ensemble de l’ancienne API.

Le mode PSK authentifie la possession d’un secret prépartagé ; il ne reproduit pas, par son seul nom, la preuve liée à la clé privée de l’émetteur dans les anciens modes.

Il faut également respecter la chronologie. La suppression n’a pas été introduite le 25 septembre avec la version 05 : la version 04 présentait déjà les mêmes valeurs réservées. Ce qui change à présent est l’état institutionnel du texte. Après le dépôt de la nouvelle version le 25 septembre, l’IESG a créé son vote le lendemain, lancé l’évaluation et fixé une discussion au 8 octobre. Le dossier indique encore des positions à recueillir et un réexamen IANA à effectuer. La formule « remplace RFC 9180 » dans le projet reste conditionnelle à son approbation et à sa publication.

Le responsable du suivi du document, Martin Thomson, avait décrit en mars le choix du groupe comme une concession. Selon sa note, les déploiements des anciens modes sont limités et un support postquantique adapté à leur conception actuelle manque encore. Mais il reconnaît aussi des utilisateurs de ces fonctions et parle d’un report plutôt que d’une dépréciation, avec la possibilité de les rétablir plus tard. Il ne fournit pas un inventaire vérifié des services concernés. On ne peut donc ni annoncer une rupture générale, ni effacer ces utilisateurs d’un trait de plume.

Le traitement du registre le montre presque matériellement. Le projet propose de mettre à jour les références IANA sans changer les identifiants KEM existants. Dans le modèle d’inscription d’un KEM, le booléen Auth reste présent pour AuthEncap() et AuthDecap() de RFC 9180 ; la nouvelle spécification dit ne pas l’utiliser. Il s’agit d’une trace de compatibilité avec l’ancienne interface, pas d’une mesure du trafic ou d’une instruction d’activer Auth dans le futur texte. La référence et le code restent lisibles ; le contrat de l’application, lui, doit être examiné ailleurs.

Daniel Kade recommande donc un contrôle circonscrit par intégration : document et mode effectivement appelés, propriété d’identité attendue, capacité du correspondant, décision de conserver l’ancienne interface ou de redéfinir l’authentification dans le protocole supérieur, puis test des deux extrémités. Ce registre de décision est une proposition éditoriale, non une obligation fixée par l’IETF. Il évite qu’une mise à niveau de bibliothèque paraisse réussie parce que le chiffrement fonctionne, alors que l’assurance demandée à l’expéditeur n’a pas été vérifiée.

Sources