Résumé

  • Six types de média distinguent CWT, JWT, bundles détachés CBOR/JSON et ensembles de claims non protégés CBOR/JSON ; le suffixe +cwt et les identifiants CoAP complètent ce vocabulaire.
  • Le paramètre facultatif eat_profile permet de choisir un processeur avant lecture du corps, mais il faut ensuite le confronter au claim interne et exécuter toutes les contraintes du profil.
  • Une chaîne fiable conserve séparément l’aiguillage, la validation des octets, la protection, la fraîcheur, l’appréciation du Verifier et la décision locale du Relying Party.

Nommer le colis ne valide pas son contenu

Le RFC 9782 part d’un problème concret : les Evidence et Attestation Results de l’architecture RATS doivent circuler dans des API HTTP ou CoAP. Sans vocabulaire précis, un serveur reçoit un « token » générique, l’envoie vers un analyseur polyvalent et découvre trop tard quel traitement aurait dû s’appliquer.

La norme enregistre donc application/eat+cwt, application/eat+jwt, deux types pour les bundles EAT détachés en CBOR ou JSON, et deux types pour UCCS et UJCS. Elle attribue aussi les Content-Formats CoAP 263 à 268. Le suffixe structuré +cwt permet à un outil générique de reconnaître le socle CWT. Cette première classification réduit l’ambiguïté et rend le rejet des formes non prises en charge observable dès l’entrée.

Elle ne crée pourtant aucune preuve cryptographique. Un suffixe ne dit ni qui a signé, ni quelle clé est admise, ni quelles claims sont obligatoires. Le type d’un bundle ne prouve pas que chaque ensemble détaché correspond au digest protégé. Le type UCCS/UJCS ne transforme pas un ensemble non signé en objet autonome digne de confiance.

Pour ces formes non protégées, le RFC 9781 place l’assurance dans un canal sécurisé : le destinataire authentifie l’émetteur, l’intégrité du transport est protégée et la confidentialité exige également l’authentification du destinataire. Dès que les claims sortent de ce canal, cette protection cesse. Un stockage ou un transfert ultérieur est donc un nouveau passage de responsabilité. À l’inverse, un CWT complet transporté dans le même canal reste garanti par sa propre enveloppe COSE ; le canal ne l’endosse pas.

Un profil visible à l’entrée reste une déclaration

EAT offre de nombreux choix : JSON ou CBOR, formats imbriqués, structures COSE ou JOSE, algorithmes, identification des clés, claims obligatoires et méthode de fraîcheur. Le RFC 9711 demande aux profils de fermer ces choix pour un usage précis.

Le claim interne eat_profile identifie ce profil par URI ou OID. Le RFC 9782 autorise le même identifiant comme paramètre du type de média. L’intérêt opérationnel est net : un routeur peut sélectionner le processeur dédié sans inspecter le corps. Les profils inconnus ne contaminent pas un analyseur universel, et la négociation Accept peut viser une forme de résultat bien définie.

Mais le paramètre externe vient du message. Après un décodage sûr, il faut conserver et comparer les deux identifiants. Absence autorisée, égalité et contradiction sont trois événements différents. Une contradiction peut signaler un client confus, un intermédiaire périmé ou une substitution ; la normaliser silencieusement détruirait précisément l’indice que le paramètre devait fournir.

Même l’égalité ne prouve pas la conformité. Selon le RFC 9711, eat_profile ne doit pas désigner un profil partiel. Un profil complet doit permettre à tout récepteur conforme de décoder, vérifier et contrôler la fraîcheur de tout EAT produit par un émetteur conforme. Un URI correct ne démontre pas qu’un algorithme autorisé a été choisi, qu’une claim requise existe ou que le récepteur implémente chaque option permise. L’identifiant choisit la grille de contrôle ; l’exécution seule produit le constat.

La validation commence là où l’aiguillage s’arrête

La section sécurité du RFC 9782 est sans équivoque : les types de média ne sont que des indices pour l’application de traitement. Celle-ci doit vérifier que les données correspondent au format attendu, quelle que soit l’étiquette annoncée, puis arrêter le traitement en cas d’échec. Sinon apparaissent des risques d’élévation de privilèges et d’attaque inter-protocoles.

Le bon modèle n’est donc pas un bit « EAT accepté ». Il faut une trace du type déclaré et du hash des octets ; une trace du processeur et de l’analyseur réellement utilisés ; une trace de l’enveloppe, de l’algorithme, de la clé et de l’ancre de confiance ; ou, pour UCCS/UJCS, du périmètre exact du canal authentifié. Pour un bundle, chaque digest mérite son propre résultat.

Puis viennent les claims. Le RFC 9711 en définit la sémantique, pas le niveau de résistance de l’implémentation qui les produit. Une signature valide attribue des octets dans un modèle de clés ; elle ne prouve pas qu’un capteur a mesuré honnêtement. La confiance dépend de ce que le Verifier sait de l’Attester, des endorsements, des valeurs de référence et de ses contrôles.

La fraîcheur est encore une autre preuve. Tout usage d’EAT doit disposer d’un mécanisme contre le rejeu. Un nonce peut remplir ce rôle, mais le profil doit préciser les mécanismes acceptés. Un token authentique peut être ancien : résultat cryptographique et résultat de fraîcheur ne doivent pas partager une case de journal.

Enfin, l’architecture RATS sépare l’appréciation et l’action. Le Verifier applique une politique à l’Evidence et produit des Attestation Results. Le Relying Party applique sa propre politique à une ressource et à une demande précises. Un résultat favorable peut conduire à un refus local ; un résultat incomplet peut conduire à un accès réduit et temporaire. Le type de média n’autorise aucune de ces décisions.

Le RFC 9782 constitue ainsi une bonne spécification minimale : des noms communs, une sélection de profil et des identifiants compacts. Dans la distinction de Heng Lu, le registre rend ces noms réels au niveau symbolique. Ils deviennent réalité exécutable lorsque deux implémentations rejettent les mêmes octets invalides, appliquent le même profil et conservent les preuves de chaque transition.

Sources