Résumé

  • La RFC 9891 est une spécification IETF expérimentale qui étend ACME pour valider un identifiant de nœud du réseau tolérant aux délais, représenté comme identité de certificat BundleEID et identifiant ACME bundleEID.
  • La preuve est scindée intentionnellement. token-chal passe par l’échange ACME ordinaire ; token-bundle est placé dans un Bundle de défi particulier. Un BP Agent renvoie un Bundle de réponse dont le condensat est lié au défi du compte ACME et à la réception de ce Bundle.
  • Ici, un Node ID est un Bundle Protocol Endpoint ID singleton. L’extension ne rend pas valide un EID non singleton.

La question opérationnelle est de savoir si l’identifiant singleton visé, et non un observateur placé sur le chemin ou un simple gateway de confiance, a réalisé l’autorisation ACME exacte. Le serveur envoie un ou plusieurs Bundles de défi à l’identifiant revendiqué. Le BP Agent côté client renvoie des Bundles de réponse. Les contrôles portent sur l’identité bundleEID attendue, la relation entre les jetons, l’autorisation par la clé du compte, le lien de condensat et la réception du Bundle de défi particulier. Le jeton transporté dans le Bundle ne remplace pas le jeton du défi ACME : l’architecture conserve du matériel d’autorisation sur deux canaux.

Une identité de certificat peut désigner un BundleEID, mais cela ne détermine pas qui possède l’autorité de nommage entre organisations. La RFC 9891 ne définit ni régime universel de nommage, ni modèle de déploiement, ni politique de gateway. Un gateway d’intégrité optionnel peut attester la source de Bundles de réponse ; sa politique, la délégation de confiance et son rapport avec le serveur ACME restent à définir par les implémentations et les organisations. Les mécanismes de sécurité du protocole Bundle forment une limite de sécurité pertinente, pas une solution automatique à ces questions de gouvernance.

La RFC examine aussi les attaques sur le chemin et la valeur encore incertaine d’une validation multiperspective. Les perspectives peuvent voir des overlays DTN et des routes différents ; la topologie DTN peut diverger de celle du réseau IP sous-jacent. L’expérimentation n’établit donc ni l’efficacité de plusieurs perspectives dans un réseau donné, ni une latence, une disponibilité, une tolérance au déni de service, une fréquence de déploiement ou un taux de réussite opérationnelle.

Fixtures de vérification

Pour un échange borné, l’opérateur peut réunir : un Node ID singleton et son bundleEID exact ; une clé de compte ACME et le défi du compte ; un token-chal enregistré ; un Bundle de défi avec un token-bundle distinct ; l’identifiant de ce Bundle et l’heure de réception ; le Bundle de réponse et son condensat ; enfin, si nécessaire, l’attestation du gateway et sa politique de validation. Le résultat attendu lie le défi du compte à ce Bundle reçu précis, et non à une chaîne observée ailleurs. Un EID non singleton constitue un cas négatif. Une réponse sans relation de condensat attendue, ou sans réception du défi pertinent, est également négative. Ces fixtures aident à vérifier ; elles ne sont pas des artefacts de déploiement imposés par la RFC.

Sources