摘要

  • draft-ietf-anima-rfc8366bis-36 把 last-renewal-date 定义为 MASA 预计最后愿意续期的日期；它仅供参考，Pledge 不处理，也不会延长 expires-on。
  • 真正续期发生在以后：Registrar 重新签一份带旧 Voucher 的 RVR，MASA 再判断域私钥控制、域身份证书状态和当时政策，随后才可能签发替代 Voucher。

某台设备的原始 Voucher 里有两个日期。资产系统很容易把较晚的那个涂成绿色，并写成“续期保障至”。签名是真的，字段也是真的，但界面补上的“保障”并不在协议里。

last-renewal-date 说的是 MASA 在旧 Voucher 签发时所作的预计。定义特意用了两个限制：字段“仅供参考”，而且 Pledge 不处理。它只有在 expires-on 存在时才能出现，却不是另一种到期时间，更不会把当前 Voucher 的有效期推到未来。

签名能固定一次声明，不能提前完成未来交易。

修订 36 仍是候选文本

Datatracker 将 2026 年 9 月 9 日发布的修订 36 列为 ANIMA 工作组的活跃 Internet-Draft，目标状态为 Proposed Standard，目前处于 IESG Evaluation::Revised I-D Needed。记录中仍有两个 DISCUSS，还需要两个 YES 或 NO OBJECTION，IANA 状态也因版本变化而需要重新审阅。

草案标题页写的是：若获批准，将废止 RFC 8366、更新 RFC 8995。条件不能省略。它还不是替代 RFC，更不是某个厂商的上线报告。

续期概念本身也不是修订 36 才出现。RFC 8366 已经建议用短期、不可直接撤销的 Voucher 配合轻量续签，修订 35 也保留了同一思路。修订 36 的新增价值，是把“轻量”背后的后续门槛写得更具体。

旧日期无法替 MASA 做今天的决定

Registrar 需要新建 Registrar Voucher Request，重新签名，并把旧 Voucher 放进 prior-signed-voucher-request。MASA 会验证这份新 RVR，确认提出请求的 Registrar 仍能使用域私钥，还会检查域身份证书的吊销状态，再应用从上次签发以来已经变化的政策。

草案举了两个政策例子：域所有者要求停止继续续期，或者支持合同到期。它们说明政策会动，不代表每个部署都必然由支持合同控制。

初次签发可能需要更重的所有权调查。续期不必全部重做，而是验证先前关系是否仍成立。因此它可以更低成本，也常可自动化。可是“可以自动化”只描述执行方式，不是“必定批准”。自动决策同样会拒绝、超时或因依赖故障而无法产生结果。

请求、签发、接收必须分列

一份签名正确的 RVR 能证明特定 Registrar 在特定密钥与证书语境下提出了请求。把旧 Voucher 放进去，能说明希望延续哪一段既有关系。验证域私钥，能说明请求方仍掌握相关控制材料。

这些证据都不是新 Voucher。

MASA 可能因证书或政策拒绝。网络可能让响应丢失。替代 Voucher 可能已经签发并到达 Registrar，却从未抵达目标 Pledge。Pledge 还可能因签名链、序列号、发行者、时间或域锚不符而拒绝。即使接受，后续登记、配置或业务动作仍可能失败。

因此，运行账本至少要分成七类：

  1. 承诺收据：旧 Voucher 原文、签名链、设备绑定、expires-on、预计续期日和域锚。
  2. 可用性收据：MASA 路径、所需格式与签名机制在留有修复窗口时经过测试。
  3. 请求收据：新 RVR、签名、旧 Voucher、请求时间和域私钥证明。
  4. 资格收据：证书状态、阻断状态与实际执行的政策版本。
  5. 签发收据：替代 Voucher 的精确字节、签名者、时间和新有效期。
  6. 接受收据：Pledge 验证新对象并确认 Registrar 与固定域锚一致。
  7. 结果收据：登记、配置和预期服务动作确实完成。

只保留一个“可续期”布尔值，会把故障位置和责任主体一起抹掉。

不单设 Voucher 撤销路径，就更依赖按时演练

设计要解决的复杂性是真实的。长期断言再配 OCSP 或 CRL，会增加协议和代码路径；Pledge 也可能访问不到状态响应者。草案因此建议短期 Voucher，以同类对象的重新签发代替专门的 Voucher 撤销机制。

“短期”由各 onboarding 机制决定。格式并未禁止长期 Voucher，但没有定义它们自己的撤销方法。签名链中的中间 CA 证书仍可被撤销，这属于 PKIX 链的影响，不是隐藏的 Voucher 撤销服务。

这项简化把风险从“持续查撤销”转到“到期前能否重新签发”。如果提前数月演练失败，还能修路由、证书链、域密钥或所有权记录。第一次测试若等到到期后，旧字段只能解释当初为何乐观，无法恢复有效性。

无 nonce 的新鲜度仍由时钟承担

对不含 nonce 的 Voucher，Pledge 只能用内部时钟比较 expires-on。草案警告，没有可靠时钟的设备不能简单信任 NTP，因为攻击者可能控制时间流。这样的设备应使用 nonce 获取新鲜的临时 Voucher。

无 nonce Voucher 在有效期内可以重复使用。它能方便同一域内的重复 onboarding，也允许拿到对象的人多次尝试。固定域锚会限制可接受的目标域，但不会把对象变成一次性。

预计续期日不提供时间源，不增加 nonce，也不改变复用语义。把它当作新鲜度证明，会把三个不同控制压成一列。

域锚回答“谁”，不回答“结果怎样”

Voucher 的核心职责，是安全传递一个信任锚。Pledge 要用它认证后续域交互，并验证锚与当前通信的 Registrar 相符。这能阻止攻击者拿着一个域的 Voucher，把设备悄悄接入另一个攻击者控制的域。

这个边界很强，但仍有限。它不证明 Registrar 可用，不证明后续登记成功，不证明配置正确，也不证明设备产生了领导层期待的业务结果。RFC 8995 描述了更大的 BRSKI 流程；Voucher 只是其中一份对象。

所以，签名有效、设备绑定、新鲜度、域锚匹配、续期资格、新对象签发、Pledge 接受和运行结果，必须分别落账。

把承诺日期改成演练触发器

Heng Lu 的最小初始规范与运行代码优先原则提供了一种务实解释：共同文本可以定义对象和本地验证规则，未来变化只有在实现、验证与采用中才成为某个参与者的运行事实。

在这里，last-renewal-date 是协调信息。诚实的界面应写“签发方当时预计可续期至 X”，并另列“最近完整演练 Y”“替代 Voucher 到期 Z”“下次演练 Q”。若企业确实要承诺服务可用性，应通过有负责人、监控和补救措施的运行合同表达，而不是从 YANG 字段推导。

旧 Voucher 提供计划窗口。新 Voucher 的签发、接受与后续结果，才构成续期证据链。

来源