摘要

  • RFC 9646 在两次 get-bootstrapping-data 调用之间放入一条 HTTP 400；能力声明、服务器选择与设备返回的 CSR 是三份不同证据。
  • CSR 签名能证明请求者持有相应私钥，却不能单独证明设备来源、CA 批准、证书交付、安装或获权使用。
  • csr-request 位于无法按 RFC 8572 引导数据方式签名的 HTTP 错误中，因此该机制不能跨越“不受信任引导服务器”边界。

红灯对应的不是最终失败

RFC 9646 扩展安全零接触配置，使设备可在上线期间申请面向生产环境的身份凭证。它的关键不是“自动发证”，而是一段有意分成两次请求的协商。

第一次调用中，SZTP 客户端发送 csr-support。它列出能否生成新非对称密钥、支持哪些密钥算法、能产生哪些 CSR 格式。若服务器需要证书请求，就以 HTTP 400 返回，并在 RESTCONF 的 error-info 中携带 csr-request。该结构选择算法、格式，还可给出证书请求信息。

客户端随后执行第二次 get-bootstrapping-data，提交 p10-csr、cmc-csr 或 cmp-csr。服务器可联合注册机构与证书机构验证请求；只有通过相应政策，才会在上线信息中返回签名证书。

因此，400 同时有两个准确含义：在 HTTP 分类中是客户端错误状态，在这段协议状态机中却是预期指令。它既不等于业务失败，也不等于身份批准。监控系统若只保留颜色，就会把控制消息误当结论。

能力清单不能替代执行记录

csr-support 只描述可能性。它不能证明设备真的创建了新密钥，也不能证明随机数质量、私钥存放位置或 HSM 保护。服务器的选择缩小了可能性，但仍只是命令。设备还需生成或选取密钥、构造指定对象并发起第二次请求。

这与 Lu Heng 的最小初始规范原则一致：共同规范负责必要的互操作交接，本地制度负责可见的后续判断。RFC 9646 没有统一 CA 审批政策，没有规定证书在上线信息中的唯一承载方式，也没有替应用决定新身份可做什么。

若平台只记录“支持 CSR”和“CSR 已收”，审计无法回答服务器是否选择了设备未声明的算法、所谓新密钥是否重复、第二次请求是否属于同一轮交互，以及最终证书是否绑定到那把密钥。

持有私钥与请求来源是两道题

持钥证明的做法很明确：CSR 包含公钥，并由相应私钥签名。服务器用 CSR 中的公钥验证签名。验证成功说明对象创建者当时控制该私钥。这是一条强而窄的结论。

来源证明问的是另一件事：是哪台设备、哪个受权主体产生了请求。原始 PKCS #10 结构自身不带来源认证。来源可由客户端的 TLS 或 HTTP 身份补充，但这意味着会话上下文必须与 CSR 一同保存。只留下可验签的文件，不能让文件自动继承已经丢失的会话身份。

CMC 与 CMP 可使用 PKI 或共享秘密提供来源认证，也可在 CA 前加入注册机构处理。它们提供更丰富的证据路径，却不会自动产生发证权。验证者仍需检查 IDevID 路径、共享秘密引用或协议保护，再依据本地政策决定。

若复用制造商身份密钥，来源验证包括验证 IDevID 证书路径，并确认 CSR 使用同一密钥对。若使用新生成的本地密钥，CMC 或 CMP 可借制造商私钥或共享秘密把新请求与原身份关联。这两条路的责任结构不同，不应压缩成一个“CSR 有效”字段。

新密钥的抗重放价值必须落到事实

RFC 9646 建议每个 CSR 生成新私钥。如果设备在服务器指令之后确实生成新密钥，随机材料同时具有类似 nonce 的作用。当返回的签名证书包含这把新公钥时，设备可获得响应属于本轮交互的证据。

“支持密钥生成”不等于已生成。若公钥指纹重复，所谓新鲜性就不存在。另一方面，新并不必然更安全：若设备无法像保护内置制造商密钥那样保护新密钥，RFC 建议复用保护更强的旧密钥，而不是为了形式上的新鲜性制造一个更脆弱的秘密。

所以，证据应记录选用哪条密钥路径、为什么、私钥位于何处、是否可导出、随机源与生成时间，以及该选择带来了何种重放属性。动态私钥必须防止泄露；RFC 建议 HSM 或 TPM。无法提供同等保护时，定期轮换可缩短暴露期。

部署身份与新私钥属于用户数据。设备恢复出厂状态时应清除它们。发证日志若没有复位、轮换与清除结尾，就不是完整生命周期记录。

未签名的中间消息划出硬边界

RFC 8572 允许设备连接尚不信任的引导服务器，并依赖签名的引导数据。RFC 9646 的 csr-request 无法获得同样保护，因为它装在 HTTP 错误消息中，而该错误不能按 RFC 8572 的方式签名。

结论十分明确：客户端连接不受信任服务器时不能使用这套 CSR 机制。客户端不应发送 csr-support，而应选择 signed-data-preferred。这不是日志完善程度问题，而是谁有权塑造生产身份请求的问题。

若系统忽视边界，不受认证的一方便可选择算法、格式甚至证书请求内容。设备随后产生的 CSR 即使数学上完全正确，也只证明它执行了指令；它不能证明指令来自有权者。后续加密正确性无法倒灌成前一步的权威。

签发、传送、安装与使用各自有结果

服务器收到 CSR 后，可能与 RA 或 CA 一起验证持钥、来源、资产归属与所求属性，再批准或拒绝。CSR 签名不替代这些组织判断。

RFC 9646 明确不规定签名证书如何装入上线信息。文中给出配置与 RFC 9642 keystore 等示例，但传送方式仍在规范范围之外。因而，“证书已签发”和“设备已收到证书”是两项证据。

安装又是下一项。证书必须关联到正确私钥，提交到正确存储，并由预期服务选择。首次成功的对端验证提供运行证据；应用是否授权具体操作仍在认证之后。任何单一状态都不能代替全链。

Lu Heng 的运行代码优先要求把权重放在实际执行与可见效果上。YANG 模块提供共同语法；真实设备、CA、数据存储与服务各自产生自己的事实。

建立可重放的上线收据

记录从信任关系开始：引导服务器身份、信任锚路径、TLS 与 HTTP 认证事实，以及客户端为何发送 csr-support 或 signed-data-preferred。保存第一次请求中的 nonce、硬件与软件标识、算法和格式清单。

把 HTTP 400 作为协议转移保存，包含完整 csr-request、所选算法、格式、请求内容、时间与关联标识。密钥环节记录生成或复用、公钥指纹、随机性或 HSM 证据、私钥保护边界与新鲜性判断。

第二次请求记录 CSR 格式与摘要。持钥证明与来源证明分别给出结论，并注明 IDevID 路径、共享秘密、TLS 身份或 HTTP 身份。之后接上 RA/CA 决策、批准人、签发证书指纹、传送方式、安装结果、首次使用、轮换与清除。

现实层次在这里不是抽象修辞。状态码、协议指令、加密持有、请求来源、机构批准、安装状态与应用结果属于相邻但不可互换的事实层。完整收据的价值，就是不让上一层借用下一层的权威。

Sources