Résumé

  • Dans draft-ietf-cose-hpke-27, un chiffré HPKE peut être transporté hors de COSE_Encrypt ou COSE_Encrypt0, dont le champ ciphertext vaut alors nil. Une signature ou un MAC ajouté ensuite à l’objet COSE ne couvre pas ces octets détachés.
  • Un algorithme AEAD peut assurer leur intégrité, mais cette preuve sous la clé de contenu n’est ni une signature de l’émetteur, ni une décision d’autorisation, ni la preuve qu’un effet métier a eu lieu.
  • Au 1er octobre 2026, la révision 27 restait un Internet-Draft en suivi d’évaluation par l’AD. Trois implémentations auraient validé les exemples ; cela ne certifie aucun stockage détaché en production.

Le risque ne vient pas d’un algorithme mystérieux. Il naît d’une phrase ordinaire dans l’architecture : « le message est signé ». Dans un système à contenu détaché, cette phrase peut être exacte et pourtant beaucoup trop large.

La révision 27 du projet COSE-HPKE autorise le transport séparé du chiffré. Elle avertit explicitement que l’intégrité appliquée ensuite par COSE_Sign, COSE_Sign1, COSE_Mac ou COSE_Mac0 ne couvre pas ce chiffré détaché. L’implémentation doit lui fournir une protection d’intégrité propre. Le texte ne condamne donc pas le détachement ; il interdit de lui attribuer une couverture qu’il n’a pas.

nil décrit un chemin de transport

RFC 9052 définit les structures COSE. Quand le contenu est détaché, sa case porte nil et l’application fournit les octets par un autre canal. Ce mécanisme convient aux objets volumineux, aux systèmes de blobs et aux contenus dont la durée de vie diffère de celle des métadonnées.

En mode intégré, HPKE produit notamment ct. Le texte de la révision 27 prévoit soit de placer ct dans COSE_Encrypt0, soit de le transmettre séparément. En mode de chiffrement de clé, la couche 0 chiffre le contenu avec une clé CEK et la couche 1 chiffre cette CEK pour chaque destinataire. La source XML décrit la même séparation.

Dès lors, l’identifiant du blob devient un élément de sécurité. Une URL mutable, un alias réutilisé, une reconstruction par plages ou une normalisation peuvent associer une enveloppe valide aux mauvais octets. Le vérificateur doit conserver le condensat et la longueur du chiffré effectivement utilisés, pas seulement le nom sous lequel ils ont été trouvés.

L’intégrité AEAD n’est pas une signature élargie

Le projet indique qu’un AEAD peut protéger le chiffré détaché. C’est la construction normale : la vérification du tag montre que le chiffré et les données associées sont valides sous la CEK. Cette propriété est forte, mais précise.

La signature externe répond à une autre question : la clé du signataire valide-t-elle la structure exacte qui lui a été soumise ? HPKE répond encore à une autre : le destinataire peut-il ouvrir le matériel destiné à sa clé ? Le service d’identité décide ensuite qui possède cette clé. Enfin, l’application décide si cette identité peut agir sur cette ressource maintenant.

Ces résultats ne doivent pas partager une seule case « vérifié » :

Étape Preuve utile Limite
Signature ou MAC externe Objet exact couvert et clé de validation N’englobe pas automatiquement le blob détaché
AEAD de couche 0 Intégrité du chiffré et des données associées sous la CEK Ne nomme pas publiquement l’émetteur
Ouverture HPKE Traitement de la clé destinataire et déchiffrement Ne confère aucune permission métier
Résolution d’identité Lien entre une clé et un acteur accepté Ne prouve pas l’autorisation de l’action
Autorisation Droit courant d’exécuter l’opération Ne prouve pas le commit
Reçu d’effet Changement externe observé Doit rester relié à toute la chaîne

Le contexte du destinataire ferme une ambiguïté, pas toutes

Dans Recipient_structure, le projet lie l’algorithme de la couche suivante et les en-têtes protégés du destinataire à l’entrée info de HPKE. Le but est clair : éviter que l’algorithme de chiffrement du contenu flotte indépendamment du mécanisme qui protège la CEK.

Cette structure doit être encodée de façon déterministe selon RFC 8949. Deux parties reconstruisent localement une valeur non transportée ; elles doivent produire les mêmes octets. Le déterminisme résout une divergence d’encodage. Il ne résout ni la propriété de la clé, ni la fraîcheur, ni l’autorisation.

recipient_extra_info permet aussi d’injecter un contexte partagé hors bande. Un tenant, une session ou un objectif peuvent ainsi influencer la dérivation. Mais si un côté omet ce contexte ou revient silencieusement à une chaîne vide, le contrôle disparaît. Il faut donc enregistrer sa provenance, sa version et son condensat.

Le paramètre kid facilite la sélection de la clé publique statique du destinataire. Il reste un identifiant. Un même octet court peut exister dans plusieurs espaces de noms ; un cache peut résoudre une ancienne version ; une clé de récupération peut déchiffrer sans avoir le rôle opérationnel attendu. La résolution est une décision de politique, pas une décoration du message.

Chiffrement pour un destinataire et authentification d’un émetteur

RFC 9180 a fixé le cadre HPKE connu. Le projet successeur actif reste en cours et remplacerait RFC 9180 s’il était approuvé. Une équipe doit donc relever la version et la suite effectivement déployées, au lieu d’écrire seulement « HPKE ».

Le mode Base ne fournit pas l’authentification de l’émetteur dans le KEM. COSE peut ajouter signature ou MAC. Encore faut-il vérifier la couverture réelle. Une signature valide sur l’enveloppe ne devient pas, par proximité, une signature sur un blob exclu de son entrée.

RFC 9338 éclaire la même frontière pour les contresignatures : attester les données chiffrées n’équivaut pas à attester le texte clair. Si l’organisation veut une approbation portant sur le sens du contenu, elle doit construire et conserver cette preuve, non la déduire d’un déchiffrement réussi.

RFC 9053, le registre COSE de l’IANA et le registre HPKE coordonnent algorithmes et numéros. Un code attribué n’atteste ni la configuration sûre d’un produit, ni la rotation des clés, ni le refus d’une suite obsolète.

Le statut institutionnel doit rester exact

Le Datatracker présente la révision 27 comme un document du groupe COSE visant le statut Proposed Standard, soumis à l’IESG et en AD Evaluation::AD Followup au 1er octobre 2026. L’historique date cette révision du 12 septembre. Aucun numéro RFC n’était attribué.

Le rapport du shepherd mentionne une discussion large et trois implémentations indépendantes utilisées pour valider les exemples à l’IETF 125. C’est un signal utile de code exécuté. Ce n’est ni une enquête de déploiement, ni une validation des jointures entre base de métadonnées et stockage de blobs.

Le manifeste de couverture

Chaque décision devrait conserver : les octets COSE exacts ; le tag et le type ; les en-têtes protégés et non protégés ; la présence ou le détachement ; le localisateur immuable, la taille et le condensat du chiffré ; le condensat de l’entrée signature/MAC ; l’algorithme AEAD, les données associées et le résultat du tag ; le mode et la suite HPKE ; le condensat de ek et de Recipient_structure ; la provenance de recipient_extra_info ; la version de clé résolue par kid ; le résultat d’ouverture ; la décision d’identité ; l’autorisation ; l’identifiant de commit ; l’effet observé.

Ce registre ne doit pas contenir de clés privées ni de texte clair inutile. Il doit montrer les liaisons. signature_externe=true et couverture_blob=false peuvent constituer une conception sûre si aead_blob=true est prouvé ; les remplacer par signé=true détruit l’information.

Minimum Initial Specification conduit à imposer ce petit manifeste commun sans centraliser toutes les politiques. Running-Code Primacy demande d’inspecter les buffers réels donnés aux bibliothèques. The Policy Mirror montre le pouvoir des résolveurs de clés et des stores. Reality Layers empêche de confondre syntaxe, octets, preuve, identité, permission et effet.

Sources