摘要

  • RFC 10007 更新 RFC 5280：当 CRL 签发者证书是 v3 时，验证方必须确认 keyUsage 扩展存在，并确认其中置位 cRLSign。
  • 同一主体可以持有两张包含不同钥匙的证书；主体名、信任锚与签名校验都通过，仍不能把第一把钥匙的撤销签名权推给第二把钥匙。
  • 新规则还会拒绝本来想用于 CRL、却漏发扩展的旧 v3 证书；CA 负责重签发，策略权威负责必要的用途分名，依赖方负责分阶段执行与撤销覆盖证明。

一个主体，两把钥匙

RFC 10007 给出的例子极其具体。CA 向主体 X 签发钥匙 A 的证书，证书带有 keyUsage，其中明确置位 cRLSign。随后，CA 又向同一个主体 X 签发钥匙 B 的证书；B 用于普通业务，因此证书没有 keyUsage。

另一批证书把 X 写入 CRL 分发点里的间接签发者字段。X 如果改用 B 签署 CRL，名字仍然匹配，B 的证书链也可能回到同一个信任锚，数学签名同样可以正确。缺失的是对 B 这把具体钥匙的用途授权。

RFC 10007 的资料页把它列为 2026 年 6 月发布、更新 RFC 5280 的标准轨道文件。旧版 RFC 5280 正文在 CRL 处理步骤里写的是：如果 keyUsage 存在，就检查 cRLSign。问题恰在“如果”。扩展缺失时，检查也被跳过。

而 RFC 5280 资料页所对应的签发规范早已要求：凡是用于验证证书或 CRL 签名的钥匙，合规 CA 必须在证书中加入 keyUsage。RFC 10007 把消费端算法与签发端要求对齐：v3 证书不仅要有正确的位，还必须先有这个扩展。

v1 与 v2 证书没有扩展字段，因此新规则不会要求它们携带不可能存在的数据。这不是普遍收紧所有历史证书，而是修补 v3 能表达、也本应表达用途时的空缺分支。

名字、钥匙、链与用途不能合并

主体 X 可以完全真实。钥匙 B 也可以确实由 X 掌握。错误不需要冒名者；只要系统把“属于同一个主体”误当成“拥有同一种职权”就足够了。

RFC 4514 正文规定 LDAP 中可传输的可分辨名称字符串表示，资料页限定了这项工作。DN 便于表示和比较，但它不是公钥指纹，更不是把主体下所有钥匙合并成一个权限集合的凭证。

RFC 5280 也把 digitalSignature、keyCertSign 与 cRLSign 分开。cRLSign 专指验证 CRL、delta CRL 与权威撤销列表的签名。钥匙在数学上能签名，不代表证书允许它签署这一类状态声明。

Datatracker 的 RFC 10007 页面、草案历史、LAMPS 章程与工作组历史能证明审议和发布过程，不能证明某个产品、私有 PKI 或 CA 已经采用。

间接 CRL 是一组同时成立的主张

间接 CRL 的签发者与目标证书的签发 CA 可以不同。目标证书的分发点可用 cRLIssuer 指定另一主体；CRL 的关键 issuingDistributionPoint 扩展则声明 indirectCRL，并限制证书类型、原因或分发点范围。

因此，验证至少要分别回答：签发者名是否符合目标证书的指向；间接标志与范围是否吻合；签发者证书链是否回到同一信任锚；CRL 签名是否正确；这把钥匙是否明确获准签 CRL；列表是否新鲜并覆盖所需原因。

RFC 10007 只修补第五问。正确的 cRLSign 不能证明 CRL 内容真实、范围完整、仓库可达或时间仍有效。

RFC 3647 正文把 CA、注册权威、仓库、订户与依赖方分开，也把证书策略、操作声明、状态服务可用性、审计与物理控制分开。RFC 3647 资料页提醒管理者：一个密码学判断从不自动承担整套服务的责任。

修补漏洞也可能切断撤销证据

RFC 10007 明确警告：如果某张 v3 证书原本打算用于 CRL 验证，却没有 keyUsage，实施新算法的应用将无法再验证它签署的 CRL。这个拒绝符合修订后的安全不变量，但会把旧签发缺陷变成眼前的服务问题。

CA 的首选动作应是盘点、修正证书模板、重签发、设置重叠窗口并有证据地退役旧证书。如果确实无法调整证书配置，RFC 建议该 PKI 的策略管理权威修改命名要求，让不同用途使用不同 DN。这一后备方案能减少同名歧义，却不能代替钥匙保管、范围与新鲜度控制。

依赖方还必须保留“状态不确定”。拒绝一份 CRL，并不等于目标证书已撤销；它只表示这份材料不能被接受。如果系统把失败一律映射为“未撤销”，安全检查失效；一律映射为“已撤销”，正常服务会被无证据阻断。

OCSP 另有授权链。RFC 6960 正文要求响应者由 CA 直接签署、在本地配置，或在规定签发关系下具有 id-kp-OCSPSigning 扩展；资料页说明的是另一套机制。RFC 10007 没有把 OCSP 变成自动兜底。RFC 6818 正文及其资料页则表明 RFC 5280 此前也曾被维护；文档更新仍不等于部署完成。

共同规则要薄，执行证据要厚

Lu Heng 的运行代码优先原则把“已经发表”与“已经运行”分开。他关于最小初始规范、本地化未来决策与自愿采用的框架，主张共同层只保留可确定、可本地验证的安全不变量，部署节奏则由承担后果的参与者掌握。

“v3 钥匙只有在证书明确声明 cRLSign 时才能签署 CRL”正是薄而明确的规则。它不需要委员会判断钥匙 B 看起来是否可信。依赖方可以检查确切证书并本地拒绝。至于何时升级、怎样重签发、如何保留撤销覆盖，仍需要运行系统给出答案。

来源