Résumé

  • Le paramètre 15 de RFC 9597 place une carte de revendications CWT dans un en-tête COSE, y compris lorsque la charge est chiffrée, détachée ou d’un autre format.
  • Une valeur lue tôt peut orienter une recherche de clé, mais toute décision prise avant la validation cryptographique reste provisoire et doit être confirmée.
  • La cohérence entre copies d’en-tête et de charge, la protection, l’interprétation, la confidentialité et l’autorisation produisent des preuves différentes.

Un service reçoit un objet chiffré. Il ne peut pas encore examiner la charge, mais il voit un émetteur dans l’en-tête. Il interroge l’annuaire de clés associé, obtient un candidat et prépare le traitement. Le gain de temps est réel. La confiance, elle, ne l’est pas encore.

C’est la frontière que RFC 9597 oblige à rendre explicite. Le standard corrige une lacune de CWT : comme pour JWT, certaines revendications doivent parfois être accessibles avant le déchiffrement, avec une signature détachée ou auprès d’une charge qui n’est même pas du CBOR. Il normalise leur emplacement, non leur autorité.

Un espace commun, pas une décision commune

Les numéros courts servent à la fois aux paramètres COSE et aux revendications CWT. Les mélanger directement créerait des collisions. RFC 9597 enregistre donc « CWT Claims » sous le numéro 15 dans le registre COSE de l’IANA. Sa valeur est une carte dont les clés viennent du registre CWT de l’IANA. La notation de RFC 8610 décrit la forme ; elle ne prouve pas qu’un programme l’a validée.

Les revendications de RFC 8392 — émetteur, sujet, audience, échéance, date d’effet, émission, identifiant — deviennent ainsi transportables dans l’en-tête. Mais le paramètre peut aussi accompagner un objet COSE dont la charge n’est pas un CWT. Une carte de revendications CWT ne transforme donc pas la charge en jeton.

Le standard ne fixe pas les sémantiques propres à chaque application. Le profil local doit dire quelles revendications sont admises, dans quel contexte et pour quelle opération. Le registre coordonne les noms ; l’exploitant conserve la responsabilité du résultat.

La protection doit couvrir la valeur et son interprétation

RFC 9052 distingue les cartes protégée et non protégée. RFC 9597 recommande la carte protégée et interdit que le paramètre apparaisse deux fois entre les deux cartes. Une implémentation doit pourtant décider quoi faire d’une occurrence non protégée : refus, indice sans confiance ou usage extrêmement limité.

Une revendication protégée n’est pas automatiquement vraie. La cryptographie relie des octets à une opération et à une clé. Elle ne dit pas que cette clé avait qualité pour déclarer cet émetteur, que l’audience inclut le service, que la valeur est récente ni que l’action est autorisée.

L’interprétation doit elle aussi être déterminée sans ambiguïté. RFC 9597 recommande le paramètre typ de RFC 9596 lorsqu’aucun contexte naturel ne suffit. Le résultat de la pièce précédente est donc un input de celle-ci : le type choisit le contrat d’interprétation, puis ce contrat décide comment traiter la carte. Une valeur protégée interprétée par un sélecteur malléable reste une chaîne fragile.

La découverte de clé n’est qu’une hypothèse de travail

Le standard autorise une réalité opérationnelle : il faut parfois lire l’émetteur avant de savoir quelle clé permettra de valider l’objet. Le problème n’est pas la requête de découverte. Le problème est ce qu’elle a le droit de produire.

Avant validation, la valeur peut sélectionner un espace de recherche ou une file isolée. Elle ne devrait ni choisir définitivement le locataire, ni ouvrir un budget illimité, ni écrire un état durable, ni autoriser une transaction. Le système doit conserver la valeur exacte reçue, sa carte de protection, la branche provisoire, la requête, les clés candidates et l’issue cryptographique.

Si la validation échoue, les effets provisoires doivent disparaître ou rester explicitement en quarantaine. Un cache indexé par l’émetteur non vérifié, puis conservé après rejet, constitue déjà une décision non annulée.

RFC 9597 dit précisément que les décisions provisoires fondées sur une information non vérifiée doivent être confirmées après le traitement cryptographique. Il faut donc tester l’échec tardif : recherche réussie suivie d’une mauvaise signature, type inattendu, audience incorrecte ou charge détachée différente.

Les deux copies doivent raconter la même histoire

Quand une revendication existe dans l’en-tête et dans la charge d’un CWT, le destinataire doit vérifier l’identité des valeurs, sauf règle applicative particulière. Ce principe prolonge le mécanisme analogue de RFC 7519 et évite qu’un proxy traite l’émetteur A pendant que l’application autorise l’émetteur B.

La règle particulière ne peut pas être une permission vague. Elle doit désigner la copie consommée par chaque composant, sa protection, la raison de la divergence et la version du profil. Sinon, l’exception devient un tunnel entre deux autorités.

L’égalité ne valide pourtant rien au-delà de la cohérence. Deux audiences identiques peuvent être fausses pour ce service ; deux échéances identiques peuvent être dépassées. RFC 8725 rappelle la nécessité de validations explicites et de règles non ambiguës. La comparaison est un reçu ; la vérité et l’autorisation en sont d’autres.

Sortir une revendication du chiffrement est un acte de divulgation

La visibilité avant déchiffrement signifie que la revendication n’est pas chiffrée. Émetteur, sujet, audience et identifiant peuvent révéler une organisation, un appareil, un destinataire ou permettre une corrélation. Copier une carte entière « pour le diagnostic » peut vider la confidentialité du jeton de sa substance.

Le profil doit minimiser : quelle valeur minimale est nécessaire à la tâche précoce ? Qui l’observe sur le réseau, dans les files, les journaux, les traces et les erreurs ? Combien de temps reste-t-elle ? Une classe de routage moins précise peut-elle remplacer un sujet stable ? Une signature correcte n’accorde aucune autorisation de publier.

Une charge détachée allonge encore la preuve

Avec un contenu détaché, l’application doit garantir que les octets transportés séparément n’ont pas changé. Un émetteur visible et une validation COSE ne suffisent pas si le vérificateur récupère le mauvais fichier. Il faut conserver l’origine de la charge, les octets ou le condensat, leur liaison à l’objet et le résultat final.

La conclusion correcte reste étroite : la revendication était visible ; cette valeur et son interprétation ont été protégées et validées ; la copie de charge a satisfait la règle ; la politique locale a autorisé l’action ; l’effet a été observé. Aucun maillon ne doit parler au nom du suivant.

Sources