Summary

  • Dans une proposition individuelle de l'IETF, une personne signe au moyen d'une clé d'accès un plafond de 200 livres pour les achats d'un agent. Le vérificateur relève bien les 230 livres du journal d'exemple.
  • Le calcul s'arrête aux frontières d'un journal. Deux journaux utilisant la même autorisation peuvent présenter chacun des dépenses conformes, alors que leur somme franchit le plafond signé.

Le portefeuille n'a pas de frontière de journal

Le bureau fictif du projet d'Izmaylov commande du papier et du toner. Son agent dispose de 200 livres au total, jamais plus de 100 livres par commande. Le fournisseur contresigne chaque achat; au-delà de 60 livres, la personne qui délègue doit approuver l'acte précis. À la fin de l'exemple, le journal atteint 230 livres. Le vérificateur signale le dépassement et une approbation absente. Tout fonctionne comme prévu: la règle et les dépenses se trouvent dans le même livre.

Déplaçons seulement la frontière comptable. Une même autorisation alimente deux journaux. Dans chacun, des commandes correctement approuvées et contresignées totalisent 125 livres. Chaque contrôle local conclut à une dépense inférieure à 200. Le portefeuille, lui, a payé 250. Cet essai à deux livres est un calcul construit à partir de la règle publiée, pas le compte rendu d'un achat réel. Le texte lui-même avertit que les plafonds, les comptes et les périodes sont vérifiés dans un seul journal; deux journaux portant la même autorisation ne sont pas additionnés.

Le conflit n'est donc pas entre une bonne et une mauvaise signature. La personne peut avoir signé exactement 200 livres. L'agent peut avoir signé chaque reçu. Le fournisseur peut avoir ajouté sa propre signature aux commandes. La question décisive vient avant la cryptographie: qui décide où se trouve l'unique solde opposable aux deux exécutants? Si personne ne tient ce solde, chaque côté peut montrer un dossier impeccable pour un budget déjà épuisé par l'autre.

Ce que le contrôle sait faire

La révision 01, datée du 24 octobre, est un Internet-Draft individuel. Le registre officiel de l'IETF n'indique ni adoption dans un flux de travail ni directeur de domaine responsable. La proposition spécifie néanmoins des objets précis: autorisation signée par la personne, limites par somme, par acte, par nombre et par période glissante; reçu signé par l'agent; journal à racines signées et horodatées. Un tiers peut ensuite vérifier hors ligne les éléments qui lui sont remis.

L'auteur a resserré plusieurs règles entre les versions 00 et 01. L'annexe C précise que les octets des enregistrements restent les mêmes, mais que certaines clés, longueurs de signature et valeurs de champ autrefois acceptées sont désormais rejetées. La vérification d'un dossier devient plus stricte. Son périmètre comptable reste celui du journal reçu.

Le projet ne place pas un contrôleur devant la caisse pour refuser une commande avant qu'elle produise un effet. Dans son propre exemple, le dernier achat fait passer le total à 230 livres; le rapport constate ensuite la violation. Ce constat peut servir à une réclamation, à une enquête ou à revoir le dispositif. Le fournisseur a déjà traité l'opération que le journal décrit. Une entreprise qui veut un plafond exécuté au moment de l'achat doit montrer le mécanisme de refus, en plus du mécanisme de preuve.

La nuance entre les pièces compte. Un reçu de l'agent dit ce qu'il déclare avoir fait. La contresignature atteste qu'une clé désignée pour le fournisseur a signé le reçu; le projet souligne que cette clé ne prouve pas à elle seule l'identité de son détenteur. L'approbation de la personne porte sur un acte précis au-dessus du seuil. Le journal enchaîne et date les pièces. Aucun de ces éléments n'effectue l'addition entre deux journaux que le vérificateur n'a pas rapprochés.

Une preuve parfaite, un total incomplet

Le dispositif emprunte l'arbre de Merkle de la RFC 9162. Une racine signée conservée par un tiers peut dénoncer une réécriture de l'histoire qu'elle couvrait. Une preuve de cohérence établit qu'un arbre s'est étendu sans modifier son ancien contenu. Voilà une réponse à la question « ce registre a-t-il changé? ». La question « où sont tous les achats imputables à cette autorisation? » réclame une vue sur les autres registres.

Le texte énumère aussi le retrait possible d'une racine finale que personne d'autre ne garde et la présentation de deux vues divergentes par le conservateur. Ces risques portent sur la visibilité de l'histoire. Le problème du budget subsiste même si deux journaux sont conservés honnêtement: 125 plus 125 fait 250, et aucun verdict local ne fait cette somme. Le numéro de l'autorisation permettrait à un enquêteur de chercher des doublons. Il n'installe ni registre commun, ni réservation atomique, ni règle de rapprochement au moment d'exécuter.

Le tableau de mise en œuvre donne un point de départ concret. Il cite des bibliothèques JavaScript et Python du même auteur, signale que la version Python ne contrôle pas encore une signature SLH-DSA de la racine et note un problème de lecture d'attributs d'horodatage. Aucune mise en œuvre indépendante connue n'y figure. L'étape qui modifierait le jugement serait un essai public avec deux enregistreurs concurrents et une démonstration du refus du dépassement dans un solde partagé.

Sources