Summary

  • RFC 9891 binds an ACME account challenge to one or more time-limited Bundle Protocol responses. A successful validation says that the configured policy accepted control evidence for a bundleEID at that moment.
  • It does not establish who allocated the Node ID, which routes are legitimate, whether a gateway had authority to attest, or whether the resulting certificate and private key were later installed and used.

Imagine a certificate authority sending a challenge into a network where a reply may take minutes, traverse intermittent links and return through an intermediary that signs what it saw. A reply eventually arrives. Its source identifier matches. Its integrity block verifies. Two random token parts recombine into the expected digest. The validation turns green.

What became true?

The narrow answer is the useful one: a particular ACME policy accepted a particular response for a particular Node ID and account key within a particular interval. RFC 9891 gives operators a way to obtain exactly that evidence across Delay-Tolerant Networking. It does not turn the green result into a deed, a routing authorization or proof that the certificate is now running on the node.

The distinction matters because DTN joins two systems with different clocks and control surfaces. ACME normally coordinates certificate orders over HTTPS. The Bundle Protocol moves messages through disruptions and long delays. RFC 9891 introduces the ACME identifier bundleEID and the challenge bp-nodeid-00 so the HTTPS-side order can be joined to a Bundle exchange with the Node ID under test. Both names are now recorded in the IANA ACME registry, while the validation administrative record is recorded in the IANA Bundle Protocol registry.

Two channels, one temporary proof

The challenge is split deliberately. token-chal travels to the client through ACME and remains off the Bundle channel. Each Challenge Bundle carries its own token-bundle. The responding BP Agent combines both values with the ACME account-key thumbprint and returns the resulting digest. An observer of only the Bundle path lacks one token; a party with only the HTTPS exchange cannot answer without receiving the Bundle.

That is stronger than asking whether a string appears in a database. It is still a challenge, not a transfer of authority.

The client first configures its BP Agent to recognize an id-chal and answer only during the authorized interval. Only then may it tell the ACME server to proceed. Because delay is intrinsic, the client may submit an expected round-trip time. RFC 9891 calls that value a hint, explicitly not an authoritative measurement. The server chooses the actual response interval under its own network-specific policy; for a terrestrial-only DTN, the document says the upper limit should not exceed sixty seconds.

The response checks make the evidence precise. The response must arrive before the Challenge Bundle's lifetime expires. Its Source Node ID must equal the identifier being validated under the comparison rules in RFC 9174. A trusted Block Integrity Block must cover the primary block and payload and pass its configured security context. The challenge identifier, per-bundle token, selected hash algorithm and expected Key Authorization digest must match. A missing or late response fails that perspective.

RFC 9171 prevents a common overstatement. A DTN Node ID is a singleton Endpoint ID used to identify a BP node, but it is not guaranteed to be globally unique, and one node can have several Node IDs. The ACME test can validate control of the identifier presented to it. It does not manufacture a universal uniqueness regime around that identifier.

More perspectives do not remove policy

RFC 9891 permits the server to send Challenge Bundles from different sources or along different routes. This multi-perspective technique can make one on-path attacker less decisive. But the server still decides which perspectives are primary, which are secondary and how many failures it will tolerate. The recommended policy accepts a successful primary perspective with no more than one secondary failure. That recommendation is not evidence that two paths are topologically independent.

The document is candid: the usefulness of multi-perspective validation in a DTN is experimental. Path diversity can be apparent rather than real. Distinct source Node IDs may converge on the same vulnerable link, gateway or routing decision. A serious audit therefore preserves the source, route evidence if available, outcome and policy for every perspective. A final Boolean is the conclusion of that policy, not a substitute for its inputs.

The same limit applies to the Bundle Integrity Gateway. Under RFC 9891, a routing node may validate a Bundle's source using local means and add an integrity block. A remote verifier can then trust that Security Source instead of directly trusting the original node. RFC 9172 supplies the BPSec mechanics, but mechanics do not define institutional authority. The receiver still needs a policy saying which gateways may attest for which sources. The gateway's local validation may rely on physical, network or convergence-layer authentication that the remote CA cannot observe.

This is not a defect hidden in fine print. Naming allocation, gateway delegation and cross-organizational trust are explicitly unsettled parts of the experiment. A valid integrity block shows that a configured security source authenticated protected bytes. It cannot show that the organisation behind that source had the right to speak for every Node ID it covered.

Issuance is not installation

The final boundary comes after success. The validated Node ID can enter a certificate request using the NODE-ID profile and Bundle-security key purpose described by RFC 9174. RFC 8555 defines the surrounding ACME order lifecycle. Yet RFC 9891 leaves certificate and private-key provisioning, deployment, revocation-list access, security-parameter configuration and communication between ACME software and BP Agents outside scope.

An issuance log therefore proves issuance. It does not prove that the intended BP Agent received the certificate, that it holds the corresponding private key, that peers trust the chain, that an old credential was removed or that traffic now uses the new credential. Those are later joins with different custodians and failure modes.

Heng Lu's Running-Code Primacy supplies the right editorial discipline: the specification states what implementations should do; observed execution establishes what they did. Minimum Initial Specification argues for a thin common core with later decisions left where their consequences can be observed. RFC 9891 follows that shape more closely than an overbroad reading would suggest. It standardizes tokens, messages and checks while leaving routing, local gateway authentication and operational deployment to their actual operators.

Reality Layers explains why the remaining joins should stay visible. A dashboard wants one badge called “validated.” Operations needs several propositions: challenge accepted, gateway policy matched, certificate issued, credential installed, peer trust confirmed and protected traffic observed. Collapsing them creates symbolic authority. Keeping them separate creates an evidence chain.

Sources