Summary

  • RFC 9891 allows an ACME client to supply an expected DTN round-trip time, but calls that value a hint. The ACME server still sets the actual response interval, applies network-specific limits and rejects a response that arrives outside the original Challenge Bundle's lifetime.
  • A timely, integrity-protected response can prove control of a Node ID for one challenge under one server policy. It does not prove permanent naming authority, path stability, certificate issuance, installation, session establishment, Bundle delivery or application outcome.

The certificate request showed rtt: 300. A dashboard translated that into a simple sentence: the validation had been approved to take five minutes. The sentence sounded reasonable. The client knew that its Delay-Tolerant Networking path was slow, and the protocol had given it a field in which to say so.

But the field did not contain approval. It contained an estimate.

RFC 9891, published as an Experimental IETF specification in November 2025, extends the Automatic Certificate Management Environment so a certificate authority can validate control of a DTN Node ID. It introduces a new ACME identifier, bundleEID, and a challenge called bp-nodeid-00. Instead of asking a web server or DNS zone to expose a token, the ACME server sends a Challenge Bundle toward the claimed Node ID and waits for a correlated Response Bundle.

Delay changes the mechanics of proof. It does not abolish the distinction between information and authority. The client can describe the journey it expects. The server still decides how long the door remains open.

A timing hint is not a delegated clock

The response object defined by RFC 9891 can carry an optional rtt: an expected number of seconds between sending a Challenge Bundle and receiving its response. The specification is unusually direct about its status. The number is a hint to the ACME server, not an authoritative value.

That distinction is operational, not semantic decoration. When a hint is present, the server should ordinarily choose a response interval of twice the RTT, then apply limiting logic. Both the lower and upper bounds depend on the network. For a terrestrial-only DTN, the upper limit should not exceed sixty seconds. Other networks can have very different delay characteristics, but the decision still belongs to server configuration and policy.

The client also must not tell the server to begin validation before its BP Agent is ready. RFC 9891 says the Response Object cannot be sent until the Agent has been configured to answer the challenge. The client is therefore responsible for preparing its side and giving a pessimistic estimate. It is not authorised to redefine the verifier's risk budget.

This separation matters because a claimant has an incentive to ask for more time. A large window can accommodate a slow or intermittent route, but it also retains challenge state longer, consumes validation capacity and enlarges the interval in which replayed or abusive traffic must be filtered. A very small window can reduce exposure while making legitimate delayed paths impossible. There is no universal optimum. The party that accepts the proof must own the policy.

The original Challenge Bundle fixes the decisive interval. A Response Bundle carries its own creation time and remaining lifetime, but the server checks arrival against the Challenge Bundle's creation time and lifetime. A responder cannot extend the proof by declaring a more generous lifetime on the way back. The return message reports within an authority already bounded elsewhere.

The proof is split across two channels

The validation is stronger than “a Bundle came back”. It is constructed so that neither visibility on the ACME channel alone nor visibility on the DTN path alone is sufficient.

The ACME challenge object includes token-chal, a random value unique to the authorisation. It travels over the ACME channel and does not appear in the Challenge Bundle. Every individual Challenge Bundle also carries a distinct token-bundle, which is visible on the BP channel. The responding Agent combines the two token parts with the ACME account-key thumbprint and returns a digest of the resulting Key Authorization.

The server then checks a joined record:

  1. the Response Bundle arrived inside the interval created by the original challenge;
  2. its source Node ID equals the Node ID being validated;
  3. a trusted Block Integrity Block covers the primary block and payload;
  4. the response repeats the correct challenge and Bundle tokens;
  5. the selected hash algorithm was one the server offered; and
  6. the digest equals the value derived from the ACME account key and both token components.

Failure at any of those checks makes that perspective fail. No response before the interval closes is also a failure. A green result therefore has specific content: someone able to use the ACME account context caused an appropriately protected BP Agent response to return from the claimed Node ID within a bounded challenge.

It does not say how long that control will last. It does not say who owns the name in law or policy. It does not say that the same route will work tomorrow.

A Node ID is narrower than a universal identity

RFC 9171, Bundle Protocol Version 7, defines an Endpoint ID independently of the intermediate forwarding used to reach it. A Node ID is a singleton EID usable to identify a BP Node. Yet a Node ID is not guaranteed to be globally unique, and a node can have more than one. The common Administrative EID is unique for a node within one URI scheme, not a universal civil identity.

That is why the IANA Bundle Protocol registry and the IANA ACME registry are important without being omniscient. IANA records the dtn and ipn URI scheme types, the bundleEID identifier, the bp-nodeid-00 validation method and the administrative-record code used by the exchange. Those entries make independent implementations refer to the same protocol elements. They do not allocate every operational Node ID, verify the topology behind it or determine which organisation may trust it.

The ACME server must normalise the identifier and must not simply dereference a Bundle EID as if it were a web address. Control is tested by a validation method. This prevents a registry-shaped string from becoming proof merely because it parses.

The difference follows the discipline in Heng Lu's Minimum Initial Specification and Localized Future Decision. The shared specification defines the minimum exchange: identifier syntax, tokens, integrity coverage, timing and comparison rules. Trust in a Security Source, acceptable delay, route diversity and certificate policy remain local decisions for the parties that bear their consequences.

Multiple perspectives remain a policy, not a miracle

An ACME server may send Challenge Bundles from several sources or across several routing paths. The aim is to reduce the chance that an on-path actor can satisfy or suppress the test from one vantage point. Each Bundle gets its own token-bundle, so every returned response can be evaluated separately.

RFC 9891 deliberately does not turn those results into one mandatory formula. Server policy decides whether the whole validation succeeds. The document recommends a possible rule: the primary perspective succeeds and no more than one secondary perspective fails. Which sources are primary or secondary is itself an implementation matter.

That means the final “valid” status contains a policy judgement. Two servers can observe the same perspective results and reach different overall decisions without either falsifying the individual observations. An audit that stores only the final status loses the rule that made it possible.

Nor does requesting several routes prove that the network supplied independent routes. RFC 9891 acknowledges that controlling Bundle routing is difficult. An integrity gateway can add another evidence layer by validating a Bundle's source through local means and applying a BIB as a trusted Security Source. But the receiver must know which gateway is allowed to attest for which source patterns. The gateway is a delegated witness with a configured scope, not a universal naming authority.

The Experimental status is significant here. The document says the unresolved question is partly the practical utility of Node ID validation across administrative domains: how naming authority is allocated, how a CA delegates trust to another network's integrity gateway, and whether multi-perspective techniques materially reduce the relevant attacks. A registered mechanism supplies a testable experiment. It does not pre-report the result.

Validation is still upstream of the certificate

RFC 8555 gives ACME its state machine. A client proves control through an offered challenge; the server moves the challenge from pending to processing and eventually to valid or invalid. A valid authorisation can be reused only within its stated expiry and policy. It is one input to an order, not the certificate itself.

RFC 9891 permits a certificate request to combine NODE-ID, DNS-ID and IP-ID identities. Each identifier has to be validated. A successful Node ID challenge cannot rescue a failed DNS or IP authorisation, and the certificate authority still applies its issuance policy, key-usage constraints and algorithm rules.

If a certificate is issued, RFC 9174 defines how a TCP convergence-layer peer can later use it. The certificate can carry a NODE-ID and the id-kp-bundleSecurity extended key purpose. During a real session, policy may require network-identifier authentication, Node ID authentication or both. A mismatch can terminate the session.

RFC 9891 leaves installation of the issued certificate into the BP Agent to the implementation. That single sentence prevents a large evidentiary mistake. A valid ACME authorisation does not prove issuance. Issuance does not prove installation. Installation does not prove selection in a TLS handshake. A successful handshake does not prove Bundle forwarding, application processing or the external result for which the system was built.

RFC 9172 supplies the BPSec architecture used to protect Bundle blocks, but integrity coverage answers a bounded question too: whether covered data validates under a particular security context and key. It does not manufacture trust in the Security Source or authority over the Node ID. Those are policy and custody questions around the cryptographic result.

This is also the point of Heng Lu's Running Code as Primary Evidence. The standard defines a credible proof procedure. Only a captured exchange can show that one implementation performed it; only later runtime evidence can show how the certificate was used. Specification, configured policy, observed validation and operational outcome must remain separate records.

His essay on Reality Layers and Symbolic Power explains the organisational temptation to collapse them. “Valid” is a powerful word. Once displayed without the challenge scope, time, perspective set and policy, it can appear to certify ownership, permanence and service health. The system becomes more legible when the badge is replaced by the joins it concealed.

The client predicted the delay. That prediction improved the server's planning. It did not take possession of the server's clock. The Node ID answered the challenge. That answer supplied a bounded proof. It did not turn one successful round trip into permanent authority over every future path and outcome.

Sources