Résumé

  • La révision 36 de draft-ietf-anima-rfc8366bis a été publiée le 9 septembre 2026. Elle se trouve toujours en évaluation IESG et n'est ni un RFC ni une norme proposée approuvée.
  • Le nouveau texte précise qu'un renouvellement vérifie si la relation antérieure tient encore : requête fraîche signée par le Registrar, état de révocation du certificat du Domain et politique éventuellement modifiée.
  • Le nouveau voucher prouve la décision positive du MASA. Il ne constitue pas un journal portable des sources, versions et exceptions consultées ; les documents étudiés ne disent pas ce que chaque service déployé conserve en interne.
  • Un reçu de décision distinct pourrait enregistrer les résultats indispensables, tout en laissant les détails contractuels confidentiels et l'autorité de renouvellement au MASA et au propriétaire du Domain. Cette proposition est celle de Daniel Kade.

Un mois de différence, une définition beaucoup plus exigeante

La révision 36 est apparue le 9 septembre, après la révision 35 du 12 août. Le registre Datatracker la place dans le groupe ANIMA, au stade IESG Evaluation avec le sous-état AD Followup. Le projet vise le Standards Track. Tant que la procédure n'est pas terminée, il n'a pas abrogé le RFC 8366 et n'a pas mis à jour le RFC 8995.

La nouveauté utile se trouve dans la partie consacrée aux renouvellements. La comparaison officielle ne se contente pas de corriger la forme. Elle explique ce que le mot « léger » recouvre.

Lors de la première émission, le constructeur peut devoir vérifier l'identité du demandeur et l'appartenance réelle du pledge. À l'étape suivante, il n'est pas nécessaire de rejouer toute cette enquête. Le MASA doit cependant confirmer que la relation établie reste valable. Il vérifie toujours la nouvelle Registrar Voucher Request : la signature montre que le Registrar dispose encore de la clé privée du Domain. Il consulte aussi l'état de révocation du certificat d'identité du Domain et applique les règles entrées en vigueur depuis le voucher précédent.

Deux exemples donnent à cette dernière phrase une portée concrète. Le propriétaire du Domain peut demander le blocage de futurs renouvellements. Un contrat de support peut arriver à échéance. Ce sont deux sources de décision différentes, l'une liée à l'autorité du propriétaire, l'autre à une condition commerciale. Le même service automatisé peut les appliquer, sans qu'elles deviennent pour autant la même règle.

Le voucher est la réponse, pas le dossier d'instruction

Le Registrar produit une requête fraîchement signée et y insère l'ancien voucher dans prior-signed-voucher-request. Ce chaînage associe le nouveau geste à l'artefact précédent. La preuve de possession de la clé du Domain est donc renouvelée au moment de la demande.

Le MASA émet ensuite un voucher signé que le pledge peut traiter. L'artefact doit rester assez simple pour un équipement qui ne dispose ni d'une grande mémoire ni d'un accès permanent aux services de statut. Il identifie le pledge, le Domain autorisé et les contraintes nécessaires à l'enrôlement. Il n'a pas vocation à embarquer une réponse OCSP complète, le texte d'un contrat ou le règlement interne du constructeur.

Cette sobriété est une qualité du protocole. La révision 36 indique d'ailleurs que le champ propriétaire du constructeur ne doit pas contenir de données exigeant la confidentialité, puisque le voucher peut être conservé par un Registrar ou un intermédiaire.

Il reste pourtant une question après l'émission. Si une enquête intervient six mois plus tard, le voucher signé atteste que le MASA a autorisé l'opération. Il ne donne pas nécessairement l'instant d'observation de l'état du certificat, l'identifiant de la politique exécutée, la classe de réponse du système contractuel ni l'existence d'une dérogation. Ces éléments peuvent se trouver dans des journaux privés. Aucune source ne démontre qu'ils en sont absents. Le problème est que leur forme n'est pas commune et que le voucher ne permet pas de les reconstruire.

Un appareil, une limite de retrait

La même révision explique le choix d'un voucher par pledge. Le modèle initial permettait d'appliquer un artefact à plusieurs appareils grâce à des expressions régulières sur leurs numéros de série. Mais retirer le renouvellement à tout un ensemble aurait été disproportionné si le changement de propriétaire ne concernait qu'un seul appareil.

La granularité du credential suit donc la granularité du pouvoir de dire non. Cette décision réduit le rayon d'une erreur ou d'un transfert. Elle ne rend pas le numéro de série universellement unique ; l'identité de l'émetteur reste nécessaire. Elle fournit surtout une règle de gouvernance très pratique : une autorisation doit pouvoir finir à l'échelle où la relation a réellement changé.

Un système de preuve devrait respecter cette unité. Une statistique de flotte ne suffit pas pour expliquer un cas litigieux. À l'inverse, l'enregistrement n'a aucune raison de dévoiler la localisation de l'équipement ou la valeur du contrat.

L'horloge ne doit pas être confondue avec la décision du MASA

Le projet recommande des vouchers à vie courte et non révocables, renouvelés par programme. Chaque protocole d'enrôlement définit la durée qui mérite le qualificatif « courte ». La chaîne de certificats peut encore être touchée par une révocation, mais le voucher lui-même n'a pas son propre objet de révocation.

Pour un voucher sans nonce, la fraîcheur dépend de la date d'expiration et de l'horloge interne du pledge. La révision 36 souligne qu'un adversaire pourrait contrôler le flux NTP pendant l'enrôlement. Un appareil sans horloge fiable doit donc recourir à un nonce et à un voucher éphémère, plutôt que faire semblant de connaître l'heure.

Il existe ainsi deux preuves temporelles. Le MASA doit pouvoir montrer ce qu'il a observé au moment d'émettre. Le pledge doit savoir s'il pouvait vérifier la fraîcheur au moment de consommer. Un voyant unique « valide » effacerait cette séparation des responsabilités.

Le contenu minimal d'un reçu de renouvellement

Un reçu utile peut rester hors du voucher. Il associerait : le condensat de l'ancien artefact et celui de la requête fraîche ; le pledge et le périmètre de son émetteur ; l'identité du Domain épinglé ; le MASA ; les heures de demande et de décision ; le résultat de possession de clé ; la méthode de statut du certificat, sa fraîcheur et son résultat ; l'identifiant et la version de la politique ; une classe contractuelle si elle intervient ; toute dérogation et son autorité ; la décision finale ; la nouvelle période de validité ; enfin le prochain déclencheur de revue ou de blocage.

Des codes de résultat et des condensats suffisent. Ils peuvent renvoyer vers des preuves dont l'accès reste protégé. Le reçu n'a pas besoin de normaliser la politique commerciale des constructeurs ; il doit seulement empêcher qu'une version de règle mutable soit remplacée par le souvenir de l'opérateur.

C'est une application de la spécification initiale minimale de Heng Lu : rendre interopérable la frontière indispensable, sans centraliser les choix ultérieurs. The Policy Mirror ajoute le bon test pour l'automatisation : l'exécution ne doit pas faire disparaître la règle qu'elle exécute.

Ce reçu n'est imposé ni par la révision 36, ni par ANIMA, ni par l'IESG. C'est une proposition éditoriale de Daniel Kade.

Limite des preuves

Le RFC 8995 décrit les rôles BRSKI et le contexte d'audit. Les RFC 5280 et 6960 fournissent le cadre du statut des certificats. Le projet distinct sur les considérations opérationnelles du MASA reste lui aussi un travail en cours.

L'ensemble permet de décrire les rôles et la modification textuelle. Il n'établit aucun incident, aucune émission fautive, aucun retard de révocation, aucun litige contractuel et aucun taux de déploiement. Il ne justifie donc pas d'accuser l'automatisation. Il justifie seulement de distinguer la signature obtenue de la trace qui explique pourquoi elle a été obtenue.

Sources