摘要

  • RFC 9642 规范了对称密钥、非对称密钥、证书、中央引用和内联定义的 YANG keystore，但不负责宣布业务恢复完成。
  • 加密配置能否迁移，取决于每个密文到 KEK、源端和目标端主密钥、重包裹操作及其授权的完整依赖链。
  • 可审计的恢复凭证必须继续走到消费者：解析出的对象、绑定的证书、被允许的操作、被拒绝的越权用途以及可观察的服务结果。

新设备启动后，运维界面显示“密钥导入成功”。所有名称、公开部分和证书都出现在 <operational> 中。随后第一个签名请求失败：加密私钥仍在，但负责解开它的共享 KEK 没有按新设备的主密钥重新包裹。

数据库没有少一行，权力却没有回来。这正是 RFC 9642 需要被谨慎阅读的地方。它建立 ietf-keystore，让不同系统能够用同一结构管理密钥与证书；它不把配置存在、私钥可用和服务恢复压成同一个结论。

一棵合法的树只能证明它合法

RFC 9642 在 2024 年 10 月成为 IETF 标准轨道 RFC。它分别声明中央 keystore、内联定义、非对称密钥和对称密钥等功能。消费模型可以让操作者在本地材料和中央引用之间选择，也可以为其他位置扩展新的 case。

因此，同样声称支持 RFC 9642 的两台设备，实际开放的迁移路径可能不同。恢复凭证首先记录模块修订、功能集合、YANG Library 上下文、datastore、精确路径和内容哈希。列表里的名字只是在一个实例内定位对象，不是全球身份、保管证明或运行选择。

leafref 成功解析，说明配置连接存在。它没有说明当前进程加载了哪个版本，也没有排除优先级更高的内联定义。状态证据与事件证据必须分开保存。

or:system 不是制造履历

依照 RFC 8342，操作者写入的 intended 状态与服务器提供的 operational/system 状态可以区分。内建密钥可能在制造时安装、首次启动时生成，或者在启用某个服务时创建。

系统来源能防止审计者把服务器提供的值误认为普通配置变更。但它不能回答生成者、熵源、硬件边界、可导出性、固件版本和身份证书有效性。RFC 9642 明确把供应商流程以及操作者如何修改内建密钥留在范围之外。

如果操作者随后给内建私钥附加部署证书，结果包含两条来源链。把它们扁平化成“一个带证书的配置密钥”，会丢掉调查最需要的边界。凭证必须保留密钥来源、每张证书来源以及完成关联的动作。

encrypted-by 是资产依赖，不是备注

加密密钥对象同时保存格式、密文和负责加密的密钥引用。服务器必须能访问这个 KEK，或访问使用它的 API，才能在运行时解密其他密钥。否则，完整的密文只是可保管对象，不是可执行权力。

RFC 9642 的非规范性迁移方案把许多密钥放在一个共享 KEK 之下，再用每台服务器独有的内建主密钥保护 KEK。迁往新设备时，只需把共享 KEK 改为由目标主密钥包裹；其余大量密文可以不变。

这个设计提高效率，也集中风险。KEK 丢失会同时阻断许多消费者；KEK 被替换会同时改变它们；KEK 接口授权过宽会一起扩大攻击面。备份完整性不能只用文件哈希衡量，而要验证图闭合：密文、每条 encrypted-by 边、源与目标主密钥、格式、算法、授权者、重包裹结果和回滚对象缺一不可。

方案本身不证明某产品照此实现。报告应描述确切源设备与目标设备、备份哈希、共享 KEK、两端主密钥、批准流程、结果与测试，而不能写“按 RFC 恢复成功”。

“隐藏”与“加密”都有边界

RFC 9640 提供 cleartext、hidden 和 encrypted 等可复用类型。hidden 表示管理模型不通过该表面返回秘密，不代表内存、控制台、本地工具、备份或硬件路径都不可提取。encrypted 表示对象有密文和包裹关系，不代表 KEK 安全或灾后可用。

RFC 9642 建议持久化时加密 keystore，并在不再使用时清零易失内存中的明文。如果持久化不加密，存储必须不可访问。这些是实现责任；YANG 树看不到副本、swap、崩溃转储、日志和特权账号。

恢复档案因此要加入存储覆盖、内存处理、备份保管、访问记录与负面测试。缺少硬件证据时，只能缩小结论，不能借“keystore”这个名称扩大保证。

NACM 是门，不是历史

模块的可写节点带有 nacm:default-deny-write，可读明文秘密继承更严格的默认拒绝。RFC 8341 提供决策机制，但注解本身不记录哪次会话、哪条规则和哪个例外实际生效。

变更凭证需要连接 NETCONF 或 RESTCONF 身份、传输绑定、NACM 版本、命中规则、路径、前后值、commit、审批与 operational 投影；还要列出绕开 YANG 的本地、厂商和硬件路径。RFC 6241 与 RFC 8040 提供管理协议，不替代密钥事件记录。

RFC 9642 自身没有定义 RPC 或 action。密钥生成可能由 SSH/TLS 消费模型提供，也可能由密码管理员在服务器外完成。最后看到一个节点，无法反推生成仪式与授权链。

证书配对以后，还要证明消费者选择

一个非对称密钥可以关联多张证书。终端实体证书引用同时点名密钥和证书。已验证 Errata 8441 修正了复制错误：解释文字曾误说对称密钥，规范结构实际一直是非对称密钥—证书对。

RFC 9644 与 RFC 9645 的 SSH/TLS 模型可以消费这些材料。审计必须解析具体服务引用，固定消费者配置版本，观察签名、解密或握手操作，并把结果绑定到选择的对象。

模块也没有给私钥本身限定签名或解密用途。证书可以约束相关公开密钥，但组织授权与实际私钥操作仍是不同层。恢复测试既要证明应有操作成功，也要证明越权操作失败。

到期通知只是工作起点

证书到期事件报告时间条件，不证明送达、确认、批准、替换、引用更新或轮换后的成功。旧备份甚至可能把已淘汰证书重新带回。

完整链条从事件标识与接收者继续到新证书、密钥匹配、服务选择、部署状态和观察到的运行结果，并保留中央已更新而内联仍旧的分叉。

恢复凭证如何收口

先固定精确备份、源设备、模块、功能、datastore 和来源。保存密钥与证书指纹、格式及全部加密边。再记录两端主密钥、共享 KEK、授权者和重包裹结论。

随后在目标端验证每个必要对象可解开、中央或内联引用选择正确版本、证书关联正确、消费者实际使用、禁止用途被拒绝。最后观察服务结果和独立回滚能力。

这不是削弱标准，而是让最小共同规范守住自己的权限。RFC 9642 协调结构；运行代码行使密码权力；凭证负责证明二者在哪里真正相接。

来源