Résumé

  • RFC 9596 enregistre le paramètre COSE protégé typ, étiquette 16, pour déclarer le type de l’objet complet, alors que « content type » décrit la charge utile ou le texte chiffré.
  • La bibliothèque COSE transmet cette valeur à l’application sans l’interpréter ; la protection naît donc des règles de rejet, de validation et d’autorisation que l’application associe au type.

Le message arrive avec une signature valide. Son en-tête protégé porte le type attendu. Pour une chaîne d’automatisation, la tentation est forte : deux voyants verts, donc le bon traitement peut commencer.

RFC 9596 ne promet pas cela. Le texte ajoute un signal précis qui aide l’application à distinguer plusieurs familles d’objets COSE. Il ne transforme pas ce signal en décision. La couche COSE vérifie la structure cryptographique et remet typ à l’application ; elle ignore sa signification métier. C’est à l’application de savoir si le type était requis, s’il est accepté ici et quelles vérifications doivent suivre.

La nuance révèle une question de pouvoir : qui a le droit d’affirmer quoi ? Le signataire peut déclarer une catégorie d’objet. Seul le récepteur peut décider si cette catégorie, dans ce contexte, ouvre une branche de traitement.

Deux types pour deux étages différents

Avant RFC 9596, COSE disposait déjà de « content type ». RFC 9052 l’attache aux données présentes dans le champ payload ou ciphertext. RFC 9596 vise l’enveloppe entière. Une même valeur syntaxique peut donc se trouver à deux étages et répondre à deux questions distinctes.

Prenons une enveloppe signée qui contient un document CBOR. Le type de charge utile peut dire comment parser ce document. Le typ externe peut annoncer qu’il s’agit d’un reçu, d’un résultat d’attestation, d’un événement ou d’une requête d’autorisation. Deux objets peuvent transporter du CBOR tout en exigeant des politiques incompatibles.

La valeur peut être un entier du registre CoAP Content-Formats ou une chaîne correspondant à un type de média, éventuellement accompagnée de paramètres. Cette économie de syntaxe facilite l’interopérabilité ; elle ne permet pas de fusionner les deux preuves. Archiver seulement un libellé normalisé ferait disparaître son emplacement, sa représentation exacte et donc sa portée.

Un journal digne de confiance doit conserver séparément le type de l’objet complet, le type de sa charge, l’octet protégé reçu et le contexte attendu. Sinon, l’enquête reconstruira après coup une certitude que le système n’avait jamais possédée.

Protégé signifie intègre, pas vrai

RFC 9596 interdit typ dans les en-têtes non protégés. Dans une construction COSE qui authentifie le compartiment protégé, toute modification du type casse la vérification. Un intermédiaire ne peut donc pas rebaptiser librement l’objet sans laisser de trace cryptographique.

Mais le signataire peut signer une mauvaise déclaration. Il peut employer un ancien alias, un type valable sur une autre route, des paramètres non permis ou le bon type autour d’une charge incohérente. La signature prouve que la valeur appartient à l’objet signé ; elle ne certifie pas que la valeur décrit correctement la réalité.

Le texte le rend explicite : les implémentations COSE ignorent typ, sauf pour le transmettre. Le traitement relève de règles applicatives. Une application qui pratique le typage explicite devrait refuser une valeur inattendue et l’absence de valeur lorsqu’elle en exige une.

Le contrôle réside dans ces refus. Une interface qui affiche typ mais accepte le mauvais type par compatibilité n’a pas déployé la protection. Elle a seulement déployé une décoration authentifiée.

La branche de validation doit être réellement exclusive

RFC 9596 reprend l’idée du typage explicite de RFC 8725. Dans le monde JWT, un jeton d’une catégorie peut être confondu avec un autre. Un type distinct réduit cette ambiguïté. Mais RFC 8725 demande aussi des règles de validation mutuellement exclusives pour chaque catégorie.

Cette seconde règle empêche de surestimer la première. Si deux types passent par le même parseur, les mêmes clés, les mêmes valeurs d’audience par défaut et le même code d’autorisation, le répartiteur a peut-être changé de nom sans réduire la surface d’acceptation.

Chaque branche devrait lier le type à une structure permise, des en-têtes requis, un type de charge, des claims obligatoires, un émetteur, une audience, un usage de clé, une politique de fraîcheur, une protection contre le rejeu et un ensemble d’actions. Le mauvais objet doit échouer avant que la logique commune n’efface sa provenance.

RFC 8725 avertit en outre que des validateurs anciens peuvent ignorer typ. Compter les producteurs qui émettent le nouveau champ ne mesure donc pas son adoption. Il faut connaître la version de règle du récepteur et observer le rejet effectif des cas négatifs.

Un registre coordonne les noms, pas les permissions

IANA a inscrit typ sous l’étiquette 16 dans le registre des paramètres COSE. Les valeurs renvoient aux registres des types de média ou des formats CoAP. C’est une convention commune indispensable pour éviter les collisions et parler de la même chose.

Ce registre ne sait pas si un service a activé le type. Il ne connaît pas l’usage autorisé d’une clé, la route, les paramètres admis, la conformité de la charge ou la décision finale. L’enregistrement prouve l’existence d’un nom partagé, pas la confiance locale.

On retrouve ici le principe de spécification initiale minimale : le standard fixe l’emplacement protégé, la syntaxe et la conduite recommandée face à l’inattendu. Le profil et le code déployé gardent les choix futurs. L’adoption volontaire devient réelle lorsque les récepteurs exécutent ces choix, pas quand un catalogue central affiche une nouvelle ligne.

Une plateforme peut maintenir une liste globale des types connus pour la découverte. Elle ne doit pas convertir « connu » en « autorisé ». Chaque point d’entrée reste propriétaire de son ensemble d’acceptation.

La chaîne de preuves doit suivre la décision

Pour chaque objet, il faut conserver le condensat des octets reçus, la structure COSE, les octets d’en-tête protégé, la représentation exacte de typ, le type de charge, le point d’entrée, l’opération, l’ensemble de types attendu, la version du validateur, le résultat cryptographique, l’identité et l’usage permis de la clé, le parsing, les claims obligatoires, l’émetteur, l’audience, la fraîcheur, le rejeu, la décision d’autorisation, la branche choisie et l’effet observé.

Chaque reçu répond à un litige différent. La signature relie une clé à des octets. Le type attendu relie l’objet à une branche. Le parsing établit une forme. Le profil établit des contraintes sémantiques. La politique de clé établit la compétence du signataire. L’autorisation locale permet ou refuse l’opération. Enfin, l’application décrit le résultat.

La discipline des couches de réalité de docs/heng-lu-note.md évite qu’un petit symbole gagne une souveraineté qu’il n’a pas. Le label propose un chemin ; le code en cours d’exécution prouve que les barrières de ce chemin ont fonctionné.

Sources