Résumé

  • Le projet individuel draft-schrock-ep-authorization-evidence-chain-07, daté du 28 septembre, distingue VERIFIED et ACCEPTED là où la révision -06 mêlait contrôle natif et confiance locale.
  • Une référence de clé introuvable conduit à NOT_EVALUATED, non à une signature déclarée fausse ; une clé retrouvée ne bénéficie pas automatiquement de la confiance de l'opérateur.
  • La satisfaction d'une exigence documentaire ne vaut ni décision locale d'autorisation, ni preuve de l'exécution de l'action.

Supposons qu'une même attestation accompagne une demande de changement sur deux réseaux. Les octets ne bougent pas. Une équipe a inscrit la classe de clé et l'émetteur dans sa politique de confiance pour les autorisations de changement ; l'autre ne l'a pas fait. Si leurs tableaux de bord affichent tous deux « signature valide », l'écart déterminant est caché. Si l'un refuse la pièce, il ne prétend pas nécessairement que sa cryptographie est cassée. Il refuse de lui attribuer le rôle demandé.

La révision -07 de Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence, proposée par Ian Schrock, rend cet écart explicite. L'archive officielle porte la date du 28 septembre 2026. Il s'agit d'un Internet-Draft individuel, annoncé comme Informational par son auteur, et non d'une norme approuvée, d'un texte adopté par un groupe de travail ou d'un compte rendu de déploiement. La composition de preuves hétérogènes existait déjà dans la version -06. La nouveauté précise de -07 est d'avoir retiré la décision de confiance de l'ancien verdict unique VERIFIED pour lui donner un résultat distinct : ACCEPTED.

Le premier résultat répond aux contrôles cryptographiques et structurels propres à chaque composant. Le second dépend des paramètres fixés par la partie qui se fie à la pièce : annuaire des clés et état de ses entrées, émetteur, classe de clé, rôle et destinataire, politique native, version de format et instant de vérification. Ce sont des paramètres de l'opérateur, pas des étiquettes que le porteur de la preuve choisit pour lui. Pour un format qui ne contient qu'une référence à sa clé, il faut d'abord la résoudre. À défaut, le contrôle n'a pas été évalué.

Une clé retrouvée peut ensuite vérifier mathématiquement une signature tout en étant écartée pour l'usage envisagé. Et si deux opérateurs résolvent la même référence vers des clés différentes, même le résultat de vérification peut diverger : parler d'une validité universelle des seuls octets serait abusif.

Le texte refuse également de considérer les déclarations du présentateur — « vérifié », « accepté », ancre de confiance ou relation entre pièces — comme des résultats faisant autorité. La vérification doit être native et l'acceptation fondée sur les paramètres locaux. Un contrôle fait plus tôt à l'intérieur d'une même frontière protégée peut être réutilisé, mais le résultat interne doit être lié au condensat exact de la pièce, au profil du vérificateur, à l'état de confiance et à l'heure. Un fichier envoyé par l'agent qui annonce « déjà contrôlé » reste lui-même un objet à vérifier.

Cette contrainte explique pourquoi la séparation compte dans une chaîne de services : la confiance de l'un ne devient pas celle du voisin par simple transmission d'un booléen.

L'ordre des étapes évite une autre confusion. Seul un composant à la fois VERIFIED et ACCEPTED peut servir au rapprochement avec l'action matérielle attendue. Une autorisation authentique et recevable pour une autre action échoue à MATCH; ce n'est pas un refus de l'émetteur. Viennent ensuite l'actualité de la preuve, son statut, les contraintes de rôle et les liens établis entre composants. Le résultat SATISFIED dit seulement qu'une exigence documentaire désignée est remplie à un instant donné. Le système qui va réellement modifier le réseau garde une décision AUTHORIZED distincte, ainsi que la responsabilité de l'invocation et de ses effets.

La sortie de rejeu prévue en -07 contient un identifiant de révision de l'algorithme, les condensats de la chaîne, de l'action et de l'exigence, l'heure, l'empreinte de l'état de confiance et deux résultats par pièce : native_verification et acceptance. Les motifs devraient différencier échec cryptographique, contrôle impossible, refus de confiance et mauvaise action. C'est précieux pour comparer deux décisions sans forcer l'une à devenir la vérité de l'autre. La sortie est le compte rendu d'une évaluation proposée, non un certificat mondial ; le texte ne demande d'ailleurs aucune création de registre IANA.

Sources