摘要

  • Internet Security Research Group 运营 Let’s Encrypt，协调 Prossimo，运行 Divvi Up，并支持新兴的数字身份研究，使得一家小型非营利组织在多个关键的互联网信任层中发挥影响力
  • Let’s Encrypt 将免费证书、ACME 自动化、短有效期和开放基础设施相结合，使加密成为日常，同时将运营责任转向持续监控的续期系统
  • ISRG 的项目采用不同的经济模式：慈善资助支持公共服务，定向拨款资助更安全的软件，而 Divvi Up 在未成为传统商业供应商的情况下增加了付费隐私基础设施
  • 该组织的核心挑战在于机构规模：其服务远远超出其约 25 至 28 名员工的承载能力，使得资金来源、继任安排、事件响应和项目选择性成为互联网韧性的组成部分

一家在互联网规模运营的小型组织

Internet Security Research Group 并不完全符合公司、研究机构或行业协会的常见分类。它是加利福尼亚州一家具有联邦免税地位的公益公司，拥有一支分布式的员工队伍，以及一系列在浏览器、服务器、托管平台、网络路径、操作系统和应用遥测方面产生影响的在线服务和资助的工程项目。其对外宣传的组织网站使用了“A Better Internet”这一名称，但这是 ISRG 展示其工作的域名，而非一个独立的法律或运营实体。

规模不匹配是最有用的切入点。ISRG 的 2025 年年度报告列出了 25 名员工，而 2026 年 2 月的一篇文章则暗示约有 27.5 人（或等效的全职工作能力）。后者仅是非正式说明，而非正式员工人数，不应被视为确切的劳动力数字。与这一有限的人员基础相比，该组织报告了数以亿计的受保护网站、某些日子签发约一千万张证书的发放量、公共证书透明度日志、标准制定工作、内存安全项目以及一项隐私保护遥测服务。

这不仅仅是一个组织效率的故事。它涉及技术杠杆与机构集中化。软件、加密密钥、根存储库关系以及自动化协议，使得一个小型运营商能够将信任扩展到全球基础设施，而无需配备与传统公共事业相当的员工队伍。同样的架构也意味着，一个软件缺陷、资金短缺、政策失误或运行中断所波及的范围，可能远远超出该非营利组织自身法律和财务规模。

因此，评价 ISRG 必须同时从两个方向进行。它的成就在于，将以往昂贵、需人工处理或仅限于专家使用的功能，转化为普通运营商能够采用的日常基础设施。它所面临的风险则在于，维持这种简便性所需依赖的环节之多：浏览器、根项目、ACME 客户端、DNS、BGP、硬件安全模块、数据中心、承包商、捐赠方以及标准制定机构，都共同参与了 ISRG 无法独自控制的系统。

两项技术工作融合为一家机构

ISRG 并非由某位创始人单独创立，而是由两个相关工作的融合而来。在密歇根大学和电子前哨基金会，J. Alex Halderman 与 Peter Eckersley 致力于证书自动签发和续期。而在 Mozilla，Josh Aas 与 Eric Rescorla 则推动着一个免费自动化证书颁发机构的构想。这两个群体在 2013 年 5 月发现了彼此并联合起来，将协议与客户端方面的经验同浏览器、公钥基础设施和证书颁发机构的专业知识结合在一起。

法律沿革与更广泛的技术记录对创始经过的描述略有不同。ISRG 目前发布的组织材料将 Aas 与 Rescorla 列为创始董事，而 Aas 后来的回顾性叙述则将 Aas、Rescorla、Halderman 和 Eckersley 并称为创始团队。这两种表述均可保留，无需强求一致。Aas 与 Rescorla 组成了最初的法律董事会，而四人则共同构成了该机构诞生所依托的技术与组织联盟。

ISRG 于 2013 年 5 月 24 日注册成立，联邦免税资格自 2014 年 6 月起生效。Mozilla、EFF、密歇根大学、Cisco 和 Akamai 均作为赞助方或合作伙伴出现在创始记录中，但其角色各有不同。EFF 与密歇根大学贡献了协议和客户端方面的工作，Mozilla 带来了浏览器与 PKI 专业知识，Cisco 和 Akamai 则提供了资金、基础设施或运营支持。IdenTrust 后来提供的交叉签名关系，使得早期的 Let’s Encrypt 证书能够被广泛使用。

这种分散的起源奠定了 ISRG 此后持续运用的一种方法。该组织并不试图拥有其支撑系统所需的每一个组件，而是创建一个能够协调具备不同能力的机构的法律和运营大本营，筹集符合使命的资金，发布开放软件与标准，并对需要可问责服务提供商的部分进行运营。其结果在纵向整合上不如传统科技公司那样整齐划一，但它使得浏览器厂商、公民自由团体、学术研究人员、基础设施公司和独立维护者可以各自贡献，而无需其中任何一方成为整个系统的所有者。

非营利结构是信任模式的一部分

选择非营利结构，并不仅仅是一个筹资决策。公共证书颁发机构在互联网信任体系中占据着特权地位，因为浏览器和操作系统接受其签名，作为证书签发时服务器曾控制某个域名或其他经批准的标识符的证明。该运营商可以影响价格、访问权限、自动化程度、证书配置文件以及加密通信开放供使用的实际条件。

ISRG 的创始人认为，这一职能不应依赖于期待套现退出的股东，也不应依赖于提高证书价格的商业动机，或是围绕销售更高层级验证产品而构建的产品策略。他们同样希望避免任何一家企业母公司能够重新调整其使命，或将自动化保留为专有竞争优势。公益性质的结构使普及访问、开放标准与组织治理目标保持一致，而不是取决于一种暂时的亏本销售策略。

这种结构并未消除经济约束。Let’s Encrypt 证书对用户免费，但该服务仍然需要工程师、站点可靠性人员、法律与合规工作、审计、数据中心容量、硬件安全模块、验证基础设施、事件响应、证书透明度运营、软件维护以及筹资。非营利模式改变的只是谁为这些工作买单以及任何盈余可被如何利用；它并没有让这些成本消失。

非营利地位也未能消除治理风险。董事会仍要选择预算和战略方向，主要赞助方可能对财务稳定性变得至关重要，而根项目或 CA/浏览器论坛可能施加实质性改变运营的要求。小型高管团队也可能成为集中风险点。主要区别在于激励相容性：ISRG 没有传统的股东，不分配利润，且在法律结构上围绕公共利益构建，而非从证书用户身上创收。

这一制度选择后来成为 Prossimo 和 Divvi Up 的模板。这些项目并不共享单一的经济模式，但它们共享一个前提，即某些安全和隐私功能会创造广泛的公共价值，而不会产生直接的专有市场。ISRG 试图通过赞助、拨款、开源开发、直接运营，以及（在 Divvi Up 的情况下）通过付费服务使合同关系服务于使命，来弥合这一差距。

Let’s Encrypt 在建立自身信任之前需要借助他人的信任

建立一个证书颁发机构并不保证其证书有用。浏览器和操作系统必须已经信任签发链之上的某个根证书，而 2013 年或 2014 年的 ISRG 新根证书还没有安装基础。根证书纳入可能需要多年。创始人们曾考虑购买一个已建立的根证书，历史估价从 100 万美元到 800 万美元不等，但最终在 2014 年 10 月与 IdenTrust 签订了一项长期交叉签名协议。

交叉签名使得 Let’s Encrypt 的中级或根证书密钥能够出现在一个由设备已经信任的权威机构签发的证书中。然后，在 ISRG 自己的根证书进入主要信任存储之前，客户端可以构建一条通往 IdenTrust 被认可的根证书的链。这种安排弥合了技术上可用的 CA 与公共服务之间的鸿沟，同时揭示了 Web PKI 的一个永久特征：信任并非自我宣称。浏览器和操作系统程序制定政策、审核审计报告，并决定接受哪些根证书。

ISRG 于 2014 年 11 月 18 日公开宣布 Let’s Encrypt。Dan Jeffery 于 2015 年 4 月加入，成为首位全职员工，协助准备生产运营。第一张受浏览器信任的证书于 2015 年 9 月 14 日签发，公共信任里程碑于 10 月达成，而服务则在 2015 年 12 月 3 日正式对外开放。该服务在 2016 年 3 月签发了第一百万张证书，在 2017 年 6 月签发了第一亿张，并在 2020 年 2 月签发了累计第十亿张证书。

ISRG Root X1 被独立纳入主要信任计划，降低了对 IdenTrust 的依赖，但这并未结束对根治理的依赖。每一代新的根仍然需要完成纳入、约束以及在不同设备群体中的分发。较旧的设备可能不信任较新的根证书，这使得链的选择成为一个持续的兼容性问题，而非一次性的启动任务。

这段历史说明了为何 ISRG 既是一个运营者，又是一个生态系统参与者。它可以生成密钥、举行仪式、签发证书并发布政策，但它无法将根证书强制推送到数十亿设备中。信任源于技术控制、审计、公共规则以及独立平台的决策。这种分布式的权威限制了单方面控制，同时减缓了迁移速度，并引入了交叉签名复杂性，而这本身可能成为错误来源。

ACME 改变了证书管理的经济模式

Let’s Encrypt 最重要的创新并非孤立地提供免费定价，而是将免费证书与自动化证书管理环境协议（ACME）相结合。在自动化普及之前，服务器运营商可能需要购买证书，通过人工流程证明控制权，下载文件，安装证书，更新配置，并在续期时重复整个工作流程。即使证书本身价格不高，人工和风险也会使 HTTPS 的维护成本居高不下。

ACME 将这一生命周期转化为协议。客户端创建或使用一个账户，提交订单，完成验证挑战，发送证书签名请求，并接收证书。同一个客户端可以在到期前续签，并对更新的续期信息做出反应。托管公司、内容平台、Web 服务器、Kubernetes 系统和设备可以将签发集成到正常的部署流程中，而不是将其作为定期的人工项目来处理。

该协议被设计为开放式接口，而非 Let’s Encrypt 的私有 API。当 ACME 在 2019 年 3 月成为 RFC 8555 时，其他公共和私有的证书颁发机构都可以实施它，同时客户端也能够支持多个提供商。这种分离具有战略意义。Let’s Encrypt 受益于不断增长的客户端和集成生态系统，而无需拥有每一个客户端。Certbot、Caddy、服务器原生模块、云服务以及证书管理系统都可以将这一标准转化为适配各自操作环境的形式。

自动化也改变了可行的证书有效期。当续期需要人工发单时，90 天的证书没有吸引力；当续期由一个持续监控的软件流程完成时，它却变得易于管理。在高度自动化的基础设施中，6 天的证书对多数人工使用者而言几乎无法工作，但已成为可能。因此，ACME 的作用不仅仅是降低管理成本：它还促成了基于频繁重新验证和替换的风险模型。

ISRG 的 2025 年年度报告称，受保护网站的数量从约 4.92 亿个增加到 7.62 亿个，某些日子的签发量达到约一千万张证书。这些是组织定义的指标，而非独立普查，且证书并不等同于独立的网站、服务或用户。即便有此限制，这些数字表明证书管理已从专业采购转变为托管和应用部署中的一项后台功能。

Boulder 将面向互联网的工作与签名权限相分离

Let’s Encrypt 背后的软件称为 Boulder。它是 ACME 证书颁发机构的一个开源实现，但将其描述为 Web 应用程序不足以说明其安全问题。公共 CA 必须接收来自互联网的不受信任的请求，同时防止请求处理代码的入侵变成对签名密钥的直接访问。因此，Boulder 将签发路径划分为具有不同权限和责任的组件。

简化的流程始于 ACME Web 前端，经注册和订单处理，调用验证权限，执行策略和 CA 授权检查，获取证书透明度承诺，并请求 CA 层进行签名。存储、吊销、速率限制、审计日志、ACME 续期信息、证书吊销列表生成以及其他支持功能保持分离。这些边界隔开了面向互联网的代码、决策服务以及被允许请求加密签名的系统。

根密钥材料保持离线。在线的签发中间证书使用受硬件安全模块保护的密钥。离线根证书建立了长期信任，而中间证书承载日常签发工作，并可被替换或吊销，而无需替换整个根证书。ISRG 在 2019 年技术说明中表示，站点可靠性工程师历来是唯一能够直接访问证书签发系统的人员，这表明组织访问控制如何与软件架构相辅相成。

开源代码提供了审查和复用的可能，但它不能替代安全运行。其他组织可以检查 Boulder 或使用其部分内容，但 Let’s Encrypt 的安全性还依赖于密钥仪式、物理控制、HSM 配置、部署实践、数据中心冗余、监控、人员流程以及审计证据。代码描述了相关机制；而受信任的状态则取决于围绕它们的整个系统。

2025 年 7 月发生的全面 ACME 故障暴露了组件隔离的局限。一次解析器升级脚本在数据中心之间创建了循环或不可达的转发依赖，而同样的 DNS 问题也影响了监控和诊断。故障持续了近八个小时。签名密钥没有被泄露，但一个共享依赖瓦解了地理冗余，这表明韧性所需的控制、可观测性和恢复路径，不能通过同一服务失效而产生。

域名验证证明的是控制权，而非合法性

Let’s Encrypt 签发的是域名验证证书。证书确认的是申请人根据适用的验证规则，证明了其对某个域名（或对于较新的短时效配置文件，对某个 IPv4 或 IPv6 地址）的控制权。它并不证明该运营商是一家合法的企业，该网站是安全的，某个商标属于证书持有者，或控制权在签发后将保持不变。

随着 HTTPS 接近普及，这一区分变得更加重要。用户通常将浏览器锁图标理解为安全判断，但传输层安全协议主要保护的是连接并对端点标识符进行认证。一个钓鱼网站可以控制域名并获取有效的 DV 证书。Let’s Encrypt 的使命是消除加密的成本和摩擦，而不是创建全球性的企业身份或内容审查系统。

常见的 ACME 挑战反映了不同的部署环境。HTTP-01 要求申请者将一个令牌放置在指定的 Web 路径下。DNS-01 使用_acme-challenge下的 TXT 记录，这使得通配符证书的签发成为可能，但通常需要访问强大的 DNS 凭据。TLS-ALPN-01 在 TLS 握手期间使用一个特殊的证书。IP 地址证书将经批准的方法应用于字面地址，并被限制在短时效配置文件中。DNS-PERSIST-01 是一种新兴模型，用于建立持久的、与帐户绑定的 DNS 授权，而非每次签发都使用新令牌。

每种方法都转移了风险。Web 验证依赖于路由、托管和请求处理；DNS 验证依赖于权威 DNS、API 凭据和传播；TLS 验证依赖于正确的服务隔离。持续的授权可以消除续期系统中例行性的 DNS API 访问，但它增加了 ACME 账户密钥和持久记录的重要性。CA 根据既定协议证明控制权；它无法消除围绕该证明的所有可能的入侵路径。

这种狭义范围是 Let’s Encrypt 能够在全球范围内运行的原因之一。组织验证和扩展验证需要关于法律身份和权限的不同证据，ISRG 选择不提供这些产品。由此形成的服务在功能上有意受限，但高度易于访问，为庞大的人群保护了传输层，同时将声誉、企业身份和应用安全留给了其他系统。

验证已超越单一网络视点的局限

如果证书颁发机构仅从一个网络位置进行验证，那么当攻击者转移了其所在 BGP 路由或沿该路径操纵 DNS 时，就可能被欺骗。Let’s Encrypt 在 2020 年开始结合普林斯顿大学的研究支持，实施多视角验证。QA 并非信任单一观察，而是要求位于不同网络位置的验证器在签发前共同确认控制权。

行业要求后来正式确立了这一方法。从 2026 年 6 月开始，CA/浏览器论坛规则要求至少四个远程视角，并保证相互印证的视角跨越至少两个区域互联网注册管理机构服务区域。因此，Let’s Encrypt 的验证系统在设计上和政策上都实现了地理位置和拓扑分布的多元化。

多视角验证改变了攻击者面临的问题，因为一个局部的路由劫持可能骗过某个视角，却不一定能骗过远程网络。但这并不使欺诈性验证变得不可能。大范围的路由攻击、权威 DNS 入侵、相关的云故障或验证实现缺陷，仍可能影响多个视角。只有当验证器之间不存在隐藏的依赖关系时，多样性才能带来帮助。

CAA 和域名系统安全扩展（DNSSEC）增加了不同的控制层。CAA 记录允许域名指明哪些证书颁发机构可以为其签发证书，而 DNSSEC 则可以为签名的 DNS 响应提供完整性保证。从 2026 年 3 月 15 日起，公共 CA 的要求规定，主视角域名验证和 CAA 查询必须进行 DNSSEC 验证，且 DNSSEC 失效不能再被视为可以继续签发。

2020 年的 CAA 事件说明了某项控制的价值如何取决于正确的实现。在某些多域名订单中，Boulder 重复检查了同一个名称，而非检查每个必需的名称。约有 300 万张证书被确定为潜在受到影响。该故障并未使 CAA 失效，而是暴露了规则应用过程中的软件缺陷。在 Web 规模下，一个小小的索引或循环错误，就可能演变成涉及大规模替换与合规的事件。

因此，证书安全超出了 CA 本身的范围。它取决于互联网在网络间呈现一致的标识符视图的能力，以及 CA 能够识别差异的能力。Let’s Encrypt 的验证架构将 PKI 与路由、DNS 以及更广泛互联网的运营多样性直接联系在一起。

新世代 Y 通过又一层兼容性重建信任

Let’s Encrypt 的层次结构将根证书与签发用中间证书分开，并使用 RSA 和 ECDSA 两种系列。已建立的根包括 ISRG Root X1 和 ISRG Root X2。2025 年 9 月，ISRG 生成了新的 Generation Y 根证书（YE 和 YR），随后又宣布了另一组中间证书。截至 2026 年 7 月，YE1 和 YE2 是活跃的 ECDSA 中间证书，YR1 和 YR2 是活跃的 RSA 中间证书，YE3 和 YR3 作为备份保留。

截至 2026 年 7 月 8 日，新的根证书尚未广泛存在于主要信任存储中。因此，默认的证书链继续通过已建立的 ISRG X 根证书使用交叉证书。这使得新的层次结构能够在独立的信任分发持续进行的同时运作，但每张交叉证书都成为又一个策略对象，其扩展、有效性、吊销和路径构建行为都必须正确无误。

代际更迭不可避免。根证书和中间证书的寿命有限，密码学偏好会演变，密钥仪式或运营边界也需要更新。新的层次结构可以引入更新的算法、配置文件以及更长的规划期。但它也揭示了浏览器策略、操作系统信任存储、嵌入式设备和交替链选择行为之间的差异。

因此，证书层次结构是一种兼容性策略，而不是一张静态的证书列表。现代的客户端可能偏好较短的 ECDSA 链，而较旧的平台则可能需要一条经由广泛部署的 RSA 根证书的路径。ACME 客户端和服务器可能会遇到具有不同结果的备用链。CA 必须在加密技术的现代化与确保一条有效链不会对大量设备群体失败之间取得权衡。

ISRG 的链文档作为一种当前的运营来源，而非历史参考。固定使用中间证书或假定链长度不变的运维人员，可能在过渡期间遭遇破坏。预期的模型是信任合适的根证书，并允许正常的路径构建，但嵌入式软件和旧版平台并不总能表现理想。Generation Y 证明了，长期的公共信任是如何通过较短的运营决策被反复重建的。

一个缺失的限制引发了公共合规事件

Generation Y 的推出在 2026 年 5 月引发了一起合规失败。创建的交叉认证下级 CA 证书缺少了必需的serverAuth扩展密钥用法限制。这一缺失影响了将新层次结构连接到现有受信根证书的证书，而非订户密钥的加密强度。

Let’s Encrypt 停止了受影响证书的签发，创建了替换用的交叉证书，并吊销了有缺陷的证书。它还使用 ACME 续期信息（ARI）鼓励那些可能受影响的证书链的订户获取替换用的终端实体证书。该组织认为，订户证书本身无需吊销，因为缺陷存在于下级交叉认证的配置文件层面，并可通过链替换予以解决。

这一事件的意义不仅在于一个扩展项的缺失，还在于它揭示了兼容性机制如何扩大合规面。一张根证书、一个中间密钥、一张自签证书以及多个交叉签名的形式，可能代表相关的密钥身份，却承担着不同的策略限制。适用于路径中某一位置的配置文件，在另一位置可能不合规。

该事件的响应也表明了，在事件发生前就已发展的自动化所产生的价值：ARI 能够提前发出续期信号，ACME 客户端无需再次购买流程即可获取替换证书，而新证书链能够快速分发。使该错误后果严重的运营规模，同样也使得广泛的技术补救成为可能。

自动化无法消除对判断的需求。Let’s Encrypt 仍需要决定哪些对象需要吊销，依赖方将如何构建路径，订户证书是否仍可接受，以及过渡应以多快速度完成。一刀切的响应可能造成不必要的服务中断，而响应不足则可能使不合规的证书链继续在服务中运行。这一层面的应急处理，需要在加密有效性、正式规则、浏览器行为以及服务连续性之间取得平衡。

有益的经验并非 Generation Y 失败，或交叉签名本质上不可靠，而在于公共信任的迁移必须作为一个运营计划来管理，包含分阶段的签发、备用链测试、ARI 就绪、明确的封闭证据，以及对每个证书形态如何受到限制的清晰说明。

短有效期证书将风险转移至自动化系统

Let’s Encrypt 于 2026 年 1 月 15 日全面开放了六天有效期的证书以及 IPv4 和 IPv6 地址证书。短时效配置文件的有效期为 160 小时，IP 地址证书也必须采用该配置文件，因为地址可能比许多域名更易被重新分配或变更运营控制权。频繁的验证缩短了过期控制权仍可被认证的时间窗口。

较短的证书降低了因密钥或错误签发而产生的最大暴露窗口，但它们将更多风险转移到了续期系统上。一张 90 天有效期的证书为运营人员提供了数周时间来检测故障流程；而一张 6 天有效期的证书可能在几天内演变为服务中断。因此，相关的安全系统包括客户端调度、账户密钥保护、挑战可用性、速率限制规划、安装、服务重载以及对实际呈现给用户的证书的监控。

可选的tlsserver配置文件于 2026 年 5 月转为 45 天有效期，而在研究截止时，默认的classic配置文件保持为 90 天。Let’s Encrypt 计划于 2027 年 2 月将默认有效期降至 64 天，并于 2028 年 2 月降至 45 天。此外，CA/浏览器论坛要求将公开受信的 TLS 证书最大有效期自 2029 年 3 月 15 日起降至 47 天。这些是计划的过渡时间点，并非对所有证书都已是完成的事实。

这一变化改变了 CA 与用户之间的关系。续期不再是由每个客户端独立选择的定期操作，而是成为了一种持续流，CA 可能需要随时间分配该流量，并在事件期间重定向。因此，用户系统必须将 ACME 账户状态、续期逻辑和证书部署视为生产控制平面来对待。

IP 证书拓宽了自动化公共信任的用途。没有稳定 DNS 名称的基础设施端点、网络设备以及某些服务发现环境，可以对字面地址进行认证。这一功能直接明了，但该地址必须保持可控，并且在验证过程中能够反复访问。它使公钥基础设施对基础设施运营商变得更加有用，同时强化了身份应当在运营控制权变更时得到刷新的原则。

ARI 将续期转化为协同的控制系统

ACME 续期信息（ARI），于 2025 年 9 月作为 RFC 9773 发布，为证书颁发机构提供了一种建议客户端何时续期的方式。CA 可以发布一个起始和结束窗口，分配日常的续期负载，并指示某些受影响的证书应在吊销前提前更换。Let’s Encrypt 此前已经在服务端实现了该草案，并利用运营经验帮助形成了最终标准。

ARI 将续期从纯客户端的定时器转变为共享的控制平面。没有 ARI，数百万客户端可能会在证书寿命的固定比例处同时续期，产生可预测的流量尖峰。在应急情况下，CA 可以吊销证书，但除此之外无法保证每个用户提前更换了证书。知晓 ARI 的客户端使顺序响应成为可能：获取新证书，部署它，验证它，然后让旧证书被吊销或过期。

该扩展并不完成最终的部署路径。客户端可以请求替换证书，但仍可能无法写入文件、更新负载均衡器、重载 Web 服务器，或检测到旧节点仍在运行。客户端的采纳程度也各不相同。因此，ARI 的实际价值取决于整个用户系统的实施情况，而不仅仅是对 CA API 的支持。

DNS-PERSIST-01 旨在应对另一项自动化风险。传统的 DNS-01 续期通常向 ACME 客户端授予能够修改权威 DNS 的凭据，因此续期主机的入侵可能导致域名的入侵。这项被提议的持续验证挑战使用一条与 CA 标识符和特定 ACME 账户绑定的持久记录，并带有可选的通配符范围和过期时间。这样，例行续期可以在不必反复暴露广泛的 DNS API 凭据的情况下进行。

这种方法将信任进行了转移，而非消除。ACME 账户密钥变得更强有力，且持久记录必须保持正确。在研究截止时，该方法仍是一项 IETF 草案。Pebble 支持实验，且 Let’s Encrypt 已描述了预发布环境和生产计划，但未找到关于已完成生产部署的明确官方公告。因此，它应被视为一种新兴的控制手段，而非一项通用的当前功能。

综上所述，ARI 和 DNS-PERSIST-01 表明，证书管理正在超越签发本身，迈向持续授权。困难之处在于：谁可以续期、何时续期、如何保护凭据，以及 CA 如何在应急情况下引导分布式的客户端群体，而无需对每个用户的部署系统负责。

终结 OCSP 简化了一层，并使另一层变大

Let’s Encrypt 于 2025 年 8 月 6 日终止了其在线证书状态协议服务。该服务在高峰期每月处理约 3,400 亿次请求。这一体量产生了巨大的基础设施成本，而每次查询都可能泄露客户端的 IP 地址以及被检查证书的网站。ISRG 认为，运营和隐私方面的负担已不再合理。

该服务现通过证书吊销列表（CRL）发布证书吊销信息。CRL 可以被缓存和批量分发，避免了向 CA 进行逐访客查询。它们简化了签发方的在线架构，并适用于浏览器生态系统中平台方越来越多地通过自身系统聚合或分发吊销数据的现状。

取舍在于新鲜度和依赖方行为。列表可能很大，客户端需要获取并处理它们，而不同平台可能以不同间隔进行更新。终结 OCSP 并未使吊销变得不必要，而是改变了分发机制，并将更多责任转移给了使用这些列表的浏览器和操作系统。

Let’s Encrypt 更广泛的策略也通过缩短有效期和快速续期来减少对吊销的依赖。一张被入侵的 6 天有效证书的固有暴露窗口，比一张 90 天证书的更短；而 ARI 则能鼓励在吊销前进行替换。过期仍然不是即时响应，而某些事件也无法等待。因此，吊销仍然是必要的，即便它是一个不完美的层级。

此前的大规模事件表明了正式期限与服务连续性之间的冲突。2020 年，CAA 漏洞可能影响约 300 万张证书，Let’s Encrypt 推迟了逾一百万张剩余证书的即时吊销，以避免突然破坏大量网站。2022 年 1 月，一个 TLS-ALPN 验证错误导致了约 270 万次吊销。合规、降低风险和可用性三方面并未指向一个简单的答案。

终结 OCSP 应被理解为架构层面的简化，而非状态管理的终结。该系统现在更依赖于 CRL 分发、平台集成、短有效期以及协同续期。其表现是否更好，取决于完整的依赖方生态系统，而非仅仅 CA 请求量的减少。

Sunlight 使透明度运行成本更低

证书透明度要求公开受信的证书被提交到仅追加的日志中。这些日志使域名所有者能够监控签发，使浏览器能够要求证书已被日志记录的证据，并为研究人员提供用于检查误发和 PKI 行为的公共数据集。Let’s Encrypt 自 2019 年起运营公共 CT 日志，这使得 ISRG 既是一个重要的证书签发方，也是另一层信任基础设施的运营者。

传统的 CT 系统通常依赖基于数据库的读取 API，这需要存储、查询能力、一致性控制和大量的运营支持。Let’s Encrypt 在 2024 年 3 月推出了 Sunlight，作为一种静态分片架构。默克尔树以文件或对象的形式表示，这些文件可被放置在对象存储中，由内容分发网络缓存、压缩并独立镜像。

写入路径被有意简化。单个写入者使用比较并交换保护来推进检查点。Let’s Encrypt 的设计论点是：CT 已经要求证书被提交到多个独立的日志，因此生态系统的冗余度可以替代将每个日志都变成复杂的分布式数据库的做法。如果一个日志失败，其他日志可继续提供包含服务，而失败的服务可以从较简单的状态中恢复。

这体现了 ISRG 工程方法的特点：使用加密数据结构和独立运营者来降低每个服务的复杂性。该设计并不保证每个静态分片日志都会被所有浏览器项目接受，也不保证所有故障模式都会消失。日志项目仍会评估密钥管理、运营方行为、最大合并延迟、监控和可用性。

Sunlight 还回应了该组织在经济方面的限制。一个免费的证书颁发机构可以通过简化相邻的公共基础设施来降低成本，而不是不断扩大服务集群。静态对象更容易被缓存、镜像和检查。若该设计在 Let’s Encrypt 之外被采用，它可能降低更多日志运营者的进入门槛，并增加多样性。

因此，战略检验的标准是采用情况，而非架构的优雅。只有当浏览器项目、其他 CA、监控方和独立运营者在生产中使用 Sunlight，而无需重新创建另一个隐藏的中心依赖时，它才真正成为公共基础设施。

默克尔树证书提出一条不同的后量子路径

后量子签名给 Web PKI 带来了一个大小问题，因为设计用于抵抗未来量子攻击的算法，通常使用比当前 ECDSA 或 RSA 系统更大的公钥和签名。在传统的 X.509 链中替换每一个签名，可能会增大 TLS 握手负载，从而在数十亿连接上增加带宽和延迟。

2026 年 6 月，Let’s Encrypt 宣布了一项以默克尔树证书（Merkle Tree Certificates）为核心的计划。证书颁发机构不再使用足够大的后量子签名对每张证书单独签名，而是可以将多张证书放入一棵默克尔树中，对一个公共检查点进行签名，并为每张证书提供一个紧凑的包含证明。该模型可以在将透明度集成到签发结构中的同时，减少重复的签名开销。

该路线图的目标是在 2026 年底进入预发布环境，并在 2027 年具备生产环境。这些都是计划，而非已完成的部署。在研究截止时，普通用户仍继续收到传统证书，而浏览器支持、协议标准化、客户端行为以及互操作性仍然是外部依赖项。

MTC 表明，ISRG 准备质疑现有 CA 周围的格式，而不仅仅是在其内部替换算法。直接的后量子替换可能保留传统的 X.509 语义，但会施加持久的大小代价。基于树的系统则改变了签发、证明分发和依赖方验证的方式，这使得过渡需求更高，但可能带来更优的网络经济。

主要风险在于协调。一种证书格式只有当服务器能够获取并呈现它，浏览器能够验证它，标准机构能够规范它，且回退行为不会引入降级或兼容性问题时，才是有用的。传统的 X.509 和新机制可能需要共存多年，这将为本已复杂的信任体系增加另一个部署和链选择的问题。

ISRG 的运营规模为其带来了优势，因为它可以对照真实的签发模式测试提案，并构建预发布基础设施。但其权限仍然是有限的，因为它无法仅凭公告就让整个互联网采用 MTC。该计划取决于浏览器、服务器、标准机构和密码学社区之间的独立共识。

事故揭示了规模和学习模式

Let’s Encrypt 的历史中包含了若干事故，这些事故如同其增长一样清晰地界定了其边界。TLS-SNI-01 于 2018 年 1 月被禁用，原因在于共享主机行为造成了未经授权的验证路径。2020 年 2 月的 CAA 重复检查漏洞导致了一次大规模的替换和吊销行动。2022 年 1 月的 TLS-ALPN 验证错误引发了约 270 万次吊销。2025 年 7 月，一个 DNS 依赖关系导致数据中心间的 API 全面中断近八个小时。Generation Y 的交叉证书因缺少 EKU 限制，不得不在 2026 年 5 月被替换。

这些事件本身并不足以说明 Let’s Encrypt 特别不可靠。以如此的规模运营一项服务，必然会暴露罕见的交互行为，并受到来自根项目和研究人员的高度审视。更相关的检验标准在于该组织如何检测、披露、遏制并从失败中学习。

记录表明，该组织反复发布了事故详情，暂停了受影响证书的签发，提供了替换工具，并调整了架构或流程。同时，也表明正式的合规要求与运营连续性之间可能出现冲突。立即吊销可能满足时限要求，却破坏了那些尚未续期的运营者的服务；而推迟吊销可能保持了可用性，却使潜在受影响的证书保持有效并引起审查。

自动化放大了后果和恢复两个方面。一个缺陷可能影响数百万张证书，而同一套自动化机制又可能比人工系统更快地替换这些证书。ARI 的研发部分源自于在规模化场景下协调替换的需求。多视角验证和 DNSSEC 要求则体现了对网络路径和 DNS 行为可能破坏证书验证的认识。

因此，专业使用者不应将 CA 视为唯一责任方。运营者需要续期监控、最新的客户端、经过测试的故障转移、可靠的联系方式以及对事故渠道的知晓。根项目需要相称的规则和证据，而 ISRG 需要保持即使共享依赖失效仍可用的监控与恢复系统。公共信任是通过可见的失败与减少的重现次数来维持的，而非基于事故可以被消除的假设。

Prossimo 为从更安全的代码到被采用这一艰难路径提供资金

Prossimo 应对的是另一类基础设施风险：用不强制内存安全的语言编写的软件中的内存损坏问题。数十年来，使用后释放、缓冲区溢出和无效指针访问等问题，一直影响着 TLS 库、DNS 软件、操作系统、权限管理工具和编解码器。重写关键组件可以减少这类缺陷，但这项工作成本高昂，而共享这些受益方往往缺少为之提供资金的单一动力。

ISRG 董事会在 2020 年 12 月 9 日批准了内存安全项目，Prossimo 于 2021 年公开成立。该计划并非雇用一支核心团队来重写互联网，而是识别重要组件，定义一项倡议，筹集专项基金，与维护者或专业工程公司签订合同，支付审计与工具费用，支持打包与兼容性，并尝试将成果推向实际部署。

运营模式至关重要，因为技术完成并不等同于被采用。一个 Rust 实现可能是内存安全的，但同时缺乏现有应用程序所需的 API；其性能可能不同，可能需要 C 接口，需要打包，或在受限环境中失败。因此，Prossimo 资助了原型到成为默认基础设施之间那些不引人注目的工作：兼容层、基准测试、安全审计、no_std操作、分发集成以及维护者的移交。

该计划通过一个广泛的网络运作。资助方包括 AWS、Sovereign Tech Agency、Alpha-Omega、Google、Cisco、Cloudflare、Shopify、ICANN 等。承包商和合作伙伴包括 Ferrous Systems、Tweede Golf、Rust 基金会和 Trifecta Tech 基金会。这些关系并未使 ISRG 成为每个产出的项目的所有者。版权、治理和维护权可能仍属于独立社区，或转移至专业基金会。

理解 Prossimo 的最佳方式是将其看作一个采纳引擎。它将资本和协调力量集中到那些分散的受益方难以资助的通用基础设施上。衡量其成功的标准应当是：实现是否被审计、打包、部署、维护，并最终被视为常规选择，而非以宣布的倡议数量来衡量。

Rustls 展示了为何更安全的代码仍需兼容性工程

Rustls 是 Prossimo 最成熟的倡议之一。它是一个用 Rust 编写的 TLS 实现，旨在提供内存安全的同时满足现代的加密与运行要求。仅有原生 Rust API 不足以替代成熟的库，因此相关工作包括了 C 接口、OpenSSL 兼容层、异步支持、no_std和零分配模式、具备 FIPS 能力的加密选项，以及后量子密钥交换。

每项能力都针对不同的采纳障碍。C 兼容性允许现有软件无需用 Rust 重写即可使用该库。OpenSSL 兼容性针对的是假定使用熟悉 API 的应用程序。no_std适用于没有完整操作系统标准库的环境，而零分配工作服务的是受限系统。FIPS 支持对受监管的部署至关重要，性能工程则回应了那些不愿为理论上的安全性承受重大基础设施性能损失的运营者。

Prossimo 发布了有利的基准测试，但结果应被保留性地引用，而非视为普适的证明。TLS 性能取决于算法选择、硬件、记录大小、并发性、会话重用和应用集成。一个库在某一项测试中领先，却可能在别处遇到兼容性或运营限制。

治理过渡与代码同等重要。2025 年，Rustls 成为 Rust 基金会创新实验室中首批托管的项目之一。这一举措可能为其提供一个超越一系列 ISRG 合同的持久归属地。它反映了 Prossimo 所期望的生命周期：资助缺失的工作，降低采纳障碍，然后将管理职责移交给维护者和用户能够继续推进的地方。

Rustls 表明，内存安全既是一个语言选择的问题，也是一个制度性问题。实现本身必须可信，但周围的生态系统必须能够采纳它。Prossimo 资助那些将更安全的库转化为实际基础设施选项所需的接口、审计、组织关系和部署证据。

生产环境中的采用将成熟工作与受资助的雄心区分开来

最清晰的 Prossimo 成果是那些已经通过开发进入生产环境的项目。ntpd-rs倡议资助了一个内存安全的网络时间协议实现，具备服务器、客户端和网络时间安全支持。它经过了外部审计，移交至 Trifecta Tech 基金会进行管理，获得了 Fedora 和 Ubuntu 的软件包，并于 2024 年 6 月进入 Let’s Encrypt 的基础设施。

这一系列步骤之所以重要，是因为时间同步是证书、日志、认证和分布式系统的一项隐性依赖。只有当运营者信任其精确性、能够通过常规软件包安装它并愿意运行时，一个新的守护进程才变得有用。通过部署ntpd-rs，ISRG 成为了它所资助的安全工作的采纳者，而不仅仅是拨款的管理者。

sudo-rs提供了一个发行版级别的例子。Canonical 已将其作为 Ubuntu 26.04 LTS 中的默认 sudo 实现，同时保留原始实现作为兼容性回退。这是有力的采纳证据，但并非完整功能对等的证明。回退机制承认，成熟的工具积累了插件、工作流程和未记录的边缘情况，替代品尚未能复现。

Linux 内核中的 Rust 支持（于 2022 年被合并，并得到相关资金支持）是一个更广泛的生态里程碑。它允许部分驱动和模块用一种内存安全的语言编写，而无需替换现有的 C 代码。益处在于前瞻性：新组件可以避免某些类别的内存错误，同时仍是一个大型遗留系统中的一部分。

Hickory DNS 仍是一个较为谨慎的案例。该项目正在用 Rust 开发一个高性能的递归解析器，具备 DNSSEC、NSEC3、机会性加密、审计和生产就绪性方面的工作。Prossimo 已描述了为 Let’s Encrypt 查询量所做的准备，但在截止时尚未验证已完成迁移。一个受资助的实现、一次审计、一份部署计划以及一个处于运营状态的服务，仍然是独立的证据阶段。

这些项目共同定义了 Prossimo 试图标准化的采纳阶梯：构建、审计、打包、在苛刻的环境中部署、移交管理权，并使更安全的组件成为带有受控回退的默认选项。该计划的长期价值，取决于它能否比宣布新的重写项目更频繁地重复这一进程。

内存安全缩小了一类故障

内存安全的语言能够通过使不安全的状态难以或无法在普通代码中表示，来防止许多无效访问、释放后使用和缓冲区错误。在处理攻击者控制的输入的基础设施解析器和协议引擎中，这种减少尤为宝贵。

内存安全并非完整的软件安全。一个 Rust 实现仍可能包含逻辑错误、密码学误用、拒绝服务弱点、不安全的代码块、不良的依赖选择、权限错误或互操作性缺陷。重写可能在消除旧有错误类别的同时引入新行为。审查、模糊测试、审计、可重现构建、依赖治理以及谨慎的迁移仍然是必要的。

兼容性造成了另一风险源。成熟的 C 组件通常展现出的行为，有数十年之久，并未完全记录在其正式接口中。应用程序可能依赖于那些替代品未能重现的错误代码、时序、配置语法或插件约定。一个在理论上正确但在操作上不兼容的内存安全实现，可能无法获得采纳，或在迁移中造成服务中断。

Prossimo 的计划设计通过资助 C API、OpenSSL 兼容性、打包和分阶段过渡为默认选项，承认了这一点。这也引发了一个经济问题：生态系统应在何时资助一次重写，而非继续加固现有代码？答案取决于漏洞历史、维护者能力、接口稳定性，以及新实现是否能够吸引持久的管理。

其项目组合包括：Rustls、Hickory DNS、sudo-rs、su-rs、ntpd-rs、rav1dAV1 解码器、内存安全的 zlib 工作、用于 Linux 的 Rust、River 反向代理、Apachemod_tls以及选定的 curl 工作。成熟度差异很大，将这些项目放在一起列出并不意味着它们都处于生产就绪状态或由 ISRG 管理。

合理的评价是：Prossimo 已建立起一种可重复的融资与采纳方法，但并不能保证内存不安全的代码将消失。它的贡献在于，将一项总体性的政策偏好转化为具有维护者、审计、接口和部署目标的项目。最终的结果将在今后几年的默认选择、软件包使用、连续性和漏洞暴露中显现出来。

Divvi Up 避免收集其不需要的明文

Divvi Up 应对的是传统遥测带来的隐私成本。大多数分析系统将单个事件发送给一个组织，该组织存储明文记录，日后再计算聚合值。即便期望的结果只是一个简单的计数或求和，收集方收到的数据集也往往比最终需要回答的问题更丰富。

Divvi Up 改变了这一架构。客户端使用一种可验证的分布式聚合函数将一个测量值拆分为多个加密份额。一个份额发给主聚合器，另一份发给助手。两台服务器都不会收到明文的原始测量值。它们各自计算一个部分聚合结果，然后由一个收集方合并这些部分结果，以获得整个总体的统计值。

隐私保障依赖于机构分离。如果至少一个聚合器行为诚实，且两者不共谋，那么任何一方都无法从自己的份额中重构出单个测量值。如果两者共谋，或一个组织实际上控制了两者，其主要假设便告失效。因此，Divvi Up 将组织上的独立性作为密码学设计的一部分。

ISRG 于 2020 年 10 月批准了该项目，并于 11 月宣布了 ISRG Prio Services。其首次实际应用是在 2020 年 12 月，为新冠疫情暴露通知系统提供私有分析。该服务于 2021 年 12 月更名为 Divvi Up，随后扩展至浏览器、人权和应用程序遥测等领域。

这一模型与 Let’s Encrypt 不同。证书用户不向 ISRG 付费，而 Divvi Up 邀请组织讨论付费试点和生产服务。该产品结合了开放协议、开源的 Janus 实现，以及由一个非营利组织运营的聚合器，并附以商业关系。这笔收入可以支持其使命，但也会产生对可靠性、数据治理、服务水平以及客户支持方面的期望。

Divvi Up 的主要主张并非数据收集变得无风险，而是应用程序可以提前决定需要哪个聚合值，并避免构建一个存放单个明文测量数据的中央仓库。这种约束减少了未来分析的灵活性，但也消除了一个重大的隐私和泄露风险源。

隐私取决于完整的部署，而非某个协议

Divvi Up 结合了多个分别解决不同问题的层次。可验证分布式聚合函数定义了如何对测量值进行拆分、验证和聚合。Prio3 支持常规的计数、求和与直方图，而其他函数族则针对更专门的任务。验证之所以重要，是因为不应让恶意客户端提交损坏最终聚合值的畸形数据。

分布式聚合协议（DAP）协调了报告上传、聚合作业、主聚合器与助手之间的通信、收集以及错误处理。在研究截止时，DAP 是 2026 年 7 月 6 日发布的草案第 19 版，而 VDAF 是 2026 年 6 月 24 日发布的 IRTF 草案第 20 版。这些都是活跃的标准工作，而非最终的 RFC，因此在二进制格式和语义上仍可能继续变化。

Janus 是 ISRG 的 DAP 的 Rust 实现，并为 Divvi Up 提供动力。它仍处于活跃开发中，支持带有平凡聚合参数的 VDAF，包括 Prio3。它不支持所有方案，包括那些含非平凡参数（例如 Mastic）的方案。因此，组织必须根据其所需的确切测量来评估该实现。

DAP 在聚合期间保护报告内容，但并不自动隐藏网络元数据。聚合器仍可能看到客户端的 IP 地址、请求时序以及任务参与情况。Oblivious HTTP 可以在客户端和聚合器之间放置一个独立的中继，使中继看见连接但无法看见加密的目标内容，而聚合器则看见报告却看不到原始的网络身份。中继和聚合器必须在运营上保持分离。

分布式聚合也无法阻止从结果中推断出某些信息。对非常小的群体进行查询，或进行重复的重叠查询，即使在个体报告从未被暴露的情况下，也可能泄露信息。差分隐私可以通过添加受控噪声、限制查询以及跟踪隐私预算来应对，代价是统计精度。

不应将这些控制措施混为一体。一个部署可能使用 DAP 而不使用 OHTTP，或进行私有聚合而不使用差分隐私。最终的隐私特性取决于协议版本、聚合器的独立性、中继的分离程度、批次大小、查询策略、密码学实现以及组织上的控制。Divvi Up 提供了一种架构和服务，但每个客户都必须定义其试图解决的威胁模型。

存在生产证据，但市场仍然狭窄

Divvi Up 的第一个运营阶段与暴露通知分析绑定在一起。ISRG 报告称，截至 2022 年，该服务已处理超过 400 亿条指标。这一数字是组织自报的，但它显示分布式聚合已超越了实验室原型的阶段。

后来的部署更具揭示性。Horizontal 成为首个公开宣布的生产级用户，在与人权和敏感通信相关的应用程序中使用该服务。Mozilla 在 Firefox 遥测中，使用一个由 ISRG 运营的聚合器以及另一个由 Mozilla 运营的聚合器。这种安排反映了非共谋模型，因为两个组织处理不同的份额，且任一方都不应收到原始测量值。

ISRG 还指出了 Tinfoil，以及与 Flower 联邦学习生态系统的原型集成。与 Flower 相关的努力表明，该模式在需要群体层面信息、但不必集中本地数据的机器学习系统中具有潜在作用。但它仍是一个原型，而非成熟生产市场的证据。

这些例子说明了，为何在传统遥测会产生极大信任风险的地方，私有测量最具吸引力。浏览器会观察到敏感的用户行为；人权应用程序可能因数据暴露而危及用户；公共卫生系统需要人口统计数据，但又不希望创建中央化的移动记录。联邦学习可能因无需收集原始样例即可获得聚合信号而受益。

该架构也改变了产品管理方式。传统的分析团队可以收集详细事件，日后再决定运行哪些查询。而 Divvi Up 要求团队事先选择一个聚合函数，定义批次，设置隐私阈值，并接受未收集的细节无法被恢复。因此，这项技术在保护数据的同时，也限制了组织的好奇心。

公开的客户证据仍不完整。ISRG 未披露完整的用户普查、流量体量、服务水平记录或针对所有部署的详细案例研究。Firefox 和 Horizontal 是有意义的生产信号，但并未确立广泛的市场采纳。下一阶段将取决于是否有更多的组织愿意接受集成成本，以换取减少数据暴露。

付费隐私基础设施尚未证明其经济性

Divvi Up 使得将 ISRG 描述为完全依赖捐款支持变得复杂。其网站提供付费试点和生产服务，而定价仍属保密。在 ISRG 未经审计的 2025 年 1 月至 10 月数据中，Divvi Up 占总收入的 9%，占总支出的 19.2%。

这些百分比并不能证明其盈利性。报告未披露基础的资金分配金额、对共享开销的处理、客户集中度，或支持该项目的受限拨款金额。9% 的收入份额可能表明一种有用的多元化，但并未覆盖运营和开发该服务的全部成本。

商业模式具有实际优势。付款可以使服务能力与客户需求对齐，并减少对年度拨款的依赖。一份生产合同能够在可靠性、集成和支持方面产生直接反馈，同时也能资助使开放生态系统受益的协议工程。

这也造成了张力。一个非营利组织必须决定哪些功能服务于付费客户，哪些则推动公共标准。私有定价方式使得市场准入更难以评估，且一小部分大客户可能在运营或财务上变得有影响力。双聚合器设计还可能需要与另一个受信任的提供商合作，这使得该服务更难以作为单一供应商的解决方案进行销售。

因此，Divvi Up 是对隐私能否作为一种基础设施属性被销售，而非作为合规功能后添加的一种测试。它的替代方案包括集中式分析、内部安全计算系统、本地差分隐私，以及根本不收集该指标的决定。

一项具有财务意义的服务，可以为 ISRG 带来与直接客户价值挂钩的经常性收入。一项仍依赖补贴的专业服务，如果它能推进标准并赋能高风险应用，则可能在战略上仍有用。现有证据不支持在两者之间做出选择。相关的衡量标准是：付费生产级用户的数量、协议稳定性、独立的隐私审查、运营可靠性，以及对收入如何支持更广泛使命的更清晰说明。

数字身份仍属研究阶段，而非运营服务

ISRG 当前的研究将隐私兴趣从机器遥测扩展到了人类凭据。它正在开发一个用 Rust 编写的开源实现 Longfellow，这是与 Google 相关的一个零知识证明系统。这项工作正与 SIROS 基金会合作开展，旨在为名为 wwWallet 的欧洲数字身份项目提供公钥基础设施后端。

其目标是选择性披露。用户可以证明关于某个现有凭据的陈述——例如超过某一年龄阈值或持有某种执照——而无需出示凭据中的所有字段。零知识证明可以减少验证者接收和保留的个人数据量。

这仍是一项研究和实现工作，而非一个成熟的 ISRG 身份服务。该系统依赖于 ISRG 之外的凭据颁发者、钱包、验证者软件、信任注册表、吊销系统和标准。一个密码学证明可以确定一个签名的凭据包含某项属性，但无法确定最初的颁发者是否执行了可靠的身份核验流程。

这项工作还引入了后量子方面的考量，因为凭据的生命周期可能比 Web 证书更长。因此，ISRG 的默克尔树证书项目和 Longfellow 的研究，分别应对更广泛过渡中的不同部分。一个涉及互联网规模的服务器认证；另一个则涉及从人类凭据中实现最小的披露。

身份识别未来可能成为另一个运营项目，但现有证据并未显示已做出这一决定。审慎的描述是：这是一个新兴的研究领域，附带一个概念验证实现和一个计划的集成关系。其相关性在于它所反映的制度性论点：在信任基础设施过度收集数据或施加不必要成本的地方，开放的密码系统和公益属性的运营商或许能够改变默认做法。

一个小型董事会监管多个高后果系统

ISRG 当前的公共董事会列出了八位董事：Josh Aas、Vicky Chin、Jennifer Granick、J. Alex Halderman、Pascal Jaillon、David Nalley、Erica Portnoy 和 Christine Runnegar。他们的所属机构将该组织与 ISRG 自身、Mozilla、密歇根大学、OVHcloud、亚马逊、EFF 以及独立的法律或政策专长联系起来。2025 年度报告中，Christine Runnegar 被确定为董事会主席，而当前的董事会页面仍保留其为董事，未重述主席等职务头衔。

年度报告之后，董事会名单已发生变化。报告所列的十位董事中，来自 Cisco 的 Richard Barnes 和 Aanchal Gupta 已不再出现在当前的页面上。未发现有公开的离职公告或确切生效日期。这种缺失并不暗示有不当行为，但反映了透明度方面的缺口：当前的成员信息可见，但变动的时机和原因可能并不透明。

Josh Aas 继续担任执行董事。2025 年的报告还指出了财务、法务、发展、人事和工程方面的领导层，尽管许多员工仅以名字呈现。ISRG 采用远程分布式模式，其位于旧金山和明尼阿波利斯的地址仅用于法律或邮件联系，而非代表一个大型的中心运营场所。

外部控制强化了内部治理。Let’s Encrypt 发布证书政策和实践声明，接受 WebTrust 审计，报告事件，并遵循根项目的要求。开源软件和参与标准制定使技术决策变得可见。这些机制不能替代董事会问责，但它们创建了能够挑战错误的独立受众。

小团队模式仍然是一个重要风险。CA 运营、HSM、密码学、标准和可靠性等方面的专业知识可能集中在相对较少的人身上。项目组合的增长也可能从不同方向拉扯法务、工程、财务和运营能力。因此，董事会监督必须评估该组织是否能够支撑多个高后果系统，而不会产生隐藏的单人依赖或共享服务依赖。

ISRG 协调关系，而非拥有整个生态系统

ISRG 的关系网络相当广泛，但机制各不相同。Mozilla、EFF 和密歇根大学属于创始联盟。Cisco 和 Akamai 提供了早期资金或基础设施，而 IdenTrust 提供了交叉签名。包括 Apple、Google 和 Microsoft 在内的浏览器和操作系统公司，作为根项目或依赖方利益相关者行事。没有哪一方拥有 ISRG。

标准关系也是分布式的。互联网工程任务组（IETF）将 ACME 制定为 RFC 8555，将 ARI 制定为 RFC 9773，而 DNS-PERSIST-01 仍为草案。IETF 的隐私保护测量工作组（PPM）负责开发 DAP，互联网研究任务组（IRTF）负责开发 VDAF，而 CA/浏览器论坛则制定公共 TLS 证书的基线要求。ISRG 参与并实现这些标准，但并不单方面控制这些机构。

Prossimo 通过资助方、承包商和后续管理方运作。AWS、Sovereign Tech Agency、Alpha-Omega、Google、Cisco、Cloudflare、Shopify 和 ICANN 支持了相关倡议，而 Ferrous Systems 和 Tweede Golf 承担了工程工作。Rust 基金会托管 Rustls，Trifecta Tech 基金会管理ntpd-rs。Canonical 采用sudo-rs是一种发行版关系，而非对 ISRG 的收购或控制权转移。

Divvi Up 依赖于另一组机构。Mozilla 既是用户，也是 Firefox 第二个聚合器的运营者，而 Cloudflare 则对相关的协议工作做出了贡献。开放技术基金、福特基金会、互联网协会基金会、Meta 及其他支持者资助了隐私测量。Horizontal 是生产级用户，而 SIROS 与 wwWallet 则将新兴的身份研究与欧洲数字身份生态系统联系起来。

ISRG 的制度性技巧在于协调，而非声称所有权。它可以提供法律能力、筹资、工程、服务运营或标准参与，与此同时，其他实体控制着浏览器、DNS 区域、发行版、软件项目或第二个聚合器。这降低了纵向集中度，但依赖于持续的一致性。因此，每一种关系都必须根据其机制来理解：资助、信任决策、实施、治理、服务使用或标准权威。

财务复苏并未消除资金波动性

ISRG 的收入从 2014 年约 100,400 美元增长至 2024 年的 9,563,960 美元。其 2024 年 Form 990 报告显示，支出为 7,925,896 美元，净增 1,638,064 美元，年终净资产为 5,110,071 美元。总资产为 6,887,136 美元，负债为 1,777,065 美元。对于一个小型非营利组织而言，这一储备金是相当可观的，但相对于其运营服务所产生的后果而言，仍属适中。

年度模式并不平稳。收入在 2022 年达到约 808 万美元后有所增长，随后在 2023 年降至 516 万美元，而支出达到 781 万美元。由此产生的 2,651,888 美元赤字使净资产降至 339 万美元。2024 年，收入强劲回升，并使该组织重新实现盈余。

波动性反映了一个基于赞助、捐款和拨款的模式，而非来自 Let’s Encrypt 的使用费。ISRG 未经审计的 2025 年 1 月至 10 月图表将收入的 40% 归为赞助，24% 归为拨款，23% 归为捐款，9% 归为 Divvi Up，4% 归为利息和股息。支出分配为：Let’s Encrypt 占 50.8%，Divvi Up 占 19.2%，发展占 12.3%，运营与行政占 11%，Prossimo 占 6.8%。

这些数字表明，筹资是基础设施运营的一部分，而非可自由支配的间接费用。发展消耗资源，是因为免费的证书服务没有用户付费关系。它们还显示出一种更为混合的收入模型：慈善支持仍然居中心地位，但 Divvi Up 和投资收益使得声称 ISRG 仅靠慷慨捐助的说法在会计意义上过于简单。

2024 年的申报显示，执行董事 Joshua Aas 的报告性薪酬为 352,850 美元，其他薪酬为 44,856 美元。这些监管分类并不等同于基本工资，应在 Form 990 披露规则内加以解读。其相关性在于，在一个单个项目预算仍不够清晰的组织中，薪酬具有公共可见性。

最大的未决财务问题涉及集中度和分配。ISRG 不公布赞助集中度、各项目的独立经审计账目，或 2025 年百分比图表背后的确切美元金额。一项全球服务可能在组织层面看起来健康，而某个项目却资金不足，或某个赞助商格外重要。因此，韧性必须对照替换成本、应急能力和对实物支持的依赖来评判，而不仅仅是看最近一年是否产生盈余。

项目组合考验一家机构能否支撑多项公共物品

在其各个项目中，ISRG 遵循着一套一致的方法。它识别出一个传统产品激励未能解决的安全或隐私问题，通过开放标准和开源实现来开展工作，筹集符合使命的资金，在需要中立服务的地方运营基础设施，并寻求组织之外的广泛采纳。

Let’s Encrypt 是该模型的成熟形态：一项免费的全球服务，拥有公共根证书、审计、开放协议和广泛的客户端生态系统。Prossimo 是资助与采纳的形态：ISRG 并不运营每个产出组件，而是为由更安全的代码到实际部署的路径买单。Divvi Up 是一个混合体，将开放的密码协议和软件与一项付费服务相结合。数字身份则仍处于探索阶段。

这一方法能够解决协调与融资方面的缺口。它可以降低准入障碍，减少专有锁定，并在市场可能将数据集中或对基础信任功能收费的地方，提供一个可信的运营者。它还可以在一系列互不兼容的私有实现之外，使资助方围绕共享的基础设施保持一致。

它无法消除依赖性。Let’s Encrypt 依赖于根项目、DNS、BGP、证书透明度、数据中心和用户自动化。Prossimo 依赖于维护者、软件发行版和长期的项目归属地。Divvi Up 依赖于独立的聚合器、持续演进的标准、中继、客户集成和查询治理。身份工作则依赖于颁发者、钱包和验证方系统。

公益属性也不能替代规模方面的纪律。每个新增项目都会对法务、财务、工程和治理能力产生需求。一个小型组织可以通过自动化高效启动基础设施，但应急响应、知识传递和继任安排的扩展成本却不像常规流量那样低廉。如果 ISRG 将每一个有前景的公共利益技术都视为运营另一项永久性服务的授权，它就有可能过度扩张。

因此，该组织的长期重要性取决于其选择性。它必须区分哪些项目需要由 ISRG 运营的服务，哪些项目更适合通过拨款、标准制定工作或移交给其他基金会来支持。该模型最强的版本并非一个不断扩张的非营利集团，而是一个知道何时该运营、何时该资助、以及何时该将责任移交他方的机构。

公共利益的集中权力问题依然存在

ISRG 已经改变了围绕多个基础设施层的预设。Let’s Encrypt 使加密成为预期中的默认项，而非溢价产品。ACME 使证书生命周期的自动化成为软件正常运行的一部分。多视角验证将证书签发与路由多样性联系起来，Sunlight 将可验证的静态数据作为复杂日志系统的替代方案，Prossimo 将内存安全的倡导转化为受资助的采纳，而 Divvi Up 使非中心化的遥测作为服务变得可用。

共同的主线是减少不必要的信任集中。网站运营者不应需要一个人工的商业关系来加密流量。更安全的实现不应因为每个受益方都等待他人资助兼容性而失败。一项分析服务不应在仅需一个聚合值时就收到每一个单独的测量数据。一个凭据验证方不应在某个谓词足够时就收到每一个个人字段。

ISRG 自身却仍然成为了一个集中点。其 CA 为庞大的人群签署证书，其服务选择影响运行实践，而其资助决定能够影响哪些开源替代方案得以推进。公益基础设施并未消除权力，而是改变了行使该项权力所依据的激励、控制与审查机制。

因此，运营者应将 ISRG 的各项服务视为生产依赖，而非后台便利设施。ACME 帐户密钥、续期客户端、DNS 记录、证书安装、CRL 消费和应急监控，都应纳入常规的风险管理。Divvi Up 需要一个明确的隐私模型以及真正分离的处理方。由 Prossimo 资助的替代品，需要与其他任何基础设施组件一样进行技术和运营评估。

对政策制定者和资助方而言，ISRG 表明，当软件、标准和自动化产生杠杆效应时，一个小型非营利组织能够创造全球公共物品。这一模式值得支持，因为其收益被广泛分享。但支持应伴随着对项目成本、储备金、资助方集中度、董事会继任安排和应急响应能力更清晰的披露。

该组织最重要的成就，并非签发了多少证书或资助了多少倡议，而在于基础设施能否在保持开放、可信、可替换和韧性的同时，变得稀松平常。在日常使用中，ISRG 的服务变得越不显眼，其背后的机构就变得越发举足轻重。