摘要

  • 在 SC-104 指定的 TLS 基准要求基础版本中，订户证书必须包含非关键的 Authority Information Access（AIA）扩展；但其中 id-ad-caIssuers 的存在级别是 SHOULD，id-ad-ocsp 则是 MAY。
  • 提案的不可变差异只改两处：把外层 AIA 扩展的 MUST 改成 SHOULD，并在“至少一个 AccessDescription”规则前加上“若存在”。两种访问方法的级别、用途与位置编码规则没有改变。
  • 公开通知把投票期定在 2026 年 8 月 27 日至 9 月 3 日 00:00 UTC。本文研究截止于 9 月 2 日，因而不提前声称投票通过、知识产权审查完成或新文本已经成为正式指南。
  • caIssuers 用于取得颁发者证书、辅助构建认证路径；OCSP 指向在线状态服务。它们共处一个 ASN.1 容器，却不是同一种功能，也不能互相代替。
  • 应把程序、配置规范、方法规则、证书字节和依赖方运行结果分别记账，再用版本与指纹连接。单一的“AIA 合规”字段无法证明这五件事。

先看证书里真正嵌套了什么

这项提案的关键不在“AIA 是否重要”这样宽泛的问题，而在三层规范语句如何套在一起。

第一层是订户证书扩展表。在投票所声明的基础提交 ad77bf… 中，authorityInformationAccess 的存在要求为 MUST，关键性为否。第二层是容器语法：一旦有 AIA，AuthorityInfoAccessSyntax 必须包含一个或多个 AccessDescription。第三层才是允许出现的方法：id-ad-caIssuers 为 SHOULD，id-ad-ocsp 为 MAY，其他方法一律 MUST NOT。

所以，现行基础文本要求一定要有“盒子”，盒子也不能空着，却没有保证盒子里一定出现某一个特定服务。caIssuers 是有规范分量的强建议，不等于随意选择；OCSP 则明确只是允许。两者不能被一个“都是可选”标签压平。

SC-104 的两行修改正对准这个结构。扩展表里的 MUST 变成 SHOULD；容器语法前增加“若存在”。它没有改变 caIssuers 与 OCSP 的级别，没有增加新的 OID，也没有把这一修改扩展到所有 CA 证书或 OCSP 响应者证书。提案由此变得很窄，也更需要精确描述。

“AIA 从必需变成可选”听起来方便，却不准确。正确说法是：如果提案最终成为有效指南，外层存在要求将从 MUST 变为 SHOULD；在有充分理由并理解后果时可以偏离，但偏离仍需解释。

SHOULD 需要理由，MAY 才是明确许可

RFC 2119 对 SHOULD 的含义有一项容易被忽略的约束：某些情形可以不遵循，但实施者必须理解完整后果，并谨慎权衡后再选择另一条路径。RFC 8174 又限定了这些大写关键词何时承担规范含义。

这意味着，未来若有订户证书省略 AIA，仅凭“规则写着 SHOULD”还不足以形成好的治理记录。至少还应知道：采用了哪个指南版本，哪个签发配置决定省略，理由是什么，适用于哪类证书，从何时开始，以及经过了哪些依赖方测试。

把 SHOULD 实施成完全不留痕的 MAY，并非忠实地执行了放宽后的规范。反过来，把 SHOULD 当成没有任何例外的 MUST，也会消除提案所要建立的空间。两种误读都源于记录模型太粗。

方法层同样如此。证书包含 AIA，只证明外层容器存在；它不证明 caIssuers 与 OCSP 同时存在。证书不含 AIA，也不能直接推出某个客户端一定失败。审计必须先问清楚所讨论的是哪一层。

同一个容器里的两条路

RFC 5280 把 AIA 定义为一组关于颁发者信息或服务的访问描述，并要求该扩展标记为非关键。id-ad-caIssuers 给出取得颁发者证书的位置，可以协助依赖方选择或建立认证路径；id-ad-ocsp 则给出在线证书状态协议服务的位置。

一个回答“中间证书从哪里来”，另一个回答“状态服务在哪里”。它们可能都使用 HTTP URL，也可能同时出现在一个扩展里，但用途不同。对 caIssuers 的可达性测试，不能替代 OCSP 响应测试；一次 OCSP 请求成功，也不能证明客户端拿到了缺失的中间证书。

基准要求的其他部分也会读取这个差别。例如，订户证书是否包含 AIA OCSP 指针，会与 CRL 更新频率或 CRL Distribution Points 的条件发生联系。因此，观察记录不能只写“AIA 有/无”，而要列出每个方法 OID、位置、出现次数和当时适用的规则。

更重要的是，认证路径并不只从 AIA 产生。TLS 服务器可以交付适当的中间证书链；客户端可能已经把中间证书放在本地存储或缓存中；供应商也可能通过自己的分发机制预置证书。AIA 中的 caIssuers 是一条潜在路径，不是整个路径构建过程的录像。

客户端品牌不是行为证据

微软的官方文档说明，Windows 可以通过 AIA 取得缺失的颁发者证书，同时管理员可以关闭这项检索。仅这一点就足以说明“Windows 支持 AIA”不是可复现实验结果。版本、策略、缓存、网络、URL 可达性和服务器所交付的证书链都会改变最终行为。

Mozilla 在 2020 年公开介绍过另一种机制：Firefox 通过 Remote Settings 预加载已披露的中间 CA 证书，以减少网站没有正确发送中间证书时出现的 unknown issuer 错误。这是一项有边界的实现实例。它不能证明所有版本、所有中间证书和所有运行环境都具有同样状态，更不能把服务器正确配置证书链的责任取消掉。

把两个实例放在一起，得到的不是“客户端都不依赖 AIA”这一结论，而是一张变量表：有的客户端可能联网检索，有的依赖预置或缓存，有的禁用外部取证，有的嵌入式栈根本不实现这种路径。同一张证书在不同条件下可以得到不同结果。

因此，证书通过验证时，记录还要说明中间证书究竟来自服务器、系统存储、缓存、预加载还是 caIssuers 下载。否则，成功会被错误归因给 AIA；下一次移除缓存或改变服务器链时，真正依赖就会暴露得太晚。

先让投票走完自己的生命周期

SC-104 的公开通知列出提案人 Ethan Davis（Google Trust Services），以及附议人 Roman Fischer（SwissSign）和 Stephen Davidson（DigiCert）。通知说明基础版本为 Baseline Requirements 2.2.9，并链接到基础提交与拟议提交之间的不可变比较。讨论期为 8 月 20 日至 27 日 UTC，投票期随后持续到 9 月 3 日 00:00 UTC。

在 9 月 2 日截点，能证明的是“正在投票”，不能证明“已经通过”。GitHub 拉取请求开放、工作组投票成功、知识产权审查结束、最终维护指南发布以及生效日期，是连续但不同的治理状态。任何一步都不能被下一步的预期替代。

即便之后投票成功，CA/Browser Forum 章程所规定的知识产权审查仍有自己的记录。只有最终指南版本和生效信息，才能回答某张在某日签发的证书适用哪条公共基线。后来发生的通过，也不会把 9 月 2 日的提案状态改写成既成规则。

一份合格的程序回执应保存：投票编号、提案人与附议人、基础与拟议提交、讨论期、投票期、合格投票分母、票数与结果、IPR 审查起止、排除通知、最终指南版本与生效日期。回执是追加状态，不是用最新标签覆盖历史。

五层回执如何工作

第一层：程序状态。 记录 SC-104 当时处于草案、讨论、投票、IPR 审查还是已发布状态，并冻结对应提交。它证明规则取得何种权威，不证明有人已经按它签发证书。

第二层：配置规范。 记录证书类型、指南版本、外层 AIA 的准确规范词、关键性与生效日。它说明应当遵守什么，不说明实际字节。

第三层：方法矩阵。 为 caIssuers 和 OCSP 分别记录 OID、用途、SHOULD 或 MAY、位置类型、数量与排序规则。两行必须分开，不能汇总成“AIA 方法”。

第四层：签发观察。 记录颁发 CA、产品、模板或配置版本、证书指纹、AIA 是否存在、各方法及 URL 是否编码、观察时间。它证明这张证书是什么，不证明客户端使用了什么。

第五层：依赖方运行。 记录客户端产品与版本、平台、管理员策略、信任存储、缓存或预加载、服务器交付链、网络条件、是否发起检索、中间证书来源、状态检查路径与最终结果。它证明一次可复现实验，不代表整个生态。

五层之间要能连接，但不能融合。指南版本连接程序与配置；签发配置连接规范与证书；证书指纹连接证书与运行观察。某客户端失败不会倒推出投票无效，某客户端成功也不会证明省略对所有人无害。

这正是“最小初始规范、本地可核验决定、采用不等于发布”的方法在此处的价值。引用 Lu Heng 并不意味着他评价过 SC-104；它提供的是一条编辑纪律：公共规则只负责自己能确定的部分，部署事实必须由本地证据承担。

当前证据没有回答的问题

现有材料没有统计订户证书中 AIA、caIssuers 或 OCSP 的占比；没有说明多少 CA 会在规则变化后修改模板；没有量化证书体积、隐私、网络流量、可用性或安全影响；也没有证明某个依赖方提出了这项修改。

提案理由可以在规范结构上成立：如果内层没有任何特定方法是 MUST，外层 MUST 的保证确实有限。但“结构一致”不是“运行收益已经证实”。支持者需要避免从 Firefox 预加载推导普遍无害，反对者也需要避免从一个可能依赖网络取证的环境推导普遍故障。

合适的问题不是“AIA 到底有没有用”，而是：哪类证书、哪种方法、哪个客户端、什么配置、哪条证书链、哪个时间点，出现了什么结果。只有拆开后，这些答案才可能累积。

两行修改需要五份证据

CA/Browser Forum 可以按章程决定是否让外层存在要求与内层方法级别更加一致。CA 可以在规则生效后选择保留默认 AIA，或者在有理由的范围内省略。客户端厂商可以保留各自的路径构建策略，服务器运营者仍需交付适当证书链。

这些权力相互影响，却不属于同一个控制者。若把它们写成“SC-104 让 AIA 不再必要”，程序状态、规范语义与运行现实就被越级连接了。

更好的公开句子会小得多：某一版本的指南把外层从 MUST 改为 SHOULD；某张带指纹的证书省略或保留了哪些方法；某个具名版本与配置的依赖方，通过哪条路径得到了什么结果。

两行修改并不需要宏大的预言。它需要的是五层可追溯状态。

来源

  1. Lu Heng，《Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption》
  2. CA/Browser Forum servercert 拉取请求 665：SC-104
  3. SC-104 不可变差异
  4. CA/Browser Forum servercert 议题 673
  5. SC-104 投票通知公开存档
  6. 投票基础提交中的 TLS Baseline Requirements
  7. CA/Browser Forum 章程
  8. RFC 5280 第 4.2.2.1 节
  9. RFC 2119
  10. RFC 8174
  11. Microsoft：Authority Information Access 检索
  12. Mozilla Security Blog：在 Firefox 中预加载中间 CA 证书