摘要

  • RFC 9641 定义证书袋、公钥袋、中央信任库引用和内联定义；system 来源能区分厂商内置状态与运维意图，却不是制造和更新的完整来源证明。
  • 一个可解析的袋名只证明配置对象存在；某个对端是否在特定时间、名称、用途、算法与撤销策略下被接纳，必须由运行时验证轨迹说明。
  • 可辩护的回执应把数据存储来源、变更权限和静态完整性，与精确锚点、证书路径、服务身份、验证结论以及认证后的授权决定逐层连接。

审计人员在设备的 operational 视图中找到一枚内置证书。它带有 system 来源，于是报告写道：“该锚点由制造商可信地植入，并被本次 TLS 会话使用。”

前半句把来源标签扩写成了供应链证明，后半句又把可见状态扩写成了运行事实。system 能说明这不是一次普通 intended 配置写入，却不能重建工厂签署、固件构建、升级授权与本地存储保护。锚点出现在信任库中，也不能证明握手验证器解析了它，更不能证明服务名称、用途和授权都通过。

RFC 9641 的价值正在于它为这些边界提供了清晰的配置语言。ietf-truststore 把证书和原始公钥放入具名袋中，让其他 YANG 模型可以引用中央对象，或在自己的配置中内联定义。标准建立共同的最小接口，而没有把所有实施环境收归一个中央判断者。

来源标签保留差异，但不补写历史

设备可能预装制造商服务、零接触引导或公共证书机构所需的锚点。RFC 9641 预计这些对象出现在 operational 数据存储中；实现 system 数据存储时，也可在那里呈现，并以系统来源区别于运维者写入的 intended 配置。

这个区别很重要。若把内置对象与本地变更摊平为一张“已配置的信任”列表，审计会错误地把决定归给运维团队。然而，RFC 9641 明确没有规定操作者如何设置或修改内置锚。system 只是状态分类，不是制造保管链。

完整来源至少还要记录：哪一版制造镜像包含该对象，构建与发布由谁批准，更新包如何验证，设备何时安装，回滚会恢复什么，静态存储如何防篡改。对 RFC 8572 所描述的安全零接触配置而言，初始锚点甚至可能决定哪个控制器获得后续配置权。此时，来源空白就是权力转移空白。

袋的用途是治理输入，不是执行结果

RFC 9641 于 2024 年 10 月作为标准路线 RFC 发布，出自 IETF NETCONF 工作组。证书袋和公钥袋应围绕共同用途组织；证书袋的用途应当被描述，公钥袋的用途必须被描述。

描述能告诉维护者“我们打算怎样使用这些对象”，但通用模块并不单独强制名称、证书路径或具体密码操作。除非消费模型或辅助策略施加限制，配置的信任锚会被隐式信任，可用于验证包含任意名称、服务于任意用途的路径。这个宽边界让模型能被多种协议复用，也意味着袋名不能替代协议策略。

名为“生产服务器”的袋不会自己比较主机名。它也不会检查扩展密钥用途、名称约束、算法退役或撤销状态。由 RFC 9645 等消费模型提供选择位置后，具体实现仍需执行并记录本地规则。原始公钥与 X.509 证书还具有不同的验证流程，不能被一个“信任”标签抹平。

中央引用解决复用，也扩大修改半径

当相应 feature 可用时，RFC 9641 的 inline-or-truststore grouping 要求消费者在内联对象与中央引用之间作出选择。某一刻，两者可以包含完全相同的 DER 字节并产生同一结果；随后，它们的控制关系会分叉。

中央袋允许一次替换影响全部引用者。这可以迅速撤出失陷或到期锚点，也可能让一次误操作同时扩大多个服务的接纳面。内联配置把改变限制在单个消费者，却容易漂移：离线实例没收到更新，独立团队保留旧锚，临时兼容项变成永久对象。

因此，回执不能只写“引用中央信任库”。它应冻结袋与对象标识、精确字节或指纹、内容哈希、数据存储来源、消费配置路径、解析时间和受影响消费者清单。袋名是可变符号；事件回执必须指向当时真正解析到的版本。

运行代码优先于意图配置。正确的 intended 状态可能尚未投射到 operational，进程可能仍使用缓存，某一实例可能没有重载。只有解析轨迹与验证结果能证明变更真的进入决策。

default-deny-write 不是全部写入面的证明

RFC 9641 为信任库节点和引用添加 nacm:default-deny-write。RFC 8341 因而让普通写入从拒绝开始，除非更具体规则授权。即使证书和公钥是公开材料，替换它们也可能把认证导向另一主体，所以写保护不可省略。

但默认拒绝不是历史日志。变更回执还需会话身份、安全通道、当时生效的 NACM 规则集、命中规则、请求路径与操作、前后对象、业务批准、提交结果和 operational 投射。RFC 8342 区分 intended、system、operational 等现实层，并不自动证明它们之间的因果关系。

RFC 9641 还指出，YANG 无法规定数据静态存储保护。NETCONF、RESTCONF 与 NACM 管理 API 路径；root 进程、软件包更新、数据库恢复、磁盘损坏或备份回灌可能走另一条路径。实现必须阻止未授权静态修改，审计也必须单独取得完整性证据。

到期通知只打开工单

支持相应 feature 时，证书项可以在临近或已经到期时发出 certificate-expiration 通知。通知记录一个时间条件，不保证订阅者在线，不保证消息送达、有人确认、替代对象获批，也不保证每个消费者已经引用新对象。

真正的到期闭环应连接 feature 支持、订阅、事件、投递、确认、替代证书、引用变化、部署状态和下一次成功验证。还要保留失败分支：中央袋已经更新，内联消费者仍旧陈旧；证书尚未到期，却因名称、用途、算法或撤销而失败。

路径可达锚点，身份仍未完成

X.509 场景下，RFC 5280 定义证书路径验证。验证器仍要构造或选择候选路径，处理约束并执行本地策略。RFC 6125 把服务身份匹配与路径有效性分开。TLS 1.3 则提供证书与签名出现的握手上下文。

一次接纳事件需要保存对端证书或原始公钥、会话标识、解析后的袋与锚点、候选路径和实际路径、验证时间与时钟源、有效期、参考身份、匹配规则、密钥用途、扩展用途、名称约束、证书策略、算法判断、策略所需撤销证据、验证器版本与带理由结论。

认证之后还有授权。对端可能被正确识别，却只获准读取遥测，不能修改路由；制造商引导身份也未必拥有日常运维权限。把后续授权独立记录，才能防止“可信”一词无限扩权。

组装接纳回执

从模块修订、feature 与精确路径开始，注明内联、中央或内置模式，保留 intended、system 与 operational 来源。对每次变更记录主体、审批、NACM 决策、提交与静态完整性。对每次使用，把消费服务与配置版本解析到精确对象。

随后加入对端、会话、路径、时间、名称、用途、算法、状态检查、验证结果和授权结果。中央袋变化时逐一枚举消费者并比较前后行为；到期通知只有在确认、替换与成功使用后才关闭。

这样做不是给 RFC 9641 增添一个虚构职责，而是尊重它的最小规范边界：共享模型负责让对象可交换、可引用，自治消费者负责作出本地决定。回执负责证明两层如何相连，不让符号权力冒充运行现实。

来源