Résumé

  • La liste protégée crit oblige le destinataire à comprendre et prendre en charge chacune des extensions qu’elle nomme ; sinon, la JWS est invalide.
  • Cette règle empêche un logiciel ancien de valider une signature tout en ignorant une modification essentielle de la manière d’interpréter le message.
  • Le succès de l’opération cryptographique, le traitement JOSE et l’acceptation métier doivent produire trois décisions traçables, et non un unique voyant vert.

Le test oublié après le calcul

Un service reçoit un objet signé, retrouve la clé attendue, reconstitue l’entrée de signature et obtient une égalité parfaite. La tentation consiste à arrêter le raisonnement ici. Pourtant, l’en-tête protégé contient une extension inconnue dont le nom figure dans crit. Pour ce service, la RFC 7515 donne une consigne sans ambiguïté : la JWS n’est pas valide.

Ce refus ne contredit pas le résultat mathématique. Il reconnaît sa portée. La signature établit que certains octets ont été protégés par une clé selon un algorithme donné. Elle ne prouve pas que le destinataire sait quelle règle nouvelle ces octets activent. Continuer en appliquant les anciennes conventions ferait de l’intégrité une garantie sur un sens que personne n’a réellement vérifié.

crit contient un tableau de noms de paramètres d’en-tête. Chaque nom doit désigner une extension effectivement présente dans l’en-tête JOSE, comprise et prise en charge par le destinataire. Le tableau ne peut être vide, comporter deux fois le même nom ni servir à répéter les paramètres déjà définis par JWS ou JWA. Surtout, crit appartient exclusivement à l’en-tête protégé : placer hors signature la liste de ce qui doit être compris permettrait de modifier cette obligation en transit.

Les paramètres inconnus non déclarés critiques peuvent, en règle générale, être ignorés. Cette asymétrie est le mécanisme d’évolution. Elle laisse voyager une information facultative sans casser les anciens récepteurs, tout en donnant à une extension qui change le traitement un moyen de rendre l’ignorance impossible.

Sakimura et la compatibilité sous contrainte

Nat Sakimura figure parmi les auteurs de la RFC 7515 avec Michael B. Jones et John Bradley. Son parcours au sein des standards d’identité et de l’OpenID Foundation aide à situer le problème, sans lui attribuer seul une œuvre collective : les systèmes d’identité vivent longtemps, traversent de nombreux fournisseurs et doivent évoluer alors que leurs consommateurs ne changent pas tous au même rythme.

Le choix de conception est remarquable par sa sobriété. La norme ne cherche pas à deviner toutes les futures extensions. Elle institue un droit de refus local. L’émetteur signale les nouveaux éléments sans lesquels son message serait mal compris ; le destinataire n’a le droit de poursuivre que s’il peut démontrer leur traitement. Une signature réussie ne lui permet pas de contourner ce contrat.

La notion de « critique » ne décrit donc ni la gravité d’un incident ni la sensibilité d’une donnée. Elle exprime une dépendance sémantique. L’auteur d’une extension doit décider si elle peut rester un conseil facultatif ou si elle modifie la construction et l’interprétation du message. L’émetteur doit l’annoncer correctement. Le vérificateur doit relier le nom à une implémentation connue et à une politique autorisée.

Cette chaîne peut se casser de façon discrète. Une bibliothèque parse l’en-tête, une passerelle vérifie la signature et une application reçoit seulement authenticated=true. Si la passerelle ignore l’extension ou perd le détail du verdict, l’application ne peut plus distinguer une preuve comprise d’une preuve simplement calculée. Les composants paraissent tous fonctionner, mais la propriété de sécurité a disparu entre deux interfaces.

b64:false, l’expérience grandeur nature

La RFC 7797 montre à quoi sert cette discipline. Dans le fonctionnement ordinaire de JWS, la charge utile est encodée en base64url pour former l’entrée de signature. L’extension b64, lorsqu’elle vaut false dans l’en-tête protégé, permet au contraire de signer la charge utile non encodée. Le changement touche directement les octets soumis à la signature et certaines contraintes de sérialisation.

Une JWS utilisant cette option doit inscrire b64 dans crit. Un destinataire qui ne connaît que le comportement historique rencontrera alors une extension critique inconnue et rejettera l’objet. Il ne tentera pas de lui appliquer silencieusement la règle d’encodage habituelle. Le refus évite que l’émetteur et le récepteur déclarent valide un même conteneur tout en ne parlant pas du même message.

La connaissance technique de l’option ne suffit toujours pas. Un profil d’application peut exiger une valeur constante afin d’éviter des ambiguïtés entre objets. Certains octets de charge utile rendent la sérialisation compacte délicate. Et la RFC 7797 interdit cette option aux JWT. Un moteur JWS parfaitement conforme peut donc savoir vérifier b64:false, tandis que l’application JWT qui l’emploie doit le refuser.

Cet exemple rend visibles trois niveaux. La cryptographie répond à la question « les octets correspondent-ils ? ». Le processeur JOSE répond à « toutes les règles indispensables ont-elles été appliquées ? ». L’application répond à « cet objet est-il permis ici, pour cet usage ? ». Transformer ces réponses en un seul booléen détruit l’information dont dépend le contrôle suivant.

Connaître un algorithme n’est pas l’autoriser

La RFC 7518 fournit le vocabulaire algorithmique de JOSE. Mais une implémentation capable d’exécuter un algorithme n’est pas obligée de l’accepter dans chaque contexte. La RFC 7515 laisse aux applications la définition de leurs algorithmes admissibles. Une bonne signature avec une suite cryptographique interdite par la politique reste une raison de refus.

La RFC 8725 renforce ce principe pour les JWT. Le vérificateur doit limiter explicitement les algorithmes acceptés et ne pas laisser un champ contrôlé par l’attaquant choisir seul la méthode de confiance. Il doit contrôler l’émetteur, le destinataire, le sujet et les contraintes propres au profil. Des types de JWT destinés à des fonctions différentes peuvent nécessiter des règles mutuellement exclusives pour éviter qu’un jeton soit réutilisé dans un autre rôle.

crit n’endosse aucune de ces décisions. Il garantit seulement que certaines extensions ne seront pas ignorées. Deux systèmes peuvent connaître le même paramètre et diverger légitimement sur son admission. Ils peuvent également réussir toute la validation JOSE et refuser l’action parce que l’audience est erronée ou que la politique métier n’accorde pas le droit demandé.

Plusieurs signatures, plusieurs chemins de confiance

La sérialisation JSON permet à une JWS de porter plusieurs signatures. La RFC 7515 décrit une validité générale lorsqu’au moins une signature est valide, tout en laissant à l’application le soin d’imposer une règle plus exigeante. Il faut conserver le chemin exact par lequel cette condition a été satisfaite.

Chaque signature possède son propre en-tête protégé et peut donc annoncer ses propres extensions critiques. Pendant une migration, une signature ancienne peut assurer la compatibilité tandis qu’une nouvelle signature introduit un algorithme ou une sémantique différente. Une règle vague du type « une signature a fonctionné » transforme le chemin historique en possibilité durable de repli. La règle inverse, « toutes doivent fonctionner », peut provoquer une panne si certains récepteurs ne maîtrisent pas encore la nouveauté.

Il faut nommer la politique : signatures requises, clés autorisées, extensions admises, durée de la coexistence et condition de retrait de l’ancien chemin. JOSE permet d’exprimer la pluralité ; il ne prend pas la décision de transition à la place de l’exploitant.

Un journal qui dit pourquoi

La télémétrie devrait séparer le résultat cryptographique, le résultat de traitement JOSE et le verdict applicatif. Le premier inclut l’algorithme, une référence de clé, la construction de l’entrée de signature et le résultat. Le deuxième indique la validité de l’en-tête protégé, les paramètres critiques rencontrés et le module ayant traité chacun d’eux. Le troisième rattache l’objet à l’émetteur, l’audience, au profil, aux règles d’autorisation et à l’effet demandé.

Il n’est pas nécessaire d’inscrire des secrets ou le contenu intégral du jeton. Des identifiants stables et des codes de motif suffisent à éviter de fausses explications. Qualifier de « mauvaise signature » un échec dû à une extension inconnue envoie les équipes chercher une clé. Qualifier de « jeton valide » une preuve techniquement correcte mais refusée par l’audience masque la politique qui a réellement tranché.

La contribution institutionnelle de crit tient dans cette discipline : une partie ne peut pas affirmer avoir compris un message uniquement parce qu’elle en a authentifié l’enveloppe. La norme protège le droit d’un nouveau sens à ne pas être ramené silencieusement à l’ancien.

Sources