Résumé

  • Le 24 septembre 2026, l’IESG a approuvé draft-ietf-jose-hpke-encrypt-22 en vue d’une publication comme Proposed Standard. Le texte demeure un Internet-Draft, pas encore un RFC ni une preuve de déploiement.
  • Le mode Integrated Encryption chiffre directement le contenu pour un unique destinataire. Le mode Key Encryption chiffre une CEK commune et permet, en sérialisation JSON, de juxtaposer des destinataires HPKE, ECDH ou RSA.
  • Au moins un destinataire doit être validé, mais l’application décide si un seul suffit ou si tous doivent réussir. La confidentialité de la CEK commune est limitée par l’algorithme destinataire le plus faible.

Le message est lisible, la distribution ne l’est pas encore

Prenons un paquet destiné à un service actif, à une équipe de reprise et à une fonction d’archivage. Le premier chemin s’ouvre. La bibliothèque retrouve la clé de chiffrement du contenu, vérifie le tag et livre le texte en clair. D’un point de vue cryptographique, le succès est réel.

Il reste pourtant trois questions de contrôle : l’équipe de reprise devait-elle impérativement pouvoir ouvrir le paquet ? L’archive utilisait-elle encore un algorithme admis ? La liste des destinataires correspondait-elle à celle autorisée pour ce type de données ? Aucun octet du texte restitué ne répond à ces questions.

Cette séparation donne sa portée à l’annonce du 24 septembre. L’IESG a approuvé la révision 22 du projet JOSE consacré à HPKE avec JWE pour publication comme Proposed Standard. Le document organise l’interopérabilité ; il ne certifie ni un logiciel, ni une configuration, ni un jeu de clés, ni l’exécution d’une politique interne. Et tant que le processus éditorial n’est pas achevé, il ne faut pas le présenter comme un RFC publié.

Deux modes, deux chaînes de preuve

Integrated Encryption est une opération directe. HPKE chiffre le texte lui-même, sans clé de contenu distincte. Le paramètre protégé alg désigne la suite HPKE entièrement spécifiée ; enc et ek doivent être absents ; un seul destinataire est autorisé. Le champ JWE Encrypted Key transporte le secret encapsulé HPKE. Les emplacements JWE réservés au vecteur d’initialisation et au tag d’authentification sont vides, puisque ces fonctions sont intégrées à HPKE.

Key Encryption ajoute une couche. JWE chiffre le contenu une fois avec une CEK aléatoire et l’algorithme indiqué par enc. HPKE protège ensuite cette CEK pour un destinataire. Le JWE Encrypted Key contient le chiffrement HPKE de la CEK ; ek contient le secret encapsulé. Recipient_structure, injecté dans le calendrier de clés HPKE, lie un contexte JOSE, l’algorithme de contenu et, le cas échéant, une information supplémentaire connue de l’application.

Cette construction rend le multi-destinataire possible. Dans la sérialisation JSON, un destinataire HPKE peut cohabiter avec ECDH-ES+A128KW ou RSA-OAEP-256. Tous accèdent au même contenu par des chemins distincts vers la même CEK.

Le mécanisme facilite les migrations et les obligations de conservation. Une entreprise peut introduire HPKE dans un service tout en maintenant temporairement un consommateur ancien. Elle peut ajouter une clé de reprise sans chiffrer une seconde fois tout le contenu. Mais ce gain transforme l’ensemble des destinataires en surface de décision.

« Au moins un » est un minimum de protocole

La procédure de déchiffrement ne masque pas le problème. Lorsque plusieurs destinataires existent, l’application choisit ceux qui doivent réussir. Dans certains usages, un seul suffit ; dans d’autres, tous les chemins exigés doivent être valides. Le protocole impose seulement qu’au moins un destinataire valide le contenu, faute de quoi le JWE est rejeté.

En sérialisation JSON, le traitement doit en outre indiquer à l’application quels destinataires ont réussi et lesquels ont échoué. Ce vecteur de résultats est la matière de la décision locale.

Si A réussit sous HPKE, B échoue après une rotation de clé et C réussit avec un mécanisme ancien, trois verdicts restent possibles. Une règle exigeant seulement A peut accepter. Une règle imposant A et B doit refuser. Une règle interdisant l’algorithme de C peut considérer l’enveloppe invalide même si C a ouvert la CEK. Le même texte en clair n’entraîne donc pas le même résultat de gouvernance.

Le projet ajoute qu’un déchiffrement réussi ne suffit pas si les algorithmes utilisés ne sont pas acceptables pour le contexte. C’est une frontière saine : la norme décrit les données à vérifier et laisse l’autorité de décision au système qui porte la responsabilité du risque.

Le chemin le plus faible partage la même clé

Dans Key Encryption, tous les destinataires conduisent à une CEK commune. Celui qui récupère cette CEK peut ouvrir le contenu. Les Security Considerations en tirent une conclusion directe : la sécurité du contenu est limitée par l’algorithme le plus faible utilisé pour chiffrer la CEK.

Cela n’interdit pas toute transition mixte. Cela interdit de noter l’enveloppe selon son chemin le plus moderne en oubliant les autres. Une branche HPKE robuste ne renforce pas rétroactivement une branche admise qui donne accès à la même clé avec des garanties moindres.

La révision 22 illustre la granularité nécessaire. Après des objections durant l’examen, un second Last Call du groupe JOSE a porté sur la suppression de HPKE-4-KE et HPKE-6-KE. Ces identifiants de Key Encryption ont disparu de la révision 22, alors que HPKE-4 et HPKE-6 restent disponibles pour Integrated Encryption. Une fiche disant seulement « HPKE pris en charge » efface une différence normative réelle.

Le texte déconseille également d’utiliser la même paire KEM dans plusieurs modes ou suites HPKE, ainsi que de partager une clé entre HPKE et des algorithmes non HPKE. Pour l’audit, le nom du destinataire ne suffit donc pas : il faut conserver mode, suite, identité de clé et usage autorisé.

La grille de Heng Lu sur les couches de réalité aide à garder ces éléments séparés. L’approbation IESG est un fait de procédure. alg est un fait de format. Le succès d’un destinataire est un fait cryptographique. La règle « un ou tous » est un fait de contrôle. Seule une observation de l’application prouve la décision effectivement prise.

Sources