Summary

  • RFC 9891 is an Experimental extension to ACME. It validates a Delay-Tolerant Networking Node ID represented through a BundleEID certificate identity and a bundleEID ACME identifier.
  • The proof is deliberately split. token-chal travels through the ordinary ACME exchange; token-bundle is placed in a particular challenge Bundle. A BP Agent returns a response Bundle whose digest is tied to the ACME account challenge and receipt of that challenge Bundle.
  • A Node ID here means a singleton Bundle Protocol Endpoint ID. A non-singleton EID is not made valid merely by using the extension.

The operational question is not simply whether a Bundle arrived. It is whether the intended singleton Node ID, rather than an on-path observer or merely trusted gateway, completed the exact ACME authorization. The server sends one or more challenge Bundles to the claimed Node ID. The client-side BP Agent returns response Bundles. Validation checks the expected bundleEID identity, the challenge token relationship, the account-key authorization, the digest binding, and the fact that the response corresponds to receipt of a particular challenge Bundle. The token carried in the Bundle is not a replacement for the ACME challenge token: the design keeps authorization material across two channels.

A certificate may identify a BundleEID, but that identity does not by itself answer who has naming authority across organizations. RFC 9891 does not define a universal naming regime, deployment model, or gateway policy. An optional integrity gateway can attest to the source of response Bundles, yet its policy, delegated trust, and relationship to the ACME server remain questions for an implementation and its organizations. Bundle Protocol security mechanisms provide a relevant security boundary, not an automatic settlement of those governance questions.

The RFC also studies on-path attacks and the uncertain value of multi-perspective validation. Perspectives can observe different DTN overlays and routes; DTN topology need not match the underlying IP topology. The experiment therefore does not establish that multiple perspectives will be effective in a particular network, nor does it report latency, availability, denial-of-service tolerance, production prevalence, or operational success rates.

Verification fixtures

An operator can test a bounded exchange with these concrete fixtures: one singleton Node ID and its exact bundleEID; one ACME account key and account challenge; a recorded token-chal; a challenge Bundle carrying a distinct token-bundle; the challenge Bundle identifier and receipt time; the returned response Bundle and its digest; and, if used, the integrity gateway attestation and validation policy. The expected result is a response whose checks bind the account challenge to that specific received Bundle, not just to a string observed elsewhere. A non-singleton EID is a negative fixture. A response lacking the expected digest relationship, or arriving without the relevant challenge receipt, is also negative. These fixtures are verification aids, not RFC-mandated deployment artifacts.

Sources