Summary

  • La révision 27 de draft-ietf-cose-hpke, publiée le 12 septembre, reste un Internet-Draft de la filière normative en suivi du directeur de zone. Ce n’est ni un RFC ni un profil de déploiement approuvé.
  • Un psk_id protégé active le mode PSK ; en son absence, le mode Base s’applique. Celui-ci protège les données pour le destinataire mais n’authentifie pas l’émetteur dans le KEM HPKE.
  • kid désigne la clé publique du destinataire, pas l’identité de l’émetteur. Daniel Kade propose de conserver une quittance limitée de la voie d’authentification et d’autorisation, sans enregistrer la PSK ni le texte en clair.

Le résultat cryptographique ne nomme pas forcément l’auteur

La révision 27 est arrivée le 12 septembre alors que le dossier Datatracker affiche AD Evaluation::AD Followup. Le texte, soumis à l’IESG en vue d’une publication sur la filière Standards Track, précise désormais que HPKE exige une source aléatoire cryptographiquement sûre et que la clé de chiffrement du contenu doit elle aussi être produite ainsi en mode Key Encryption.

Ce changement est normatif, mais il ne clôt pas le processus. Le statut courant peut évoluer, les numéros d’enregistrement IANA sont encore provisoires et la formulation d’un futur RFC n’est pas acquise. La révision offre surtout une occasion précise de vérifier la frontière entre protection cryptographique et autorité opérationnelle.

Un objet COSE ouvert avec succès prouve que les données chiffrées et le contexte authentifié correspondent aux entrées cryptographiques utilisées par le destinataire. En mode Base, le KEM ne prouve pas l’identité de l’émetteur. L’étiquette « AEAD » peut brouiller cette lecture : l’algorithme authentifie le chiffré et ses données associées sous une clé dérivée ; il ne transforme pas celui qui a effectué une encapsulation vers une clé publique en principal connu.

Deux architectures de chiffrement, puis un choix d’authentification

Le projet prévoit d’abord Integrated Encryption. HPKE y protège directement le texte en clair dans COSE_Encrypt0, pour un seul destinataire. Key Encryption sépare les couches : un algorithme COSE chiffre le contenu avec une clé de contenu, puis HPKE enveloppe cette clé dans une structure de destinataire. Cette deuxième forme peut accueillir plusieurs destinataires.

Chaque identifiant d’algorithme demandé pour COSE fixe un triplet KEM, KDF et AEAD, ainsi que l’architecture dans laquelle il doit être employé. Cette association évite qu’un logiciel mélange librement des composants ou réutilise l’identifiant d’Integrated Encryption dans une couche Key Encryption.

Le mode d’authentification est néanmoins choisi ailleurs. Si l’en-tête protégé contient psk_id, le traitement suit mode_psk. Sinon, il tombe sur mode_base. Le projet souligne que ce choix n’est donc pas encodé explicitement dans l’identifiant de la suite cryptographique.

Une même valeur d’algorithme peut ainsi accompagner deux affirmations différentes. Dans un cas, le détenteur prouve la possession d’un secret partagé externe. Dans l’autre, aucune authentification de l’émetteur n’est fournie par le KEM. Un journal qui ne retient que l’algorithme ne permet pas de reconstruire la propriété effectivement obtenue.

kid aide à trouver le destinataire

Le paramètre kid est recommandé pour indiquer la clé publique statique du destinataire employée par l’émetteur. Il peut servir à sélectionner la clé privée correspondante parmi plusieurs générations actives. Son orientation est parfois mal comprise : il identifie la cible cryptographique, pas la source du message.

Le projet suppose que l’émetteur possède déjà cette clé publique et laisse sa distribution hors périmètre. Une application doit donc savoir d’où vient la clé, à quel service ou locataire elle appartient et quand elle a été remplacée. Un objet peut être irréprochable au regard de HPKE tout en ayant été préparé avec une clé correctement formée mais issue du mauvais répertoire organisationnel.

psk_id ouvre un autre renvoi vers l’extérieur. Sa présence est protégée ; la PSK elle-même ne doit pas être transportée dans COSE. Une ouverture en mode PSK prouve la possession du secret partagé pertinent. Elle ne dit pas automatiquement quelle personne ou quel service en avait la garde, si cette attribution est encore valable, ni quelles opérations elle autorise. Le projet HPKE actuel exige par ailleurs une PSK à forte entropie : le mécanisme n’est pas un substitut à un protocole conçu pour les mots de passe.

Lier un contexte ne suffit pas à définir une politique

Les en-têtes protégés et les données authentifiées externes permettent à l’application d’inscrire du contexte dans le calcul. En Key Encryption, une Recipient_structure déterministe reprend l’algorithme de la couche immédiatement inférieure, les en-têtes protégés du destinataire et d’éventuelles informations supplémentaires. L’objectif est notamment d’empêcher une substitution d’algorithme entre les couches.

Cette construction protège ce qui a été placé dans la structure ; elle ne choisit pas ce qui devrait y figurer. Un profil peut imposer un identifiant de locataire, une classe de transaction, une date d’expiration et une version de politique. Un autre peut laisser le contexte externe vide. La conformité de l’encodage ne tranche ni la portée d’une délégation ni la réutilisation licite d’un message.

HPKE se présente comme un mécanisme de bas niveau. L’application conserve la responsabilité des pertes et de l’ordre des messages, de la prévention du déclassement, de la fraîcheur et de la protection contre les rejeux au-delà de ce que garantit un contexte ordonné. Avec l’API « single-shot », le même objet peut être reçu plusieurs fois ; empêcher que la même commande soit exécutée plusieurs fois relève du protocole qui l’emploie.

Le chiffré détaché ajoute une frontière concrète. Le projet avertit qu’une signature ou un MAC COSE appliqué ensuite ne couvre pas automatiquement les octets détachés. Il faut leur assurer une protection d’intégrité propre. Dire « signature valide » sans préciser quel contenu elle couvre produit une preuve incomplète.

Le mode Base a une fonction légitime

Le constat n’est pas une condamnation du mode Base. Il convient très bien à un dépôt confidentiel ouvert à tout émetteur, ou à un système dans lequel l’authentification vient d’une signature, d’un MAC, d’un canal authentifié ou d’une identité applicative séparée. Le texte cite explicitement COSE_Sign, COSE_Sign1, COSE_Mac et COSE_Mac0 comme compléments possibles.

L’erreur consiste à attribuer au succès du déchiffrement une garantie que le mode choisi ne promet pas. Inversement, le mode PSK ne décide pas tout : un secret partagé peut représenter un appareil, un parc, un service ou plusieurs opérateurs. Sa possession ne fixe ni les permissions, ni la durée de validité, ni les règles de révocation.

La question de gouvernance naît au moment où le résultat déclenche une action. Une passerelle accepte une configuration, un appareil exécute une commande, une plate-forme enregistre un rapport. Le système doit pouvoir dire si la confidentialité anonyme était intentionnelle, quelle authentification distincte a réussi et quelle règle autorisait cette action.

Conserver la voie qui a rendu l’acceptation légitime

Daniel Kade propose une quittance d’authentification de l’émetteur pour chaque objet COSE HPKE accepté. Elle indiquerait la version du profil, Integrated ou Key Encryption, la suite cryptographique, le mode HPKE effectif, l’empreinte de la clé du destinataire et la provenance de sa distribution. En mode PSK, elle ajouterait une empreinte irréversible de psk_id, une version non secrète de la PSK et son état de cycle de vie. En mode Base, elle nommerait la signature, le MAC, le canal ou le contrôle d’identité distinct — ou constaterait que le dépôt anonyme est permis.

La quittance lierait encore le profil de contexte protégé, le résultat de fraîcheur ou de rejeu, la couverture du chiffré détaché, la version de la politique d’autorisation et la décision finale. Ni la PSK, ni le texte en clair, ni des identités superflues ne devraient être consignés. Un identifiant opaque et des empreintes suffisent pour beaucoup de contrôles.

Cette proposition ne figure ni dans le projet, ni dans le RFC 9052, ni dans le RFC 8937, ni dans le registre COSE de l’IANA. Elle applique à l’exploitation la distinction du Policy Mirror de Heng Lu : un résultat valide n’est pas encore une autorité. La spécification initiale minimale invite à garder cette preuve commune compacte, tandis que l’exigence éditoriale de BTW interdit de transformer un projet en cours en récit d’incident.

Sources

  1. COSE HPKE, révision 27
  2. COSE HPKE, révision 26
  3. Dossier Datatracker courant
  4. Historique Datatracker
  5. Projet HPKE, révision 04
  6. RFC 9052 — structures et traitement COSE
  7. RFC 8937 — amélioration de l’aléa
  8. Registre COSE de l’IANA
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists