Résumé

  • La version 02 d’un projet individuel de l’IETF autorise les paramètres facultatifs et ceux que le jeton ne nomme pas. Un paramètre omis prend la valeur par défaut de l’outil, invisible pour le vérificateur.
  • L’entrée "*" laisse passer des paramètres ajoutés plus tard à l’outil. Le jeton reste signé, mais le pouvoir qu’il ouvre peut changer avec l’interface.

Une ligne blanche dans la procuration

Une entreprise remet à son agent un jeton signé qui autorise un outil et certains paramètres. L’outil évolue et gagne une nouvelle commande. Le jeton ancien peut-il encore servir ? Dans la nouvelle version du projet de Niki Aimable Niyikiza, un astérisque peut suffire. La signature authentifie le jeton; elle ne rappelle pas son émetteur pour lui demander s’il approuve cette commande nouvelle.

L’annonce du 27 octobre et la fiche Datatracker situent le texte au stade de projet individuel. Le dispositif proposé, appelé AAT, permet au détenteur de fabriquer hors ligne un jeton de portée égale ou plus étroite. Le point de contrôle vérifie la chaîne de signatures, puis confronte l’appel de l’outil à la carte des paramètres inscrite dans le dernier jeton. La frontière est nette sur le papier. Elle bouge lorsque l’outil change de vocabulaire.

Dans la version 01, un paramètre absent de cette carte était refusé; un paramètre nommé devait être fourni. La nouvelle version remercie un auteur d’implémentation indépendante d’avoir repéré l’impasse : impossible de contraindre un paramètre réellement facultatif. La version 02 introduit donc optional: true pour une entrée nommée et "*" pour les entrées non nommées. Cette étoile n’impose aucune limite de valeur. Une carte vide revient à ouvrir la même porte.

Le défaut appartient à l’outil

L’exemple du projet fixe le chemin d’un fichier et borne les nombres facultatifs de lignes en tête et en fin de lecture. Quand l’agent indique head, le contrôleur peut vérifier la borne. Quand il l’omet, l’outil applique son réglage par défaut, que le contrôleur ne voit pas. Le texte souligne qu’un head absent peut conduire un outil de lecture à rendre tout le fichier. Rendre un paramètre facultatif, c’est donc aussi accepter le résultat de son omission.

L’astérisque ouvre un risque dans le temps. Il autorise tout paramètre non nommé, y compris celui qu’une mise à jour de l’outil ajoutera demain. Le projet déconseille cette ouverture pour les outils qui produisent des effets. Il permet aussi au point de contrôle de refuser les paramètres absents du schéma public de l’outil. Il ne fixe pourtant pas de version de schéma dans chaque jeton et n’oblige pas à demander un nouvel accord à l’émetteur quand l’interface s’élargit.

On peut alors voir un contrôle cryptographique réussir sans avoir répondu à la question intéressante. Oui, la chaîne est signée. Oui, l’appel satisfait la carte des contraintes. Mais qui a autorisé la valeur par défaut actuelle ou le nouveau paramètre ? La preuve exige le schéma réellement utilisé, la version de l’outil et une décision sur cette ouverture. Le sceau du jeton ne contient pas l’avenir de l’outil.

L’annexe F de la version 02 prévient que plusieurs changements normatifs rompent les implémentations de la version 01. Les paramètres facultatifs et non nommés en font partie. La section de sécurité reconnaît le marché passé : davantage de compatibilité contre moins de contrôle. Cette souplesse évite de réémettre un jeton à chaque modification. Elle donne aussi à ceux qui maintiennent l’outil un moyen de modifier la portée pratique d’une autorisation sans toucher au jeton.

Documents d’origine