摘要

  • RFC 9883 允许已认证的签名密钥为另一份密钥建立证书请求携带持有声明。
  • 该声明是对持有情况的断言，不是对新私钥的技术证明。
  • CA 必须验证签名证书路径、请求签名，并按照策略判断主体和 SAN 是否等价。

最危险的操作误读，是把“签名验证成功”和“持有另一把私钥”当成同一件事。前者说明谁签署了请求；后者涉及谁控制请求中新的私钥。privateKeyPossessionStatement 属性把已有签名密钥的部分保证转移给密钥建立密钥，但转移形式仍然只是签名断言。

该属性的 OID 是 1.3.6.1.4.1.22112.2.1。其完整结构为 PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }：signer 用签发者名称和序列号标识签名证书，可选字段 cert 则携带该签名证书。只有在 CA 同时是签名证书的签发者，并且能够取得自己签发的全部有效证书时，才允许省略 cert。这是有限的证书检索例外，不是允许 CA 猜测签名者身份。

CA 必须验证签名证书的认证路径；路径无效时必须拒绝请求。CA 还必须使用签名证书的公钥验证请求签名；验证失败时必须拒绝。请求中的主体名称和 SAN 应与签名证书中的相应名称匹配。若有差异，证书策略必须说明二者为何等价；无法建立等价关系时，CA 必须拒绝。该属性不得用于申请签名证书。

PKCS#10 中，subjectPublicKeyInfo 承载密钥建立公钥，属性集合承载持有声明，请求签名用签名证书验证。CRMF 的结构不同：证书请求承载主体和密钥建立公钥，格式自身的持有证明使用签名选择和发送者身份，而 regInfo 承载持有声明。两种格式表达相近的注册意图，但不能因此把不同的编码结构视作同一种消息格式。

RFC 5280 提供认证路径和密钥用途的基础。RFC 6955 可作为对照，它描述了针对 Diffie-Hellman 密钥的技术性持有证明机制。这个对照也划清边界：RFC 9883 没有把该属性变成第二把私钥的密码学证明。它的控制对象也不同于讨论 PKIX 中 ML-DSA 标识符的 RFC 9881，以及讨论 CMS 签名字节范围的 RFC 9882。

Theo March 分析：可以把签名证书视为对第二把密钥的委托保证根。这是运营分析，不是 RFC 9883 的强制要求。实际系统应在审计中把每张派生的密钥建立证书关联到授权签名证书，记录主体等价判断，并监控每个签名者的请求量、主体变化、重复请求和验证失败。这样才能审查保证转移，而不是只看到一枚有效签名。

这种关系会形成撤销扇出。RFC 9883 指出，签名证书遭到破坏时，及时撤销是规范所确定的唯一保护，并指出 CA 应撤销通过该受损证书签署的声明取得的密钥建立证书。派生证书清单、告警和自动传播属于 Theo March 分析，不是规范规定的审计或自动化方案。签名密钥的安全强度应至少等于密钥建立密钥。迁移时应阻止较弱的授权者，测试算法变化和主体等价策略。

注册测试用例应包括：路径和签名均有效；路径无效；请求签名被修改；非签发 CA 场景下缺少嵌入式证书；签发 CA 能成功检索时省略证书；主体或 SAN 不同且有、无策略等价说明；试图申请签名证书；签名密钥强度较弱；以及分别在正确字段中检查 PKCS#10 和 CRMF。审计记录至少应能关联签发者、序列号、请求和目标公钥指纹、策略决定及签发证书。

事件处理路径是：先停止可疑签名证书发起的签发并保存证据；确认是否受损后及时撤销签名证书；按声明找出所有派生证书并依 CA 策略评估或撤销；必要时轮换两类密钥；复核主体等价和强度例外；最后持续监控重放和新声明。这是运营分析路径，不是 RFC 9883 规定的完整事件流程。

来源