摘要

  • RFC 9891 的可选 rtt 字段是客户端对 DTN 往返时延的估计，并不具有强制力。ACME 服务器仍要设定实际响应区间、应用网络特定上下限，并按原始 Challenge Bundle 的生命周期判断响应是否及时。
  • 一次及时且完整性校验成功的响应，只证明某账户在该挑战和该策略下控制了相应 Node ID。它不证明永久所有权、未来路由稳定、证书已经签发或安装，也不证明 TCPCL 会话和应用结果。

自动化系统读到 rtt: 300，随即在工单里写下：“该节点获准在五分钟内完成验证。”前一个数字是客户端对路径的估计，后一句却把估计改写成了服务器的承诺。

RFC 9891 把 ACME 的标识控制验证带进延迟容忍网络。服务器针对 bundleEID 创建授权，提供 bp-nodeid-00 挑战，再让自己的 BP Agent 向被声明的 Node ID 发送 Challenge Bundle。对端 BP Agent 收到后生成与该挑战绑定的 Response Bundle，并沿可能不同的路径返回。

这种协议必须接纳“等待”本身是网络正常状态，而不是故障。可它没有因此取消权力边界。知道路径大概需要多久的一方，可以提供信息；承担验证风险的一方，仍然决定窗口。

估计并不接管时钟

客户端提交的 Response Object 可以包含 rtt，单位为秒。RFC 9891 明确称它为 hint，而非 authoritative value。若存在该值，服务器通常应以两倍 RTT 作为基础，再施加网络特定的下限和上限。对于纯地面 DTN，上限不应超过六十秒；其他网络可以采用不同限制。

这里没有矛盾。协议允许示例中的较大估计，因为不同 DTN 的传播条件差异巨大；同时把最后决定留给服务器。客户端更了解自己的链路计划，服务器则更了解验证容量、状态保留成本、拒绝服务风险和 CA 的风险政策。

客户端在 BP Agent 尚未配置好之前不得启动验证。由于实际 Bundle 经过哪条路并无保证，估计还应偏保守。客户端因此拥有准备本地执行和诚实描述预期的责任，却没有单方面延长窗口的权限。

真正约束回程的是 Challenge Bundle 的创建时间和生命周期。Response Bundle 也带有自己的创建时间和剩余寿命，但服务器必须按原挑战的窗口检查到达。回程报文不能用一个更宽松的寿命字段覆盖最初的截止点。

这项设计把可用性与风险摆到同一张表上。窗口太短，会把合法的间歇节点挡在自动化之外；窗口过长，会占用更多状态与联络资源，也扩大过滤重放和滥用流量的成本。不存在由客户端一个数字就能消除的冲突。

证明来自两条信息通道

返回一个 Bundle 还不足以验证 Node ID。RFC 9891 把挑战材料拆开，使只观察 ACME 通道或只观察 BP 通道的参与者都不能独自构造完整证明。

token-chal 对每个 ACME 授权唯一，只在 ACME 通道出现。同一次授权可以发出多个 Challenge Bundle，每个 Bundle 又有独立的 token-bundle，这个值在 DTN 路径上可见。响应方把两部分 token 与 ACME 账户公钥指纹组合，计算 Key Authorization，再返回相应摘要。

服务器要逐项确认：

  1. 响应在原挑战窗口内到达；
  2. 响应的 Source Node ID 等于待验证的 Node ID；
  3. 可信 Security Source 的 Block Integrity Block 覆盖主块和载荷；
  4. id-chal 与 token-bundle 对应本次 Bundle；
  5. 所选哈希算法在服务器给出的集合内；
  6. 摘要与账户指纹和两部分 token 计算出的预期值相同。

任一条件失败，该视角就失败。窗口内没有响应也失败。不过相同的“失败”状态可能来自不同现实：路径中断、时钟质量、完整性信任、算法交集、本地 Agent 配置或 token 对应关系。只有保留 subproblem，后续行动才不会把所有问题误判为“节点不受控制”。

成功同样必须保持范围。它说明拥有 ACME 账户上下文的一方，能在有限时间内让相应 Node ID 返回特定证明。它不说明这个标识在所有命名空间都唯一，更不说明控制权永久存在。

RFC 9171 把 Node ID 定义为可用于识别 BP Node 的 singleton Endpoint ID，同时明确 Node ID 不保证全局唯一，一个节点也可拥有多个 Node ID。常见 Administrative EID 在特定 URI scheme 内对节点唯一，并不等于法律主体或组织身份。

IANA ACME 注册表与 IANA Bundle Protocol 注册表登记 bundleEID、bp-nodeid-00、管理记录类型以及 dtn、ipn scheme。注册让实现者共享同一词义；它不观察节点，不测量路径，也不替本地网络分配信任。

多视角不是自动生成的独立性

服务器可以从多个来源或经多条路径发起挑战。每个 Bundle 的 token 不同，因此结果可以逐视角保存。这样做能够降低某些单路径攻击的成功机会，却不能证明底层路线真正相互独立。多个逻辑入口仍可能经过同一网关或物理链路。

RFC 9891 没有规定唯一的汇总算法。它建议的一种策略是：主视角成功，次要视角失败不超过一个。谁是主、谁是次，仍是实现问题。这意味着最终 valid 不只是网络观测，也是服务器对观测集合应用政策后的判断。

如果审计只存最终状态，就无法区分“三条路径全部成功”和“主路径成功、一个次路径失败但政策允许”。两家 CA 即便看到相同数据，也可能因风险政策不同而得出不同结果。

完整性网关提供另一层委托。它可以用本地方法验证 Bundle 来源，再添加 BIB。接收者必须配置哪些 Security Source 可以为哪些 Node ID 范围作证。密码学校验保护网关说过的话；政策决定网关有权为谁说话。

这正接近 Heng Lu 在最小初始规范与未来本地决策中强调的结构：中心只固定互操作所需的最小共同部分，后续决定留给能观察本地后果的参与者。标准统一了证明的语法，却不应吞并对方的超时、信任和风险政策。

验证成功之后仍有多道门

RFC 8555 把 challenge、authorization 与 certificate order 分开。挑战从 pending 进入 processing，再变成 valid 或 invalid。有效授权允许订单继续，但不等于证书已经签发。

RFC 9891 允许同一 CSR 同时包含 NODE-ID、DNS-ID 和 IP-ID。每一项都必须验证。即使 DTN 响应完全正确，另一标识失败仍会影响订单；CA 还要应用签发政策、密钥用途与算法约束。

证书签发后，RFC 9174 才说明它如何进入 TCP convergence layer 的身份检查。证书可含 NODE-ID 和 id-kp-bundleSecurity 扩展用途。真实会话中，双方政策可能要求网络层标识、Node ID 或二者都通过；失败可以终止会话。

RFC 9891 把证书如何安装进 BP Agent 留给实现。于是“授权有效—订单签发—证书安装—TLS 选用—TCPCL 会话建立—Bundle 转发—应用收到结果”必须是七条可关联但不能互换的记录。

RFC 9172 提供 BPSec 框架。BIB 验证成功，证明特定上下文与密钥下被覆盖的数据完整；它不会自动创造对 Security Source 的制度信任。

Heng Lu 的运行代码是首要证据要求把规范允许什么与系统实际做了什么分开。现实层级与符号权力则解释了一个 valid 标记为何会在脱离时间、视角和对象后，被误读成永久所有权或服务健康。

客户端估算了时延。这让服务器可以更好地安排验证，却没有夺走服务器的时钟。节点及时回答了挑战。这是有意义的控制证明，却不是通往未来所有结果的通行证。

来源