摘要

  • RFC 9891 把 ACME 账户侧的挑战与一个或多个限时 Bundle 响应结合起来；成功表示服务器策略在当时接受了对 bundleEID 的控制证据。
  • 它不证明 Node ID 由谁分配、哪条路由合法、完整性网关是否获得授权，也不证明签发后的证书与私钥已经投入运行。

在容迟网络里，几分钟后返回不一定是异常，而可能正是网络的工作方式。问题在于，当响应终于到达、完整性校验通过、控制台亮起“验证成功”时，人们很容易把这个结果解释得比协议更大。

RFC 9891 新增 bundleEID 标识符和 bp-nodeid-00 挑战。token-chal 只经由 ACME 的 HTTPS 通道送达；每个挑战 Bundle 则携带独立的 token-bundle。BP Agent 将两者与 ACME 账户密钥指纹结合，计算服务器预期的摘要。仅观察其中一个通道的人无法完整作答。

客户端必须先配置 BP Agent，再授权服务器发送挑战。客户端可以提供往返时延，但规范明确说它只是提示，不具权威性。接受窗口由服务器策略决定。响应还必须满足来源 Node ID、BIB、挑战标识、令牌、算法和摘要的一系列检查。RFC 9172 规定 BPSec 保护机制，RFC 9174 提供 NODE-ID 比较和证书配置文件。

这套证据的边界可以从 RFC 9171 看清：Node ID 是标识 BP 节点的单播 EID，但不保证全球唯一，而且一个节点可以有多个 Node ID。验证某个标识符的控制，不等于创造其全球所有权。

服务器还可以从不同来源或路径发送挑战 Bundle，实施多视角验证。然而由谁算主要视角、允许几个次要失败，仍是服务器政策。两个看似不同的来源也可能共用同一链路或网关。RFC 9891 因而把这种方法在 DTN 中的有效性列为实验问题，而不是既成事实。

完整性网关构成另一道边界。它可以在本地验证来源，再给 Bundle 增加 BIB。远端接收者信任的是 Security Source，却仍需一张政策映射表，说明该网关可以为哪些 Node ID 作证。密码学能证明受保护字节来自受信密钥，不能证明运营网关的机构依法或依约取得了所有相关命名权。

即使验证通过，RFC 8555 后续的签发流程也不等于部署。RFC 9891 明确不处理证书与私钥的配置、撤销列表、ACME 客户端与 BP Agent 的内部通信、路由选择等事项。因此，挑战成功、证书签发、凭据激活、受保护流量出现，必须是四项独立记录。

IANA ACME 注册表与 Bundle Protocol 注册表协调代码点，不观察生产状态。Heng Lu 的运行代码优先要求用执行证据校验规范承诺；最小初始规范把未来决策留给能承担后果的本地运营者；现实层与象征权力则提醒我们，不要让一个绿色标记吞并它从未证明的权威。

来源