摘要

  • RFC 9883 允许主体使用已经获证的签名私钥，声明自己持有另一把用于密钥建立的私钥；标准明确说明，这一声明并不提供技术证明。
  • CA 的接受决定依赖签名证书路径、请求签名、名称绑定、证书找回能力，以及明确允许这种替代的证书策略。
  • 一旦签名私钥泄露，依赖关系必须向后追溯：由它签署声明而取得的密钥建立证书也应被找出并撤销。

证书受理台看到的材料很容易制造“已经证明”的错觉：新公钥在请求里，privateKeyPossessionStatement 也在，外围签名验证成功。但真正执行签名的是此前已获证的签名私钥，而不是新公钥对应的密钥建立私钥。后者没有执行任何可观察的证明操作。

两把私钥承担不同事实

RFC 9883 的 PKCS#10 流程分两阶段。主体先生成签名密钥对，用它签署普通请求并取得签名证书。随后生成密钥建立密钥对，把新公钥与持有声明放进第二份请求，再用原来的签名私钥签署第二份请求。

标准对这一动作的含义限定得十分清楚：签名证书的主体声称自己持有密钥建立私钥，但“不提供证明”。只有证书策略允许时，CA 才能用该声明替代通常的持有证明。RFC 6955 为部分 DH、ECDH 场景提供技术证明，但不适用于 PKCS#10，也不支持 ML-KEM 这类 KEM。RFC 9883 的声明则可用于 PKCS#10 和 CRMF。

因此，有效签名只证明一件较窄的事：申请者在这次请求中控制了签名私钥。它还能把一个既有证书身份与对另一把密钥的主张绑定起来，却不能证明那把密钥在哪儿生成、是否可导出、现在是否仍可用，或是否受到某个硬件边界保护。

缺失的证明由策略承接

CA 仍须按 RFC 5280 验证签名证书路径，并使用其中的公钥验证请求签名；任一步失败都必须拒绝。请求主体名与签名证书主体名应当相同。若主体名或主体备用名不同，证书策略必须说明如何确认它们指向同一实体；无法确认就必须拒绝。

声明用签发者和序列号标识签名证书，也可以直接携带证书。若两张证书由同一 CA 签发，证书可省略，但这意味着申请者假定 CA 能找回自己签发的全部有效证书。这不是编码天然保证，而是仓库完整性与时点状态的运营事实。一个定位符并不等于已找回的证书、已验证的路径或当时的撤销状态。

PKCS#10 把新公钥和声明放进被签名的请求信息。CRMF 则要求 ProofOfPossession 走签名分支，携带 poposkInput、发送者身份和新公钥副本，并在 regInfo 中加入声明。两种封装保持了同一边界：密钥建立私钥没有因此完成技术证明。

这也解释了为什么 RFC 9883 禁止用该声明申请签名证书。能签名的私钥可以直接签署自己的请求来证明持有。替代机制只服务于不能用同样方式完成证明的密钥建立用途。

签发同时创建撤销图

若签名私钥失控，攻击者就能制造新的持有声明。标准给出的保护是及时撤销签名证书；因泄露而撤销它时，CA 还应撤销所有依据其声明签发的密钥建立证书。

这要求签发时就保存反向索引：签名证书、请求字节、策略版本、身份判定和最终证书必须可相互追溯。签名密钥强度也应至少不低于密钥建立密钥，否则承担信用的桥梁会成为更弱的一环。

来源