摘要

  • BRSKI-AE 要求证书请求同时带有新私钥的持有证明，以及基于出厂 IDevID 的来源证明，使远端 RA 不必依赖已经消失的第一跳 TLS 会话。
  • 签名对象是授权的证据输入，不是授权本身。即使本地注册员把 RA 工作委托给后台，RFC 9733 仍要求它参与设备加入域的决定。
  • Voucher、注册员同意、RA 决定、CA 响应、设备确认、注册状态遥测与生产网络准入各有独立含义；只报一个“上线成功”会抹去真正的责任链。

一台新控制器被运到信号不稳定的工厂。现场能找到域注册员，却连不上总部 PKI。设备先把证书请求留在本地，几个小时后才由中间系统转走；等远端注册机构收到时，最初的 TLS 连接早已结束。远端还能否核验，这真是那台设备对那把新密钥提出的原始请求？

RFC 9733 的核心价值，就在于把答案从临时连接搬进请求本身。BRSKI-AE 使用经过认证的自包含对象：一部分证明请求者掌握待认证公钥所对应的私钥，另一部分用设备出厂时获得的 IDevID 证明请求来源。对象可以经过多个传输环节，也可以等待异步处理，原始证明仍可由后台复核。

但“能独立核验”不等于“能独立决定”。签过名的请求不能替自己挑选归属域，不能批准自己要求的名称和用途，更不能命令 CA 必须签发。它把事实带到决策点，却没有把所有决策者都塞进一个对象里。

一把新密钥提出了两个问题

第一个问题是：请求者是否真的掌握这把私钥。PKCS #10 请求通常用新私钥自签，CRMF 还支持不具备签名能力的密钥类型所需的其他持有证明。验证通过，只说明请求者控制了与公钥对应的秘密材料。

第二个问题是：控制这把密钥的人是谁。任何人都能生成一对新密钥并证明自己掌握它。新密钥没有因为自签就自动拥有设备身份。RFC 9733 所说的身份或来源证明，需要把请求绑定到已经认证的凭据；在 BRSKI-AE 中，通常是用 IDevID 私钥签署，并覆盖序列号等足够强的设备标识。

这两项检查可能出现不同结果。攻击者完全掌握自己生成的密钥，却没有合法 IDevID。真正的设备能证明来源，却要求了域政策不允许的角色、名称或用途。两项密码检查都正确，设备的所有权记录、吊销状态或风险政策仍可能导致拒绝。

因此，审计记录至少要区分“持有证明通过”“来源证明通过”和“授权决定通过”。把它们压成“签名有效”，既解释不了拒绝，也不足以支撑签发。

为什么不能只信第一跳会话

传统 BRSKI 常配合 EST。EST 可以把 PKCS #10 请求和设备到注册员的 TLS 客户端认证绑定起来。对眼前的注册员来说，这是有用证据；但如果真正的授权发生在远端第二个 RA，后台未必能看到原会话，也未必能重新核验那次临时绑定。

BRSKI-AE 改用消息本身可认证的注册协议。规范化的实现采用轻量 CMP 配置。PKIMessage 的保护可以承载基于 IDevID 的来源证明，内部的 CRMF 或 PKCS #10 则证明 LDevID 新密钥的持有。注册员转发原始对象时，不需要把“我刚才在 TLS 里见过它”改写成后台只能信任的口头说明。

这一点使职责可以分层。现场注册员继续当域的守门人，远端 RA 使用更完整的数据和政策做审查，CA 负责产生证书。传输系统只负责搬运和保护消息，不必冒充身份或授权来源。

所谓不依赖传输，也不是不要传输安全。RFC 9733 仍要求设备与注册员之间沿用既有 TLS 或 DTLS 通道；注册员到后台 PKI 的交换方式则不在该 RFC 范围内。CMP 消息保护提供完整性与真实性，却不天然加密内容。若后续通道没有保密保护，旁观者可能看出哪些设备正在入域，甚至选择性阻断某类设备。

Voucher 指定可信的域，不是发给设备的 LDevID

替代注册开始之前，设备仍按 BRSKI 经注册员与 MASA 完成 voucher 交换。Voucher 让设备获得目标域的信任锚，常见形式是 pinned-domain-cert。此后，设备据此判断谁有资格向它提供域内材料。

Voucher 很重要，但它不是 LDevID 证书。它没有证明后续请求已被 RA 批准，也没有证明 CA 已签发，更没有证明设备被生产网络接受。它回答的是“应当信任哪个域”，而不是“这个域已经授予了什么资格”。

完成 imprint 后，设备生成 LDevID 私钥并提交自包含请求。使用 CMP 时，设备必须依据 voucher 建立的信任锚验证服务端响应。于是两条证据链衔接起来：voucher 约束设备接受哪个域；注册流程决定该域是否给这把新密钥签发何种证书。

如果运营界面只显示“voucher 成功”，后续政策拒绝会被误报成系统异常；如果只保留“证书返回”，调查者又会失去设备为何信任这个域的依据。两份记录都应存在。

委托后台，不得绕过注册员

RFC 9733 的安全边界写得很直白：域注册员可以把部分甚至大部分 RA 职能交给独立后台，但它仍必须参与设备加入目标域的决定。设备不能绕过注册员，直接从 CA 获得 LDevID。

注册员同意可以有多种表达：在严格治理的架构中隐式成立，事先写入数据库，通过额外消息传送，或者直接用签名表达。CMP 场景下，RFC 建议注册员把设备原始请求嵌套到自己签署的消息中。后台于是看到两个没有互相冒充的声明：设备确实提出了这项请求；域注册员同意后台处理这项请求。

嵌套保留了设备的原话，避免中间人只给后台一份摘要；注册员签名又防止“设备身份真实”被误读成“本域准入已批准”。后台 RA 仍可拒绝，CA 也只能在所需认证和授权完成后签发。制造商身份从来不是运营域权限的自动通行证。

这套分离还能准确定位错误。IDevID 签名失败属于来源；注册员同意缺失属于域门禁；证书配置不合规属于 RA 政策；签发内容错误属于 CA。一个笼统的“PKI 失败”没有这样的修复价值。

异步队列不会冻结现实

BRSKI-AE 解决的正是后台暂时不可用的问题。自包含对象可以等到有传输容量时再送出，而不丢失来源证明。不过，等待期间只有对象没有改变，周围世界仍在变化。

设备可能转让，注册员同意可能撤销，证书配置可能升级，信任锚可能轮换。同一请求可能因为响应丢失而再次到达。旧签名仍然能够通过密码验证，却不代表旧决策今天仍然有效。

生产系统需要一条持久事务，把 voucher 身份、请求密钥指纹、持有与来源验证、请求属性、注册员同意、后台事务号、RA 结论、CA 响应和最终证书指纹连在一起。重试必须区分“已签发但响应丢失”和“从未获批”。队列年龄应进入政策判断，而不能只算传输指标。

这里最容易被忽略的边界是时间。真实性回答“谁签了这份对象”；时效性回答“这份对象现在是否仍应产生后果”。二者不是同一事实。

收到证书以后，仍有三个终点

成功的认证响应包含所请求的证书，也可能带中间 CA 证书或额外信任锚。CMP 还允许可选的 Certificate Confirm。设备收到并验证证书后，可以向 PKI 报告它是否成功注册、是否符合需要；PKI 或注册员再确认收到了这份确认。

BRSKI 同时保留设备与注册员之间的强制注册状态遥测。RFC 9733 特意把它列为独立的最终阶段。CMP 的证书确认告诉 PKI 设备如何评价证书；BRSKI 遥测告诉注册员注册流程的结果。确认被接收，也不等于证书已经在业务中使用。

第三个终点在协议之外：安装凭据、通过网络准入、取得配置并完成目标功能。CA 可以正确签发，而设备从未使用证书；设备可以报告注册成功，而接入控制仍拒绝；网络可以放行，而工业任务仍未运行。

诚实状态应当写成：voucher 已接受；密钥持有与请求来源已核验；注册员同意已记录；RA 已批准；CA 已签发；设备已确认；注册遥测已收到；运营准入尚未验证。句子变长，恰好说明自动化没有越权替后续层宣布成功。

发现一个入口，不等于发现一位合法决策者

RFC 9733 把端点形式推广为 /.well-known/<enrollment-protocol>/<request>，并登记 brski-reg-cmp，供设备用最简方式发现支持 CMP 的注册员。设备可以访问相应端点，再根据 HTTP 状态判断操作是否受支持。

这只是功能发现。服务名存在，不代表该端点就是这台设备所属域的合法注册员；IANA 登记也不证明任何具体部署已经符合规范。HTTP 成功可能只代表外层已接收，内部 CMP 事务仍在等待或拒绝。日志必须同时保留解析出的端点、TLS 对端、域信任锚、注册协议、内部事务与决策主体。

冻结来源没有证明任何具体铁路、变电站、楼宇或充电网络已经部署 RFC 9733。标准中的例子用于说明架构需求，不是市场采用报告。能被证实的是机制及其边界，而不是某个未观察到的生产结果。

来源