摘要

  • SC100 获得参与投票的 22 家证书签发方和 3 家证书消费方一致赞成，没有反对或弃权；但截至 2026 年 8 月 31 日，知识产权审查仍未结束，计划于 9 月 5 日 19:00 UTC 截止。
  • 草案没有宣称创设新的 DNSSEC 义务，而是整合并澄清既有条文：与域名控制验证和 CAA 有关的适用查询，主网络视角必须验证 DNSSEC；远程网络视角在 MPIC 中可以验证。
  • DNSSEC 与 MPIC 回答不同问题。前者判断一个解析器看到的 DNS 数据能否获得密码学验证；后者要求多个独立远程视角在签发前佐证主视角的判断。
  • 草案既把完整 DNS 查询信息排除在两类日志与自审范围之外，又要求保留足以验证合规的信息。可行的最小证据应由“解析器控制回执”和“单次签发回执”组成，并以主视角身份和时间连接。

先辨认草案，再讨论控制

SC100 官方页面给出了完整的程序状态。22 家参与的证书签发方投赞成票；Apple、Cisco Systems 和 Mozilla 作为证书消费方投赞成票；没有反对或弃权，15 的法定人数要求也已满足。

这只说明表决完成。页面同时写明，30 天 IPR 审查从 8 月 6 日 19:00 UTC 开始，到 9 月 5 日同一时间结束。在此之前，成员仍可提交必要专利权利要求的排除通知。8 月 13 日的工作组会议纪要也只是记录 SC100 最近进入了 IPR 审查期。

最容易误判的是版本号。SC100 的接受修改稿标注为 2.2.9、日期为 8 月 6 日；当前正式 TLS 基线要求同样标注 2.2.9 和 8 月 6 日。然而，正式文本的修订表最后一项是 SC101，并没有 SC100。论坛的版本索引列出正式发布件，而 SC100 附件仍明确印着 DRAFT。

因此，“2.2.9”不是充分的规范身份。证据必须同时写明文档状态、来源和指纹：是当前 Final Guideline、IPR 审查中的 Draft Maintenance Guideline，还是未来真正纳入 SC100 的新发布件。

表决说明还有一道防止夸大的界线。SC100 没有生效日期，因为提案称其目的只是提高可读性、集中散落条款，并无意修改现有要求。本文讨论的是如何证明已经存在的角色义务，而不是宣布一项新义务。

“必须”属于主网络视角

底层义务来自 SC085v2。从 2026 年 3 月 15 日起，主网络视角执行相关域名控制验证与 CAA 查询时，在存在 DNSSEC 链的情况下必须进行验证。现行 2.2.9 已经包含这些要求，只是分布在不同段落。

SC100 接受修改稿拟在 §4.2.2.2 集中表述。主网络视角使用的解析器必须按 RFC 4035 §5 执行验证，支持 NSEC3 和 SHA-2，并正确处理 RFC 6840 §4 的安全注意事项。

接着，草案把动作分配给角色。主网络视角必须对域名授权或控制验证以及 CAA 处理涉及的所有 DNS 查询执行 DNSSEC。仍保留的邮件验证方式有一项局部例外：用于取得 Authorization Domain Name 的 CNAME、CAA、TXT 查询仍属强制，其他查询使用 SHOULD。对于其余验证方式和 CAA，CA 不得通过本地策略关闭验证。主视角遇到 SERVFAIL 等 DNSSEC 错误时，不得把错误解释成允许签发，邮件例外的边界除外。

远程网络视角的措辞是 MAY。它们在参加 MPIC 时可以沿 IANA 根信任锚执行 DNSSEC，也可以不执行。MAY 不是 MUST，也不是 MUST NOT。远程执行 DNSSEC 不会自动证明整次签发合规；未执行也不能被自动记为协议意义上的 Insecure。

真正要保留的，是“角色—解析器—查询—状态—决定”的链条。一条没有角色字段的 Secure 记录，可能来自主视角、某个远程视角、离线测试或诊断系统。它无法证明规范点名的主视角完成了该次签发所需的工作。

MPIC 的数量不是 DNSSEC 验证器的数量

SC067v3引入 MPIC，目标是让同长度前缀 BGP 攻击更难欺骗域名验证。它要求适用的验证方法在签发前，从多个远程网络视角佐证主视角对域名控制与 CAA 的判断。

DNSSEC 则让解析器判断 DNS 数据或经认证的“不存在”证明能否在信任链下通过密码学验证。RFC 4035中的 Secure、Insecure、Bogus、Indeterminate 是解析状态，不包含网络视角的地理独立性，也不包含 CA 最终是否签发。

SC100 草案重录了 MPIC 的分阶段要求：自 2026 年 6 月 15 日起，适用实施至少使用 4 个远程视角，满足法定人数表，并让成功佐证者分布在至少两个 RIR 服务区域；12 月 15 日起最低数升为 5。这是远程观察点的数量，不是被 MUST 约束的 DNSSEC 解析器数量。

证据模型应把二者做成并列维度。主视角一行记录“必须执行、实际状态、错误决定”；每个远程视角分别记录“是否执行 DNSSEC、若执行则是什么状态、是否佐证、是否计入 MPIC”。这样既不会把绿色法定人数伪装成“所有远程都通过 DNSSEC”，也不会把远程可选状态误写成 MPIC 缺陷。

“充分信息”是有意留下的设计空间

SC096先把 DNSSEC 验证从广泛的 DCV/CAA 日志要求中剥离。提案解释，解析器并非为大规模详细日志而设计，变更管理日志可以证明适当控制处于启用状态。

SC100 拟议 §4.2.2.2.7 延续这一限制：与 DNSSEC 有关的完整 DNS 查询信息，不属于 §8.7 自审和 §5.4.1 日志的范围。但紧随其后，草案要求 CA 仍须保留足以验证本节其余要求得到遵守的信息。

7 月 16 日会议纪要记录了取舍。当时剩余争议正是是否规定一种具体日志方法。与会者倾向于要求“充分证据”，同时允许不同实施方式。修改后讨论期重新开始；7 月 30 日纪要称此后没有新的意见，表决才启动。

这不是允许只写一句“已启用”，也不是要求保存每个数据包。标准把最小充分性的设计责任留给 CA。最有用的边界是两张可连接、但作用不同的回执。

第一张证明控制，第二张证明那次签发

解析器控制回执描述某一时间段内，主网络视角被配置为何种能力：

控制回执 ID + 主视角 ID + 解析器/服务 ID + 软件与构建版本 + 配置或策略哈希 + 信任锚版本 + RFC 4035/NSEC3/SHA-2/RFC 6840 能力 + 本地策略例外状态 + 测试运行 + 变更批准 + 生效起止时间

敏感配置不必公开。回执可以保存哈希和受控存储的引用。它证明某个控制在某段时间内被批准并接受测试，却不能单独证明每次请求都走过这个控制。

单次签发回执完成另一半：

尝试 ID + 证书/预证书绑定 + 请求与决定时间 + 名称与验证范围 + 验证方法 + CAA 范围 + 适用规范/草案版本 + 主视角 ID + 解析器/控制回执 ID + 查询类别 + DNSSEC 状态 + 错误与关闭决定 + 远程视角 ID + 每个远程是否执行 DNSSEC及其状态 + RIR 区域 + MPIC 观察与法定人数 + 重试谱系 + 不可变哈希

主视角身份与每个远程的“已执行/未执行”是最不能省略的字段。远程没有执行可选 DNSSEC 时，应中性地写“允许范围内未执行”，而不能写成 Insecure；远程实际执行时，结果必须留在自己的视角与解析器名下，不能复制主视角结果填满表格。

这套回执是 Daniel Kade 的分析建议，不是 SC100 列出的强制字段，也不归因于 DigiCert、提案背书方、投票成员、浏览器、审计师或 RFC。它只是一种让“充分”可测试、同时尊重“无需完整查询集”的方案。

文件、配置与结果必须连接起来

公开 CP/CPS 可以声明实践；软件版本可以标识代码；测试可以证明特定用例；Secure 可以表示一次 DNSSEC 分类；证书可以证明签发发生；MPIC 记录可以证明远程佐证达到法定人数。但这些孤立对象仍不能回答：这一次请求是否由规范要求的主视角，用当时获批的解析器，对规定的查询执行验证，并把错误按规则处理后交给签发决定。

证据的价值在于连接，而不在于文件数量。表决结果证明规范共识，不证明 25 个投票组织的生产部署。某家 CA 没有公开内部实现细节，也不证明它违规。本文不识别任何错误签发、DNS 投毒、隐瞒日志或具名机构失误。

仍需等待的只有可以明确列出的状态：9 月 5 日 IPR 结果、最终条文、真正纳入 SC100 的正式版本，以及每个实施者自己的运行证据。

来源