谁批准了 Company-Certs 信任锚轮换

Summary

一份处于早期阶段的个人互联网草案提出通过 /.well-known/company-certs 发布面向特定应用的私有 CA 信任锚，使应用无需把它们装进操作系统的全局信任库。
HTTPS 来源认证、X.509 路径有效与“选择 valid_from 最新的适用链”是三种不同判断；它们都不能证明组织内有权者已经批准换锚。在新旧链并存时，客户端的实际信任可能因此先于授权证据发生改变。
Daniel Kade 建议为每次实质轮换建立“信任锚变更凭据”，绑定精确元数据时期、新旧指纹、用途范围、重叠窗口、批准权限、本地策略、旁路佐证与回滚。这是编辑性治理建议，不是 IETF 要求。

不需要攻击者，问题已经成立

先设想一次完全正常的换锚。企业准备让旧私有 CA 退场，在几天内同时公布旧链与新链，好让各类客户端分批迁移。两条链都处于声明的有效期，服务对象与允许域名一致，新链的起始时间更晚。客户端按既定规则选中新链，可以减少人为歧义，也不必等待所有系统在同一秒切换。

这套流程有充分的工程价值。经过认证的来源比邮件附件可靠；显式用途比无边界导入安全；重叠窗口比突然替换更能保护可用性。但这些优点并不会自动产生组织授权。客户端能够证明“某个域名控制下的端点给了我这份对象”，却无法仅凭同一对象证明“PKI 负责人和应用所有者授权我信任其中这枚新锚”。

信任锚并非普通内容。它是路径验证的本地输入。被加入应用的锚集合后，原先不受信的证书链可能在规定用途里变为可接受。因而，谁能改变端点内容，谁就取得了一种改变应用权威边界的技术能力。治理问题在于，这项执行能力是否与批准能力严格重合。

草案给出的边界

draft-doehle-company-certs-discovery-00 是一份日期为 2026 年 7 月 22 日的个人互联网草案，拟进入标准轨道。截至本文截点，它只有 -00 版本，既不是 RFC，也不代表 IETF 共识，更不能证明已有任何生产部署。

草案把版本化 JSON 放在 /.well-known/company-certs。顶层包含权限信息与信任锚；每枚锚对应一个 usage_context，并可列出多条证书链。链条记录可以包含 valid_from、valid_until、同源 HTTPS 的 CA 链地址、PEM X.509 链、CRL 或 OCSP 位置，以及 SHA-256 指纹。

范围约束是设计的重点。permitted_domains 必须等于端点 TLS 证书中的某个 DNS 标识，或位于其子域之下；CA 链地址也要保持同源。isolated_store_required 则表达发布方要求应用单独保存该锚的意图。若客户端无法隔离，草案倾向于拒绝，而不是偷偷塞进更宽的信任库。

这不是把私有 CA 安装到操作系统全局根库的方案，也不取代 Web PKI，不负责签发终端证书，更不宣告某个私有 CA 对全世界都可靠。它的长处恰恰是局部化：让一款应用为一项明确关系取得所需信任材料，而不改变设备上所有其他 TLS 决定。

草案也准确限制了 HTTPS 能证明什么。服务器证书必须验证，来源控制因此构成发布权限；但它并不独立证明私有 CA 的质量、安全或运营可靠性。DNS、托管、内容分发、TLS 私钥、代码仓库、发布流水线与 PKI 管理在组织里可能由完全不同的主体控制。

域名不是组织授权图

RFC 8615 规定了 well-known URI 命名空间。它的安全分析提醒，能写入这类资源的主体，可能获得代表整个来源发言的能力。在共享托管、复杂权限或多条部署路径中，一项看似局部的写权限可能比管理员想象得更大。

这不是否定域名控制。域名能够给声明一个明确来源，也能把范围限制在可验证的命名空间。问题是不能让它越权代替组织图。Web 团队可能负责上线，网络团队控制 DNS，分发商负责边缘缓存，CA 团队制作证书链，应用所有者决定用途，风险责任人批准换锚。把这些角色都压成“公司发布了”，便失去了追责所需的结构。

RFC 9525 在 TLS 连接层提供了类似界线。客户端通过参考身份验证，确认呈现的 TLS 身份与它打算访问的名称相符。这能说明连接到了被该名称授权的服务器，却不是一份内部变更批准书。端点完全真实，变更仍可能缺乏正确授权。

自动化同样需要边界。流水线可以成为获准执行甚至获准审批的机制，但前提是其权限已经定义：能改哪些用途、允许哪组新旧指纹、是否必须等待第二证据、重叠能持续多久、谁能停止和回退。一次成功运行只能证明代码执行过，不能自行证明代码有权作出信任决定。

时间先后不是审批签名

当同一用途存在多条适用链时，草案要求忽略有效期外的条目，并在没有本地覆盖策略时，选取 valid_from 最晚的一条。这是明晰的选择规则，解决的是“客户端用哪条”，不是“组织为何批准这条”。

RFC 3339 有助于统一时间格式，却无法说明时间由谁设置、重叠窗口为何成立、两个部门是否共同同意切换。无论发布是正常、误操作还是被劫持，一个更晚的值都可以拥有完全正确的语法。

RFC 5280 的路径验证也不会补上这段授权。它把本地信任锚与策略当成输入，然后判断某条路径是否符合这些输入。验证成功说明证书链在给定信任基础上成立，不说明这枚锚为何进入基础。

所以，不能把“最新者优先”描述成设计缺陷。自动轮换必须有确定的选择办法。真正的错误，是把“客户端依策略选中新链”自动改写成“组织批准了新链”。前一句是技术事实，后一句需要另一条证据链。

隔离必须在运行中被证明

isolated_store_required 是发布方意图，不是技术强制。客户端需要判断自己的架构能否做到隔离；若不能，应拒绝信任锚。只检查 JSON 中存在一个布尔值，并不能证明责任已经完成。

审计要落到实际位置：锚被载入哪个存储，哪些路径构建器能够调用它，共享库是否把它暴露给其他应用，操作系统集成是否扩大了作用域。一次代码重构就可能让原本私有的集合被复用，而端点内容没有任何变化。

允许域名也有同样问题。解析器可以读到范围字段，验证器却可能忘记执行；缓存可以把两个用途混在一起；应用可能为便利而复用同一份配置。发布值只有与本地观察连接，才能成为控制证据。

“没有写入全局信任库”不应靠推断，而应靠抽样和验证。隔离是该机制最重要的安全承诺之一。一旦失守，局部发现协议就可能获得远超原设计的权威半径。

新鲜的 HTTPS 也可能承载过期授权

RFC 9110 与 RFC 9111 区分 HTTP 语义、缓存新鲜度和重新验证。草案建议保守缓存、定期重取、防止重放与陈旧元数据，客户端也可以设置自己的最长新鲜期。

这些机制回答“我看到的是不是足够新的来源表示”，却不回答“背后的批准是否仍然有效”。一项两小时应急批准可能比缓存先到期；安全团队可能撤回决策，而某个边缘仍提供旧时期；相反，刚从源站取得的新 JSON 也可能从未获得应用负责人的认可。

第一次成功取回尤其敏感。此前应用没有从这条渠道获得任何锚；此后它可能接受一批以前无法通过的证书链。草案也把首次获取视为敏感的引导事件。运营界面至少要区分首次加入、日常刷新、双链重叠、首选切换、旧锚删除与紧急回退，不能把它们都画成同一个 GET 成功。

请求本身还可能暴露客户端关注哪家机构、何种用途。减少无意义轮询能保护隐私和基础设施，但也使缓存期限成为信任政策。这个期限应由可接受的纠错时间决定，而不能只看流量成本。

证书状态无法替代换锚状态

元数据可以包含 CRL 与 OCSP 位置。RFC 6960 帮助依赖方查询证书状态，是证书生命周期的重要工具，却不能证明信任锚的引入过程。

新 CA 的下级证书可能全部“良好”，而新锚本身并未被正确批准；旧 CA 的路径可能继续有效，而组织原本已经决定退役。下级证书的状态不会重建谁发起换锚、用途有多宽、双链并存是否获准。

从端点删除错误条目也不是即时修复。缓存尚在，离线客户端尚未回来，既有会话可能不重建路径，锚还可能已被复制到别处。纠正方案需要列出受影响的客户端群、最大传播延迟、重新验证动作，以及隔离没有破坏的证据。

信任锚变更凭据

Daniel Kade 的建议是为实质性 Company-Certs 变更建立一份信任锚变更凭据。它不是要求公开 JSON 新增字段，也不是 IETF 规定，而是把发布事实、内部权限和客户端决定接起来的运营记录。

凭据首先冻结元数据时期：对象精确摘要、来源、已验证参考身份、取回时间、缓存与重验证状态。接着记录 usage_context、允许域名和隔离要求。这样，对某一摘要的批准不会自动延伸到端点几个月后发布的另一份对象。

随后要描述动作：旧锚和新锚指纹、链标识、valid_from、valid_until、重叠窗口和目标切换状态。新增、成为首选、删除和紧急回退是不同操作，不能都被一个“已更新”吞掉。

权限部分记录批准角色、政策或受限自动化，以及它实际授权的变更记录。无需把个人姓名、内部会议纪要公开到互联网；受保护的引用、签名决策摘要和可核验角色足以建立连接。关键在于，授权证据不能完全依赖执行发布的同一条路径。

客户端部分说明它采用默认最新规则还是本地覆盖，首次获取或根变化是否需要旁路佐证，能否落实隔离，何时必须重验证，端点不可达时如何处理。最后还要连接 CRL、OCSP、紧急删除、回滚资格、客户端类型、最大生效时间与关闭证据。凭据自身也应到期，避免旧批准给新状态续命。

佐证强度应匹配后果

低权限内部测试工具不必承受重型仪式。来源认证加上签名仓库审批，可能已经足够。若应用掌握签名、支付或基础设施控制权，组织则可要求不同管理域的第二把批准钥匙、双人控制或独立变更账本。

“第二渠道”不能只看数量。同一账号发出的确认、同一发布链上的另一 URL，都可能共享失败点。真正的独立性可以来自 PKI 控制系统、签名发布清单、受保护账本、硬件批准钥匙或另一管理域。

RFC 5011 只能作为有限比较。它在 DNSSEC 自动信任锚更新中使用加入、保持期和移除等状态，但不适用于 Company-Certs，也不是这里的规范来源。可借鉴的只有一条原则：当软件能够改变自己的信任基础时，过渡需要有记忆，不能只保留一个“当前值”。

保留每个动词的权限边界

这份早期草案不需要承担企业全部治理。它已经给出有用的工程结构：经认证来源、限定域名、应用用途、有效期、隔离意图。与无上下文发送 CA 文件或把私有根静默装进全局库相比，这是更清晰的起点。

治理层从协议证据终止处开始。现有来源没有证明任何具名部署、入侵、误轮换或采用率。开篇只是依据多链选择规则构造的边界测试，不是对现实企业的指控。

成熟做法不是把简单端点变成官僚系统，而是保留不同动词：HTTPS 认证“取回”，JSON 表示“元数据”，X.509 验证“路径”，本地政策“选择”适用锚，组织权限“批准”变更。变更凭据把它们连接起来，却不允许其中任何一个冒充全部。

Company-Certs 端点无法证明谁批准了信任锚轮换

为何重要

Summary

不需要攻击者，问题已经成立

草案给出的边界

域名不是组织授权图

时间先后不是审批签名

隔离必须在运行中被证明

新鲜的 HTTPS 也可能承载过期授权

证书状态无法替代换锚状态

信任锚变更凭据

佐证强度应匹配后果

保留每个动词的权限边界

资料来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报