摘要

  • CA/Browser Forum 的 pull request 622 仍是开放中的 Draft Ballot SC-XX，尚无最终提案编号，也没有完成正式讨论、投票、IPR 审查或生效程序。
  • 现行 TLS Baseline Requirements 2.2.9 从收到 Certificate Problem Report 或相关通知开始，计算到公开吊销状态的时限。草案先给 CA 24 小时判断报告是否 actionable，再从该判断启动相应的吊销时钟。
  • Actionable 只是报告足以进入调查流程，并不代表违规已经证实。冻结文本要求至少指出一张仍在有效期且未吊销的证书，并说明可能违反的规则或适用的吊销理由。
  • 同一个可处理时间戳还会启动 120 小时的全量检查：CA 要检查自己签发的其他有效且未吊销证书。每张后来发现的受影响证书，又从首次识别时获得自己的吊销时钟。
  • 草案拟把 Revoked 定义为可观察状态：证书声明的相关 CRL 地址必须列出序列号，相关 OCSP 地址必须返回 certStatus=revoked。这比内部数据库标记更强，但不等于全球缓存在同一毫秒同步。
  • 一个保护隐私的吊销回执应串联正式渠道收件、可处理判定、实质结论、群体扫描、理由对应时限和状态发布；它可以公开时间、数量与状态码，而不公开私钥、报告正文或订户资料。

一次收件，至少产生三只时钟

Certificate Problem Report 看起来可能只是一封邮件：一个序列号，一段验证流程的异常，或一份私钥已经失守的证据。但报告指出的是入口，不一定是边界。签发方法的缺陷可能覆盖同一时期的一批证书；一把密钥可能对应多张证书；外部研究者通常只能看到样本，无法查询 CA 的签发库存。

PR 622 试图把这种不确定入口拆成一组明确步骤。CA 收到报告后，拟在 24 小时内判断它是否可处理。作出肯定判断后，如报告人可联系，CA 还拟在 24 小时内告知调查发现；相应的吊销时限从可处理判断开始；另有 120 小时用于检查该 CA 签发的全部其他、仍在有效期且尚未吊销的证书。

这里并不存在一只总时钟。第一只衡量收件到分类，第二只依吊销原因衡量分类到状态发布，第三只衡量分类到群体扫描完成。扫描每找出一张额外证书，还会从“首次识别”生出一只新的理由型时钟。

现行 2.2.9 的结构较直。它要求在收到报告后 24 小时内给出初步报告，并规定从收到 Certificate Problem Report 或吊销相关通知到公开吊销，不得超过 4.9.1.1 所列时限。那些时限并不统一：私钥泄露、域名验证已不可靠等情形要求 24 小时内吊销；另一些理由是 24 小时 SHOULD、五天 MUST。因此，只记录“已按时处理”没有意义，必须同时知道触发时刻和理由类别。

草案把第三方报告场景中的外层起点从收件移到可处理判定。其理由也明确把这个间隔视作好处：CA 先有一段有限时间确认报告是否提供了足够信息，然后才承担理由对应的吊销时限。这可以防止一条无法识别证书、也说不清问题的消息立刻启动高风险操作。但分类一旦决定合规时钟，它就不再只是收件箱里的行政动作。

“可处理”不是“已证明”

冻结草案为可处理性设置的是调查门槛，而不是裁决标准。报告要给出至少一个有效标识，指向该 CA 签发、当时仍有效且未吊销的证书。CA 必须支持序列号；支持证书或预证书的 SHA-256 指纹是 SHOULD。报告还要说明证书如何违反 Baseline Requirements 或 CA 自身政策，或者提出私钥泄露等吊销理由。

满足这些字段的报告仍可能判断错误。报告人可以找到真实证书、援引真实条款，却误解事实；CA 也可能在调查后认定没有不合规。反过来，CA 不能把 actionable 理解成“我们已经同意指控”，否则计时要等调查结论完成才开始，入口门槛就会变成终局裁判。pull request 的公开讨论反复区分了可处理判定、不合规事实和补救完成，这种区分应被保留。

入口本身也是边界的一部分。草案要求 CA 在 Certification Practice Statement 的 1.5.2 节写明流程，并建议设置容易找到的页面、FAQ 或知识库。表单可以阻止明显不可处理的提交，但必须让符合门槛的报告进入。审阅者因此争论：域名、序列号、指纹和私钥分别能否通过表单；邮件是否必须保留；报告若发给普通员工又如何计算。

这些讨论尚不是规则，却暴露了一个实际条件。私钥发到人力资源员工邮箱，不能合理地让这名员工承担技术响应时钟；官方安全表单若在建立案件前就拒绝报告人唯一能提供的证据，也不能算有效入口。回执至少应记下正式渠道、收件时刻，以及当时适用的公开说明版本。

终点终于能够在 CA 之外被测试

PR 622 最扎实的改动，是拟新增 Revoked 的定义。若证书包含 CRL Distribution Point URI，那么该位置可取得的 CRL 必须包含证书序列号；若证书包含 Authority Information Access OCSP URI，对该位置查询该序列号必须得到 certStatus 为 revoked 的响应。

servercert issue 252 自 2021 年起追问的正是这个问题：吊销是操作员改动数据库字段的时刻，是签署新 CRL 或 OCSP 响应的时刻，是把对象放到源站的时刻，还是依赖方经证书指定的分发接口实际能取到新状态的时刻？

对于外部信任判断，内部比特位不足以构成结果；一份签好却没有抵达公开接口的对象也不够。草案把完成条件放在依赖方实际查询的边界。如果证书同时声明两类相关状态位置，合理阅读就是两类条件都应满足。

但“可查询”不等于所有节点瞬时一致。issue 252 的讨论记录了 CDN 刷新和缓存清理的困难；按需 OCSP 服务甚至可能在请求到达时才生成响应。新定义更适合被理解为一个可观察的完成条件，而不是全世界每个缓存同时变化的保证。

于是一个不对称结构浮现出来：终点可以从 CA 外部探测，起点——把报告判为可处理的瞬间——首先只存在于 CA 内部。

120 小时扫描把一个样本变成一个群体

群体检查可能是草案影响最大的一步。报告人只须使一张证书达到可处理门槛；CA 则须在 120 小时内检查自己签发的其他有效、未吊销证书，寻找相同不合规的实例。规则没有把完整枚举责任交给外部人，因为发行记录、验证方法、客户联系和部署历史掌握在 CA 手中。

DigiCert 的 CNAME 验证事件说明了这种信息不对称，但不能被当作“草案必然能阻止事故”的证据。Bugzilla 1910322 记录，第三方最初没有交出其已知的序列号；DigiCert 后来的事件报告把未严肃对待缺少序列号的报告列为根因之一，并称完整报告时有 83,267 张通过该方法签发的有效证书。最初线索与实际受影响群体是两种完全不同的对象。

如果规则要求外部报告人枚举所有证书，就会把调查责任放给信息最少的一方。草案的一证书门槛加 CA 全量扫描，更贴合能力分配。可它也增加了需要证明的时间点：120 小时从可处理判定开始，每张额外证书的吊销时限从首次识别开始。

一句“群体检查已完成”无法区分扫描何时启动、系统何时匹配到证书、调查员何时把结果写进案件。可审计记录至少需要初始群体定义、方法或查询版本、开始和完成时间、检查数量、新发现数量、例外类型与后续更正。无需公开查询代码或客户名单，但不能让后来暴露的一批证书看起来像从未处于原始搜索面。

提高报告质量，不能成为删除早期历史的许可

PR 622 的动因之一是报告摩擦。DigiCert 事件中，报告人最初没有提供已知序列号。SSL.com 的 Bugzilla 1942270 描述了从邮件被引导至表单、又不确定如何填写 “thumbprint” 的经历；该问题最终被标记为 INVALID。GoDaddy 的 Bugzilla 1942241 则涉及官方地址拒收装有泄露密钥材料的压缩附件，最终状态为 FIXED。

这些材料没有证明唯一正确的渠道设计。邮件附件可能因合理安全策略被过滤，表单也应抵挡垃圾和普通客服问题；明文私钥需要特殊处理，报告人也可能有错。草案没有把每条消息变成吊销命令，这是必要克制。

风险在于把质量门槛变成历史消失器。按冻结文本，若报告不可处理且有联系方式，CA 通常须在判定后 24 小时内说明缺少什么。报告人以后补齐材料时，新材料的收件可以成为后续时限依据。这个时间点可以合法启动吊销钟，但不应新建一个与原始来件毫无关联的案件。

一个稳定案件标识应贯穿“已收件—不可处理—请求补充—已补充—可处理”。否则，周一到达的实质性指控在周五补上序列号后，公开记录会像案件周五才出现一样。规则或许允许周五启动吊销时限，治理记录仍应保留周一以来的全过程。

回执可以很窄，却必须把状态接起来

这里需要的不是公开事件材料，而是对草案已经创造的状态作最小连接。

状态 回执至少包含
正式收件 渠道、公开说明版本、收件时间、保护隐私的报告标识
初步分类 可处理判定时间、必要输入齐备或缺失情况、有限理由码
实质发现 违规或吊销理由类别，与可处理性明确分开
初始证书集 数量、受保护标识、适用的 24 小时或五天类别
群体检查 范围、方法版本、起止时间、检查量、新增量与例外
后续发现 每个受保护项目或聚合批次的首次识别时间与时限类别
状态发布 每个相关 CRL/OCSP 位置与第一次成功观察到吊销的时间
剩余状态 传播例外、订户协调、更正和下一动作负责人

公开层可以披露时间、数量和状态码。证书标识可在会伤害订户或调查时采用哈希或延迟披露。明文私钥、报告正文、账户记录、内部检测查询和安全表单控制不应公开；审计员或根程序可以查看受保护层。

这里可以有限借用 Lu Heng 对“现实层”的区分。它不是 Web PKI 规则，也不能替 CA/B Forum 作决定；它只提供一种检验：状态名称必须与使其产生后果的可执行事件相连。Actionable 改变合规时钟，Revoked 改变依赖方可以接受什么。两者都需要时间戳和观测，而不能只剩标签。

草案里的日期不是生效日期

截至本次资料冻结，pull request 仍以 Draft Ballot SC-XX 为题。冻结 head 为 ef1dda7b7652d439c3b4b8db2328c4afd4a31ec0，其 base 为 6aba16d239d793d547c9397c50a3013257107bb6；用于对照的当前 main 冻结在 5c13e270b4e0b6aaef258acf0a642d1c5a36cf97，文件版本为 2.2.9。

PR head 里的文档仍自称 2.2.2，并写有 2026 年 9 月 15 日拟生效日期。这个组合本身就是警告：那是工作分支里的草案字段，不是已通过的时间表。会议记录表明工作组讨论过这项工作，不等于章程和章程细则要求的提案、投票、IPR 与发布步骤已经完成。

因此，运营团队可以现在测试接收回执和扫描日志，不能把草案日期当成现行义务。监测对象应是最终提案号、正式讨论期、投票、IPR 状态、合并后的规范版本和明确生效条款。

来源

  1. Heng Lu：《On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile》
  2. CA/Browser Forum servercert pull request 622
  3. 冻结 head ef1dda7b… 中拟议的 Baseline Requirements
  4. 冻结 main commit 5c13e270… 中的现行 Baseline Requirements
  5. servercert issue 252：澄清吊销的技术含义
  6. Mozilla Bugzilla 1910322：DigiCert CNAME 验证事件
  7. Mozilla Bugzilla 1942270：SSL.com 报告机制投诉
  8. Mozilla Bugzilla 1942241：GoDaddy 附件投诉
  9. SCWG 2026 年 8 月 13 日会议记录
  10. Server Certificate Working Group 章程
  11. CA/Browser Forum 章程细则