摘要

  • RFC 10002 允许已签名的原始申请保持不变，同时让注册机构通过外层 PKIData 包装加入身份见证、密钥占有见证或证书字段修改。
  • “签名有效”“持有私钥”“身份已核验”“RA 已处理”“CA 已签发”回答的是不同问题，不能合并成一个绿色的“已验证”。
  • 可追责的签发流程必须保存原请求、每层 CMS 包装、控制项顺序、RA 授权范围、CA 策略决定，以及申请与最终证书之间的逐字段差异。

设想设备团队申请一张证书。终端生成密钥，提交带有名称和扩展的请求，签名校验通过。数分钟后，CA 返回证书：公钥一致，某个扩展却被删除，另一个名称字段也发生了变化。

如果审计系统只保留两行记录——“请求签名有效”“签发成功”——调查人员几乎无法回答最关键的问题。字段是由终端提出、由 RA 纠正、由第二个 RA 覆盖，还是由 CA 策略直接改写？谁验证了身份？谁验证了私钥占有？CA 是自己重做了检查，还是依赖了上游见证？

RFC 10002《Certificate Management over CMS》把这条链路拆开。它是 2026 年 7 月发布的 IETF 标准跟踪文档，取代 RFC 5272 与 RFC 6402。配套的 RFC 10003定义传输，RFC 10004规定不同角色最低应支持哪些能力。三份文档共同说明：证书申请并不是一个签名通往一个结果，而是一组可嵌套、可见证、可拒绝、可等待的决定。

签名保护的是一个对象

RFC 2986定义的 PKCS #10 请求包含主体名称、公钥、可选属性，以及对这些申请信息的签名。签名让接收方发现受保护内容是否被改动，也表明签名私钥曾经参与。

它没有证明所有东西。它不证明申请人依法拥有某个机构名称，不证明另一个只能解密、不能签名的私钥确实在设备中，也不要求 CA 接受每个扩展。更不可能仅凭终端签名，推导出某个中间机构有权修改申请。

CMC 的简单请求可以直接承载 PKCS #10，但能力有限。RFC 10002 明确说，包含身份证明时不能使用简单请求；无法签名的私钥也需要更完整的机制。完整 PKI 请求把 PKIData 放入 CMS 的 SignedData 或 AuthenticatedData，于是控制项、多个请求体和补充材料能够一起传递。

RFC 5652允许 CMS 容器继续被另一层签名、认证或加密。CMC 借此解决一个现实问题：RA 若直接改写终端签过名的 PKCS #10 或 CRMF 请求，原签名或占有证明就会失效；正确做法是保留内层对象，在外层加入自己的控制和签名。多个 RA 就可能形成多层包装。

因此，内层签名证明“终端保护了哪些字节”，外层签名证明“哪个中间主体加入了哪些控制”。两者都不能自动证明该主体具有相应业务授权。

私钥占有与身份不是同一张票

密钥占有证明回答：申请者能否按规定使用与公钥对应的私钥。签名密钥可以用签名证明；只用于加密或密钥建立的密钥，可能需要挑战、后续消息或确认。RFC 4211 的 CRMF 就为这些情况定义了不同选择，并允许 RA 在特定条件下声明它已经完成占有验证。

身份证明回答的是另一个问题：根据某种认证安排，交易关联的是谁。RFC 10002 的 Identity Proof Version 2 可以用共享秘密对请求材料计算 MAC。它的失败码、验证方和秘密管理都属于身份路径，不属于私钥占有路径。

一个人可以控制私钥却无权使用某个组织名称；服务台也可以确认员工身份，却没有证明那把硬件密钥真的由该设备控制。把两者都写成“verified=true”，会在最需要追责时抹掉差异。

RA POP Witness 允许 RA 告诉 CA：占有证明由我完成。RA Identity Proof Witness 则可以表达：身份检查由我完成，包括 CA 不掌握共享秘密或检查在线下发生的情况。见证是新的声明，不是原始证据本身。CA 可以依据策略信赖它，但记录必须回答：哪个 RA、哪种方法、覆盖哪个主体和密钥、保留什么证据、授权何时到期。

Control Processed 更宽，只表示某个控制已在本地处理或将由后续主体处理。当身份方法本身重要时，RFC 10002 倾向使用更明确的身份见证。这正说明“处理完成”不是完整的审计语义。

不破坏原签名也能改变申请结果

Modify Certification Request 是最容易暴露权力来源的控制。RA 可以请求替换或删除证书申请中的字段，但不触碰内层签名对象。修改要求位于外层，由 RA 自己保护。

这种能力并非天然有害。RA 可能需要规范目录名称、删除未获授权的扩展，或把线下核验结果转换成 CA 可接受的形式。问题在于能否重建：修改指向哪个请求体、旧值是什么、新值是什么、依据哪条规则、由谁提出。

嵌套层的处理顺序是从内到外；同一层存在多个修改控制时，标准没有规定顺序。若系统依赖“数组中后出现的值覆盖前值”，它依赖的是某个实现的偶然行为。顺序影响结果时，应形成一个无歧义的合并决定，或用独立层次明确先后。

CA 仍有自己的决定权。RFC 10002 不要求它写入终端或 RA 请求的每个扩展，也允许依据策略修改内容，但不得反转终端明确要求的限制含义。最终证书因而是 CA 签署的新对象，而不是申请表的公证复印件。

运营方至少应比较三种状态：终端签署的原始请求、所有 RA 建议后的逻辑状态、CA 实际签发的证书。任何差异都需要责任主体和策略理由。“证书是 CA 签的”只说明最终签名者，不能解释每个字段的来历。

传输成功不等于签发结束

RFC 10003 规定文件、邮件和 HTTP 传输。HTTP 使用 POST，HTTPS 可以防止链路窃听。但 TLS 成功或 HTTP 2XX 都不证明 CMC 内的控制被识别，更不证明证书已经最终签发。

完整交易可以处于 pending，也可能只完成一部分。客户端可以查询等待中的结果，证书接受确认又把状态延伸到收到证书之后。最终服务器遇到无法识别或必须处理却无法处理的控制时，应让整个 PKIData 失败，而不是静默丢弃控制再返回漂亮的成功状态。

Transaction ID 将多条消息归入同一操作；一旦使用，后续消息应延续该标识。发送方和接收方 nonce 提供关联与防重放信号。它们并不替代业务幂等，但能防止一次丢包重试被误认成另一项申请。

监控系统如果把 POST 成功计为“证书完成”，就会把传输层符号当成现实层结果。批量请求尤其危险：部分成功不等于整体完成，等待状态也不等于批准。

合规表不是现场证据

RFC 10004 的控制矩阵要求 RA 实现修改请求、Control Processed 与 RA Identity Proof Witness；为 RA 工作的 CA 也必须具备相应接收能力。交易标识和双向 nonce 是各角色的基础能力，RA 还应支持 POP 见证。

这些要求证明协议刻意区分了角色，也规定了合规实现的能力下限。它们不证明某个产品处理了这次嵌套控制，不证明 RA 的职责范围，也不证明证据被保存。合规标签只有在运行代码、策略和产物可以复演时才获得实际权威。

签发也不是信任链的终点。RFC 5280规定依赖方后来验证的 X.509 证书轮廓，同时承认专门领域可能追加策略和保障要求，并提醒使用者阅读 CA 策略。CMC 解决的是申请链路，不替所有依赖方作决定。RFC 7030 还定义了另一种 HTTPS 证书登记方式 EST，说明协议选择本身也不是不可改变的天命。

事故发生后还能复演的记录

可用证据应从原始请求的规范字节与哈希开始，记录格式、公钥、受保护属性、签名算法与校验结果。每一次占有或身份检查，都要记录方法、目标、原验证方、结果、策略版本和保护隐私的证据引用。

每层 RA 包装都应保存其签名、证书、授权范围、添加的控制、移除的层与下一个接收者。修改必须有目标、前后值、层次与理由；见证必须指明它代表哪种原始证明。日志不应保存共享秘密或私钥。

CA 侧则需记录策略版本与每个字段的结论，并生成从原请求、RA 修改到最终证书的差异。Transaction ID、nonce、重试、等待、接受确认、发布和激活事件必须保持关联。

这样，RA 被攻陷时，调查不会因为“原请求签名仍然有效”而误判无害。攻击者完全可能利用已被信任的 RA 凭据，签出恶意的外层修改或见证。没有伪造内层请求，并不代表没有发生越权。

Running-Code Primacy 在这里是一条操作纪律，而不是 IETF 条文：控制的权威来自实际校验它的代码、核对主体范围的策略与留下结果的系统。Minimum Initial Specification 要求共享层只承载必要且可本地验证的机制，不让技术中间人自动升级为业务主权者。现实层视角则迫使“已签名”“已见证”“已签发”回到可执行事实，而不是象征性咒语。