Résumé

  • RFC 9995 place le résultat du hachage dans le payload COSE et protège obligatoirement l’algorithme ; le type du préimage et son emplacement peuvent aussi être protégés, mais restent facultatifs.
  • La signature ou le MAC peuvent être validés sans le préimage : le résultat porte sur une enveloppe compacte, non sur la disponibilité, la fraîcheur, la sûreté ou la valeur opérationnelle de l’objet absent.
  • Pour agir, le système doit encore identifier l’autorité du signataire, obtenir les octets sous une politique bornée, recalculer l’empreinte, analyser et apprécier l’objet, autoriser l’usage précis puis constater son effet.

Dans un atelier de maintenance isolé, l’équipement de vérification reçoit une petite structure COSE par un canal à faible débit. La structure contient une empreinte et une signature. Le paquet logiciel de plusieurs gigaoctets, lui, n’est pas présent. Le technicien peut vérifier que l’enveloppe n’a pas changé ; il ne peut pas encore déclarer que le paquet disponible demain sera celui qui a été attesté aujourd’hui.

C’est le choix précis de la RFC 9995, publiée en juillet 2026 sur le Standards Track de l’IETF. Une COSE Hash Envelope évite d’envoyer un grand préimage à un service de signature ou à chaque vérificateur. L’économie de transport est réelle, surtout quand l’objet existe déjà dans un autre dépôt. Mais elle est achetée par une séparation nette : l’objet cryptographique transporte l’empreinte, pas l’objet d’origine.

Le bon modèle n’est donc pas « un fichier signé à distance ». C’est une chaîne de décisions dont la première peut réussir avant que les suivantes ne commencent.

Le préimage, l’empreinte et l’empreinte détachée

Trois objets doivent conserver des noms différents.

Le préimage est la suite exacte d’octets qui a été hachée : nomenclature logicielle, image de micrologiciel, dossier de preuve ou tout autre contenu. L’empreinte est la courte valeur résultante ; dans RFC 9995, elle devient le payload COSE. Enfin, les règles ordinaires de COSE permettent de détacher ce payload : le vérificateur reçoit alors séparément la petite empreinte utilisée dans la structure de signature.

L’absence du grand préimage est la fonction centrale de l’enveloppe. Le détachement de la petite empreinte est une option de transport supplémentaire. Un journal qui inscrit simplement « payload externe fourni » ne dit pas lequel des deux a été fourni. Cette ambiguïté suffit à produire une preuve d’audit trompeuse.

La RFC 9052 définit les structures COSE. Pour COSE_Sign1, le calcul protège les en-têtes protégés, les données authentifiées externes choisies par l’application et le payload complet utilisé dans la Sig_structure. Les en-têtes non protégés ne bénéficient pas de cette garantie. Le préimage absent ne devient pas signé par proximité conceptuelle : seule son empreinte entre dans le calcul.

Une implémentation sérieuse expose donc deux verdicts. Le premier authentifie l’enveloppe sans objet. Le second, après obtention d’un candidat, établit ou refuse l’égalité de ses octets avec l’empreinte annoncée.

Trois coordonnées protégées, aucune livraison

Le paramètre payload_hash_alg, étiquette 258, est obligatoire dans l’en-tête protégé et interdit dans l’en-tête non protégé. Il indique l’algorithme qui a produit le payload-empreinte. Le déplacer dans une zone modifiable détruirait la coordination même du calcul.

preimage_content_type, étiquette 259, peut indiquer le type de média ou le Content-Format CoAP du préimage. Il est facultatif mais protégé lorsqu’il existe. Ce n’est pas le paramètre COSE ordinaire content_type, étiquette 3 : ce dernier décrirait le payload, donc l’empreinte. RFC 9995 l’interdit dans la Hash Envelope afin d’éviter deux objets décrits par un même mot.

payload_location, étiquette 260, peut porter une chaîne ou une URI permettant de chercher le préimage. Sa protection prouve que l’indice n’a pas été remplacé sans casser l’enveloppe. Elle ne prouve ni disponibilité, ni stabilité, ni confidentialité, ni droit d’accès.

Le registre COSE de l’IANA coordonne ces valeurs. La RFC 8126 explique la fonction des politiques d’enregistrement. Un numéro stable ne certifie pourtant ni une bibliothèque, ni un déploiement, ni une politique locale. De même, la grammaire CDDL de la RFC 8610 peut faire rejeter une structure mal formée sans dire qui l’a produite ni ce qu’elle vaut.

Le type ne décide pas davantage du sens. La RFC 7252 fournit l’espace des Content-Formats CoAP que l’étiquette 259 peut référencer. Cette coordonnée sélectionne éventuellement un parseur ; elle n’atteste pas que le contenu respecte son schéma ou convient à l’action prévue.

La clé ouvre une question d’identité

Une opération cryptographique valide établit une propriété limitée : avec les entrées et algorithmes acceptés, les champs protégés et l’empreinte n’ont pas été modifiés depuis leur production par le détenteur de la clé ou du secret pertinent.

Elle ne nomme pas seule ce détenteur. RFC 9052 attribue à l’application la responsabilité d’associer la clé à la bonne identité puis de vérifier que cette identité est autorisée. Une clé peut être valable pour signer un reçu d’archivage et ne pas l’être pour approuver un micrologiciel. La rotation d’un poste, l’expiration d’un contrat ou le changement d’un tenant ne modifient pas les mathématiques de la signature ; ils modifient son pouvoir.

Les données authentifiées externes peuvent lier un contexte, à condition qu’un profil définisse ce contexte et que producteur et consommateur reconstruisent exactement les mêmes octets. Un champ externe vide ne prouve ni environnement, ni version, ni finalité.

La RFC 9421 illustre par contraste la signature de composants HTTP sélectionnés et la nécessité d’un profil applicatif. Une Hash Envelope ne signe pas une requête HTTP et ne transforme pas l’adresse protégée en ordre réseau. Les deux mécanismes exigent que le verdict reste dans son périmètre.

Une URI signée reste une entrée non privilégiée

Supposons que l’enveloppe indique un dépôt. L’automate peut déjà posséder l’objet ; il peut être hors ligne ; ou sa politique peut interdire tout accès direct. RFC 9995 permet la récupération, elle ne la rend pas automatique.

Un service de vérification privilégié qui suit aveuglément l’URI acquiert un nouveau pouvoir : joindre des réseaux internes, transmettre des identifiants, suivre des redirections ou décompresser un flux volumineux. Le signataire peut être compromis, l’enveloppe ancienne, le nom réattribué. Le fait que l’URI soit intacte ne garantit pas que le monde auquel elle mène soit resté intact.

La RFC 9110 sépare ressource, représentation, contenu, codage et redirection. Il faut donc fixer les schémas acceptés, les origines, le nombre de redirections, l’usage des identifiants, les délais, la taille, l’expansion après décompression et l’isolation réseau. Le journal doit conserver l’origine finale et les transformations autorisées.

La RFC 6920 distingue justement le nom fondé sur un hachage de la méthode servant à trouver l’objet. Plusieurs miroirs peuvent livrer les mêmes octets ; un même emplacement peut en livrer d’autres. L’empreinte permet de trancher après la récupération, pas de gouverner celle-ci à elle seule.

Le calcul doit porter sur les octets convenus

Le consommateur calcule l’algorithme de l’étiquette 258 sur le candidat exact, puis compare avec le payload COSE. Un nom de fichier, une version sémantique ou un identifiant de dépôt ne remplace pas cette opération.

La RFC 9530 montre que le digest d’un contenu HTTP et celui des données de représentation sélectionnées ne désignent pas nécessairement les mêmes octets. Un codage de contenu peut produire plusieurs formes d’une même ressource abstraite. Les champs Digest n’offrent par eux-mêmes ni authentification, ni autorisation, ni confidentialité.

Il faut donc publier le contrat d’octets : archive compressée telle que stockée, contenu après décodage, sérialisation canonique ou autre forme précisément nommée. Reparser puis sérialiser du JSON ou du CBOR peut changer l’ordre, les nombres ou les espaces. Normaliser les fins de ligne peut fabriquer un objet pratique mais différent. Le vérificateur préserve les octets, n’applique que les transformations prévues, calcule, puis compare.

Une égalité réussie transmet à ces octets la revendication de l’enveloppe, dans la limite des algorithmes. Elle n’en prouve ni la date, ni la complétude métier, ni l’innocuité.

Le sens commence après l’égalité

Un manifeste peut correspondre à son empreinte et échouer au parseur. Il peut se parser et violer son schéma. Il peut satisfaire le schéma tout en décrivant une autre version. Il peut viser la bonne version et omettre une dépendance exigée. Il peut être complet et révéler un composant interdit par la politique.

Ces états ne sont pas des variantes de « validé ». La fraîcheur aussi reste externe : une signature parfaite peut protéger fidèlement une vérité périmée. L’application doit lier le contexte temporel, la version, la révocation et la finalité qu’elle souhaite imposer.

RFC 9995 couvre COSE_Sign, COSE_Sign1, COSE_Mac et COSE_Mac0. COSE_Encrypt et COSE_Encrypt0 sont hors périmètre. Le mécanisme ne fournit pas la confidentialité et ne décide pas si un futur objet chiffré sera haché avant ou après chiffrement.

Enfin, les identifiants d’algorithmes n’effectuent pas la migration. La RFC 9053 définit des algorithmes COSE et leurs contrôles. La RFC 7696 rappelle que l’agilité exige une transition active : production du successeur, prise en charge par les consommateurs, période de recouvrement, refus daté de l’ancien choix et traitement des archives. RFC 9995 demande une combinaison de force cohérente avec le hachage ; l’opérateur choisit encore ce qui est acceptable pour la durée de vie de l’objet.

La preuve utile suit l’exécution

Le principe de running code de Heng Lu demande les traces du chemin réellement parcouru : octets produits, empreinte, enveloppe, algorithmes, clé, identité, finalité, récupération, comparaison, parseur, politique, autorisation et effet. La mention « compatible RFC 9995 » est un début de description, non une clôture.

Son argument sur la spécification initiale minimale et la décision locale correspond à cette architecture. Les étiquettes et formes communes suffisent à coordonner. Les privilèges de téléchargement, les formats permis, les rôles, la fraîcheur, la migration, la rétention et le retour arrière appartiennent à des responsables locaux nommés.

La distinction des couches de réalité interdit de fusionner la structure, la cryptographie, l’identité, l’obtention, l’égalité, le sens, l’autorisation et l’effet. Chaque couche peut réussir tandis que la suivante échoue.

Les sources étudiées décrivent des normes et une doctrine éditoriale. Elles ne mesurent ni l’adoption, ni les performances, ni un produit précis. Le scénario de maintenance sert à rendre la frontière visible ; il ne constitue pas un constat de déploiement.