Mozilla

年度鉴证报告可以说明某个证书颁发机构的控制措施在一个确定期间内接受了审查。它本身却回答不了依赖方真正可能需要追问的更小问题：为何这张证书、这组名称和这把密钥会在这个时点被签发；客户端后来遇到它时又实际发生了什么。

Mozilla 的公开规则把常被一句“已批准”混在一起的动作拆得很清楚：模块负责人或同级评审可以同意某项代码进入特定模块；个人可以另行获得仓库提交权限；改动可以落入某条分支；Firefox 之后还可能、也可能不会把它纳入面向用户的发布渠道。它们彼此衔接，但任一环节都不能代替其他环节的证据。

到了 2026 年 9 月，一家证书颁发机构说自己“遵守现行 TLS Baseline Requirements”，这句话仍然不能告诉审计者它用了哪套域名控制算法。现行 v2.2.9 已经写入更严格的顺序，但同一份文件又明确允许 CA 在 11 月 15 日前继续采用 v2.2.7 的对应条款。过渡安排本身合理；若签发记录把版本选择藏在一句“符合现行要求”里，日后便无法还原授权边界。

Mozilla 发起了公共后缀列表，Firefox 至今仍把其中一个版本变成浏览器行为。DNS 能说明 `whatwg.github.io` 位于 `github.io` 之下，却不能说明两个子域属于同一管理者，还是彼此不信任的租户。本文追踪 Mozilla 的两项有限角色——项目发起者与下游实现者——说明一份社区记录如何在运行代码中形成安全权力，同时不把 Mozilla 误写成列表的所有者。

Mozilla 2019 年 5 月的附加组件停运事件表明，当证书生命周期、远程恢复、隐私和用户数据保护措施叠加时，一项合理的安全要求可能成为共模可用性依赖。