Résumé

  • draft-ietf-hpke-hpke-05, actuellement en évaluation par l’IESG, garde Base 0x00 et PSK 0x01, puis réserve les valeurs 0x02 et 0x03 attribuées par RFC 9180 à Auth et AuthPSK.
  • Cette décision dessine un prochain socle commun ; elle ne certifie ni la disparition du code ancien, ni la migration des profils applicatifs, des objets conservés et des contreparties.

Un responsable de migration peut entourer deux lignes dans une table et croire avoir trouvé son plan de retrait. Dans RFC 9180, les quatre lignes sont Base, PSK, Auth et AuthPSK. Dans la révision 05 du projet IETF, les deux dernières portent désormais la mention « RESERVED ».

Le changement est précis. Son effet opérationnel ne l’est pas automatiquement. Une table de spécification ne connaît ni l’image réellement chargée dans un service, ni une bibliothèque incorporée statiquement, ni le contenu d’une file de reprise, ni le protocole privé d’un partenaire.

La nouvelle norme peut fixer une destination. Pour affirmer que l’ancien chemin est éteint, il faut un registre de preuves issu des systèmes qui l’exécutaient.

Le statut du texte impose déjà une première limite

Datatracker présente la révision 05 comme un Internet-Draft actif du groupe HPKE, daté du 26 septembre 2026. Le document vise le statut Proposed Standard, a été soumis à l’IESG et figure à l’ordre du jour de la téléconférence du 8 octobre. L’examen IANA doit encore être repris après le changement de version.

Son en-tête dit qu’il rendrait RFC 9180 obsolète s’il était approuvé. Cette condition interdit d’écrire au présent ce que le processus n’a pas encore achevé. Le texte n’est pas un RFC ; les sources gelées ne montrent ni décision finale de l’IESG ni publication par le RFC Editor.

La suppression des modes n’est d’ailleurs pas née avec la révision 05. La révision 04, publiée en juillet, présentait déjà la même table. L’actualité est le passage de cette architecture dans le texte actuellement évalué, non une invention de septembre.

RFC 9180 est un RFC informatif de l’IRTF. Son successeur candidat cherche un consensus IETF de niveau Proposed Standard. Cette différence de filière compte pour la gouvernance du futur socle. Elle ne constitue pas un relevé des installations existantes.

La compatibilité annoncée s’arrête là où le texte s’arrête

L’annexe A formule une promesse limitée : lorsque RFC 9180 et le nouveau projet spécifient tous deux un comportement, ce comportement doit rester identique. Base et PSK se trouvent dans cette intersection.

Auth et AuthPSK n’y sont plus. RFC 9180 leur attribue 0x02 et 0x03 ; le projet réserve ces valeurs et classe leur retrait parmi les changements majeurs. Dire simplement que le nouveau texte est rétrocompatible efface précisément l’exception qui exige une migration.

Même dans la zone commune, compatibilité ne veut pas dire extinction. Un vecteur d’essai prouve qu’une suite et des entrées données produisent le même résultat. Il ne prouve pas que tous les appelants utilisent la nouvelle API, que les processus ont redémarré, que les exceptions de locataire sont fermées ou que les archives sont relisibles.

La preuve doit donc porter le nom du profil, de l’implémentation et du chemin testé. Une coche « HPKE compatible » est trop large pour piloter une coupure.

Le mode appartient au contexte de l’application

HPKE n’est pas une enveloppe universelle et autosuffisante. Le projet laisse à l’application le transport de paramètres non secrets comme enc et psk_id. Si le destinataire possède plusieurs clés, l’application doit aussi lui indiquer laquelle utiliser.

Le mode et la suite cryptographique sont choisis par ce contexte. Il n’existe pas un en-tête HPKE unique que l’on pourrait balayer dans tous les flux et toutes les bases pour compter les usages Auth. Une application peut sélectionner un appel d’API ; une autre peut fixer le mode dans un profil ; une troisième peut le déduire d’une version d’objet.

Cette diversité déplace le travail d’inventaire. Il faut relier le manifeste de dépendances au binaire chargé, le binaire à sa configuration, la configuration au profil applicatif, puis le profil à une observation ou à un corpus de test. Sans ce lien, un symbole dans le code ne prouve pas un usage, et un paquet chiffré ne révèle pas nécessairement le chemin de configuration qui l’a produit.

La présence et l’absence ont donc toutes deux besoin d’un périmètre. « Aucun appel Auth observé » n’a de sens qu’avec des points de capture nommés, une durée et la couverture des chemins dormants.

Six reçus au lieu d’une déclaration

Le dossier de retrait peut être construit en six colonnes indépendantes.

Le reçu de norme fixe le document, sa révision et son état de procédure. Le reçu de dépendance identifie le paquet, la version, le hachage et l’image réellement exécutée. Le reçu de configuration indique les modes admis par opération, objet et contrepartie. Le reçu d’usage observe le profil effectivement sélectionné. Le reçu du pair prouve un échange réussi avec le profil de remplacement. Le reçu de résultat confirme que l’action applicative au-delà du déchiffrement a abouti.

Aucun n’absorbe les autres. La dernière version d’une bibliothèque peut supprimer une fonction sans que toutes les images aient été déployées. Le déploiement peut réussir alors qu’un worker ancien reste actif. Une configuration peut interdire Auth tandis qu’un objet retardé exige encore son décodeur. Un test PSK peut ouvrir le ciphertext sans démontrer l’autorisation métier recherchée.

L’ordre inverse est tout aussi dangereux. Trouver une fonction Auth n’établit pas qu’elle est activée. Trouver une exception ne prouve pas qu’elle a servi. Réussir à ouvrir un ancien objet ne prouve ni fraîcheur, ni mandat, ni effet final.

Un projet individuel matérialise une branche, pas un consensus

draft-ms-hpke-auth-modes-01 propose de restaurer AuthPSK comme extension stricte. Il réintroduit la mécanique Auth comme composant, mais refuse de rétablir Auth seul, au motif que cette construction classique ne fournit pas de résistance quantique.

Datatracker prévient explicitement que ce texte est un Internet-Draft individuel, sans approbation ni statut formel dans le processus IETF. Il ne faut donc pas le présenter comme la solution adoptée.

Son existence reste informative : sortir une fonction du noyau commun ne la rend pas impossible à décrire dans un autre ensemble de compatibilité. Si cette extension avançait, elle devrait posséder ses propres tests, liaisons applicatives, règles de clé et preuves d’adoption.

Les échanges de liste montrent la même séparation. Des participants discutent du rôle des signatures, de l’authentification classique et de la construction post-quantique. Le courrier prouve que la question est débattue ; il ne prouve ni consensus, ni code déployé, ni besoin universel.

PSK prouve une possession, pas toute l’identité

Le noyau candidat conserve une propriété d’authentification de l’émetteur en mode PSK. Cryptographiquement, le pair qui construit le contexte possède la clé prépartagée.

L’organisation qui distribue cette clé doit encore dire qui peut la détenir, pour quel service, jusqu’à quelle date et avec quel lien vers une identité. Une clé partagée par cinq processus ne désigne pas l’un d’eux. Une clé réutilisée entre environnements ne porte pas spontanément la frontière d’autorité souhaitée.

Le projet rappelle aussi les non-objectifs de HPKE : pas de prévention applicative du rejeu ou du downgrade, pas d’ordre fiable des messages, pas de dissimulation de longueur, pas de protection contre un mauvais aléa éphémère, et pas de forward secrecy face à une compromission ultérieure de la clé privée du destinataire.

La migration ne peut donc pas remplacer le mot Auth par PSK dans un tableau et déclarer l’identité réglée. Elle doit tester la propriété que l’application veut réellement : identité du pair, fraîcheur, autorisation et effet.

Les données durables prolongent la vie du récepteur

Un service peut arrêter de produire un ancien format bien avant de pouvoir supprimer son chemin de lecture. Les messages différés, sauvegardes, archives, tâches rejouables et objets soumis à conservation ont leur propre horloge.

Supprimer trop tôt le code ou les clés rend les données illisibles. Conserver éternellement un chemin non isolé crée une surface sans propriétaire. Le registre doit donc fixer le format d’objet, sa fenêtre de création, son horizon de rétention, le profil sélectionné et le dernier test de lecture.

Si les métadonnées historiques ne permettent pas d’identifier sûrement le mode, cette lacune doit rester une inconnue. Déduire une certitude de la forme du ciphertext fabrique un contrôle qui n’existe pas.

Le texte coordonne ; les systèmes ferment la transition

Les principes de spécification minimale et de primauté du code en fonctionnement de Heng Lu offrent ici une grille utile. Une publication peut définir un ensemble commun. Une évolution devient réelle pour chaque acteur par l’implémentation, la validation, le déploiement et l’usage.

Cette lecture ne retire rien au travail normatif. Elle empêche seulement de lui attribuer un effet qu’il ne peut observer. Le nouveau projet peut réduire le noyau HPKE. Le responsable opérationnel doit ensuite établir, preuve par preuve, quels acteurs ont rejoint cet ensemble.

La phrase de clôture honnête est bornée : profils examinés, versions mesurées, exceptions supprimées, objets migrés, partenaires testés et durée d’absence observée. Tout ce qui se trouve hors de ce périmètre reste inconnu.

Sources