Résumé

  • Le champ facultatif rtt du RFC 9891 exprime une estimation du client, non une consigne faisant autorité. Le serveur ACME choisit l’intervalle effectif, applique ses bornes et vérifie le retour par rapport à la durée de vie du Challenge Bundle initial.
  • Une réponse correcte établit un contrôle borné d’un Node ID pour une épreuve et une politique données. Elle n’établit ni propriété permanente, ni stabilité de route, ni émission ou installation du certificat, ni succès d’une session ou d’une application.

Le journal affichait cinq minutes de trajet prévu. Un analyste en déduisit cinq minutes de validation autorisée. L’écart entre ces deux phrases paraît minime ; il contient pourtant toute la répartition du pouvoir dans le protocole.

Le RFC 9891 étend ACME aux identifiants de nœuds d’un réseau DTN. Là où une validation classique utilise le Web ou le DNS, le serveur envoie un Challenge Bundle à l’Endpoint ID singleton présenté comme Node ID. Le BP Agent répond avec un Response Bundle corrélé. Cette mécanique accepte qu’un trajet soit intermittent ou lent, mais elle ne remet pas l’horloge du vérificateur au demandeur.

Le document, publié à titre expérimental en novembre 2025, enregistre le type d’identifiant ACME bundleEID, la méthode bp-nodeid-00 et le type d’enregistrement administratif BP correspondant. Il fournit un langage commun et une expérience reproductible. Il ne décrit pas un déploiement existant et ne résout pas à lui seul l’autorité de nommage entre organisations.

Une estimation utile, un pouvoir limité

Le Response Object peut contenir un rtt, en secondes, représentant l’aller-retour attendu entre le Challenge Bundle et sa réponse. Le RFC appelle explicitement cette valeur un indice. Si elle est présente, le serveur devrait normalement prévoir deux fois ce RTT, puis appliquer ses limites propres au réseau. Pour un DTN uniquement terrestre, la limite supérieure ne devrait pas dépasser soixante secondes.

Cette règle ne dit pas que tous les réseaux doivent partager la même borne. Elle dit que la valeur envoyée par le client entre dans une décision dont le serveur reste responsable. Le client connaît peut-être mieux la lenteur prévue de son chemin ; le serveur connaît sa capacité, son exposition au déni de service, la durée acceptable de conservation de l’état et la politique du certificat.

Avant de soumettre le Response Object, le client doit avoir configuré son BP Agent pour répondre. Son estimation devrait être pessimiste puisque le trajet exact des Bundles n’est pas garanti. Sa responsabilité porte sur la préparation et la qualité de l’information. Elle ne comprend pas le droit d’allonger unilatéralement la fenêtre.

Le test décisif utilise la date de création et la durée de vie du Challenge Bundle. Le Response Bundle a lui aussi une durée restante, mais le serveur ne lui permet pas de réécrire l’échéance initiale. Une réponse tardive ne devient pas valide parce qu’elle annonce qu’elle disposait encore de temps.

Cette asymétrie protège la valeur du test. Une fenêtre plus longue peut rendre accessibles des nœuds intermittents ; elle conserve aussi plus longtemps des ressources et un contexte attaquable. Une fenêtre trop courte réduit ce risque mais exclut un réseau légitime. Le compromis appartient à celui qui accepte ensuite la preuve.

Deux canaux fabriquent une seule preuve bornée

Le retour d’un paquet ne suffit pas. Le protocole sépare le secret de l’épreuve entre le canal ACME et le canal Bundle.

token-chal est propre à l’autorisation ACME et ne traverse pas le réseau BP. Chaque Challenge Bundle reçoit en plus son propre token-bundle, visible sur ce trajet. Le BP Agent combine ces deux éléments avec l’empreinte de la clé du compte ACME, calcule la Key Authorization, puis renvoie son condensat selon un algorithme accepté.

Le serveur vérifie alors plusieurs propositions distinctes :

  • la réponse arrive dans la fenêtre originale ;
  • son Node ID source correspond au Node ID examiné ;
  • un Block Integrity Block fiable protège le bloc primaire et la charge utile ;
  • les deux jetons correspondent à l’autorisation et au Bundle précis ;
  • l’algorithme a été proposé et le condensat est exact.

L’échec d’un seul contrôle fait échouer cette perspective. L’absence de réponse à temps produit le même statut, mais pas la même explication. Un délai peut venir du routage, d’une horloge, d’une configuration incomplète, d’un algorithme incompatible ou d’une règle de confiance. Garder le sous-problème est donc plus utile que conserver seulement « invalide ».

Une réussite a elle aussi un sens étroit. Elle relie la clé de compte, l’autorisation, un échange particulier et la capacité de répondre depuis le Node ID pendant une période bornée. Elle ne prouve pas l’unicité mondiale de cet identifiant. Elle ne mesure pas la qualité permanente du chemin.

Le RFC 9171 précise cette portée. Un Node ID est un Endpoint ID singleton utilisable pour identifier un nœud BP ; il n’est pas garanti unique à l’échelle mondiale et un nœud peut en posséder plusieurs. L’Administrative EID habituel fournit une unicité dans un schéma URI donné, non l’identité universelle d’une organisation.

Les registres ACME de l’IANA et Bundle Protocol de l’IANA garantissent que les logiciels attribuent le même sens à bundleEID, bp-nodeid-00, aux schémas dtn et ipn et au code administratif. Ils coordonnent des symboles publics ; ils n’observent pas les routes et n’allouent pas la confiance locale.

Plusieurs points de vue ne valent pas plusieurs mondes indépendants

Le serveur peut émettre plusieurs Challenge Bundles depuis des sources différentes ou tenter plusieurs trajets. Chaque Bundle reçoit son jeton, si bien que le résultat de chaque perspective reste identifiable. L’objectif est de rendre plus difficile une attaque limitée à un seul point du réseau.

Le RFC 9891 laisse cependant la décision globale à la politique du serveur. Il propose comme politique raisonnable la réussite de la perspective principale et au plus un échec secondaire. Le choix de ce qui est principal ou secondaire reste local. Deux serveurs peuvent donc appliquer des conclusions différentes à la même matrice d’observations.

Plusieurs demandes de route ne prouvent pas que les routes étaient indépendantes. Un même relais ou une même passerelle peut rester leur point commun. Le texte reconnaît que garantir le routage des Bundles n’est pas trivial ; l’utilité de la validation multi-perspective appartient au champ de l’expérience.

Une passerelle d’intégrité peut attester l’origine d’un Bundle après l’avoir vérifiée par des moyens propres à son réseau, puis poser un BIB. Le destinataire doit configurer quelles Security Sources peuvent attester quels identifiants. La passerelle témoigne dans un périmètre délégué. Elle ne devient pas l’autorité universelle du Node ID.

On retrouve ici le principe de Heng Lu dans Spécification initiale minimale et décision future localisée. Le socle commun décrit l’échange vérifiable ; les organisations qui supportent le risque conservent la décision sur le délai, la confiance et l’agrégation. La normalisation rend ces décisions compatibles, non identiques.

Après la validation commencent encore plusieurs opérations

Le RFC 8555 sépare l’épreuve, l’autorisation et la commande de certificat. Le statut valide signifie que le serveur considère le compte autorisé pour l’identifiant jusqu’à une échéance donnée. Une commande peut porter plusieurs identifiants, et chacun doit réussir sa propre validation.

Le RFC 9891 permet de combiner NODE-ID, DNS-ID et IP-ID dans une demande. Une réponse DTN parfaite ne remplace donc pas une validation DNS ou IP manquante. Même après toutes les autorisations, la CA conserve sa politique d’émission et vérifie les usages de clé et les algorithmes demandés.

Le RFC 9174 décrit l’étape d’utilisation. Un certificat TCPCL peut contenir un NODE-ID et l’usage étendu id-kp-bundleSecurity. Lors d’une vraie négociation, chaque pair applique sa politique à l’identité réseau, au Node ID ou aux deux. Un échec peut fermer la session.

Or le RFC 9891 laisse l’installation du certificat dans le BP Agent à l’implémentation. Autorisation valide, émission, installation, sélection pendant TLS, session TCPCL, transfert du Bundle et résultat applicatif forment donc sept faits différents. Aucun écran ne devrait les condenser sous une seule mention « certificat validé ».

Le RFC 9172 encadre la sécurité des blocs BP. Une intégrité cryptographique réussie démontre que les données couvertes valident sous un contexte et une clé. Elle ne décide pas à elle seule si la Security Source est autorisée à parler pour ce Node ID.

La distinction rejoint Running Code comme preuve première. La spécification fournit une procédure contrôlable ; seule la trace d’exécution montre qu’elle a eu lieu. Et Les couches de réalité et le pouvoir symbolique explique le danger du mot « valide » lorsqu’il perd sa durée, sa perspective et son objet.

Le client annonçait le délai. Le serveur pouvait mieux préparer son test. Il ne lui avait pas cédé son échéance. Le nœud répondait à l’épreuve. Cette réponse était une preuve réelle — précisément parce qu’elle ne prétendait pas être davantage.

Sources