Internet Security Research Group e o fardo de administrar a confiança pública

Resumo

• O Internet Security Research Group opera o Let's Encrypt, coordena o Prossimo, executa o Divvi Up e apoia pesquisas emergentes em identidade digital, dando a uma pequena organização sem fins lucrativos influência em várias camadas críticas de confiança na internet
• O Let's Encrypt combinou certificados gratuitos, automação ACME, ciclos de vida curtos e infraestrutura aberta para tornar a criptografia rotineira, transferindo a responsabilidade operacional para sistemas de renovação monitorados continuamente
• Os projetos do ISRG usam modelos econômicos diferentes: financiamento filantrópico apoia serviços públicos, bolsas direcionadas financiam software mais seguro e o Divvi Up adiciona infraestrutura de privacidade paga sem se tornar um fornecedor comercial convencional
• O principal desafio da organização é a escala institucional: seus serviços alcançam muito além de sua força de trabalho de cerca de 25 a 28 pessoas, tornando financiamento, sucessão, resposta a incidentes e seletividade de projetos parte da resiliência da internet

Uma pequena organização operando em escala de internet

O Internet Security Research Group não se encaixa facilmente nas categorias usuais de empresa, instituto de pesquisa ou associação setorial. É uma corporação de benefício público da Califórnia com status de isenção fiscal federal, uma força de trabalho distribuída e um portfólio de serviços ativos e programas de engenharia financiados cujos efeitos alcançam navegadores, servidores, plataformas de hospedagem, caminhos de rede, sistemas operacionais e telemetria de aplicativos.

Seu site organizacional público usa o nome A Better Internet, mas esse é o domínio por meio do qual o ISRG apresenta seu trabalho, e não uma entidade legal ou operacional separada.

O descompasso de escala é o ponto de partida mais útil. O relatório anual de 2025 do ISRG listou 25 funcionários, enquanto uma postagem de fevereiro de 2026 indicava aproximadamente 27,5 pessoas ou capacidade equivalente a tempo integral. Esta última era uma indicação informal, e não um número formal de funcionários, e não deve ser tratada como um número exato de pessoal.

Com essa base limitada de pessoal, a organização relatou centenas de milhões de sites protegidos, emissão de certificados atingindo cerca de dez milhões em alguns dias, registros públicos de Certificate Transparency, trabalho com padrões, programas de segurança de memória e um serviço de telemetria que preserva a privacidade.

Não se trata simplesmente de uma história de eficiência organizacional. É uma história de alavancagem técnica e concentração institucional. Software, chaves criptográficas, relacionamentos com repositórios de raiz e protocolos automatizados permitem que um pequeno operador estenda a confiança por infraestruturas globais sem empregar a força de trabalho associada a uma utilidade pública convencional. A mesma arquitetura significa que um defeito de software, falta de financiamento, erro de política ou interrupção operacional pode se propagar muito além da escala jurídica e financeira da própria organização sem fins lucrativos.

O ISRG, portanto, precisa ser avaliado em duas direções ao mesmo tempo. Sua conquista está em converter capacidades que eram caras, manuais ou restritas a especialistas em infraestrutura que operadores comuns podem adotar. Sua exposição está no número de dependências necessárias para sustentar essa simplicidade: navegadores, programas de raiz, clientes ACME, DNS, BGP, módulos de segurança de hardware, data centers, contratados, doadores e organismos de padronização, todos contribuem para sistemas que o ISRG não controla por si só.

Dois esforços técnicos se tornaram uma instituição

O ISRG surgiu da convergência de dois esforços relacionados, e não de um único fundador trabalhando isoladamente. Na Universidade de Michigan e na Electronic Frontier Foundation, J. Alex Halderman e Peter Eckersley trabalhavam na emissão e renovação automatizadas de certificados. Na Mozilla, Josh Aas e Eric Rescorla desenvolviam a ideia de uma autoridade certificadora gratuita e automatizada. Os grupos se descobriram e uniram forças em maio de 2013, combinando o trabalho de protocolo e cliente com a experiência em navegadores, infraestrutura de chave pública e autoridade certificadora.

O histórico jurídico e o registro técnico mais amplo descrevem a fundação de maneiras ligeiramente diferentes. O material organizacional atual do ISRG nomeia Aas e Rescorla como diretores fundadores, enquanto a retrospectiva posterior de Aas identifica Aas, Rescorla, Halderman e Eckersley como a equipe fundadora mais ampla. Ambos os relatos podem ser preservados sem forçá-los em um único rótulo. Aas e Rescorla formaram a diretoria jurídica inicial, enquanto todos os quatro pertenciam à coalizão técnica e organizacional da qual a instituição surgiu.

O ISRG foi incorporado em 24 de maio de 2013 e recebeu o status de isenção fiscal federal efetivo a partir de junho de 2014. Mozilla, EFF, Universidade de Michigan, Cisco e Akamai aparecem no registro de fundação como patrocinadores ou parceiros, embora seus papéis diferissem. A EFF e Michigan contribuíram com o trabalho de protocolo e cliente, a Mozilla trouxe experiência em navegadores e PKI, e Cisco e Akamai forneceram financiamento, infraestrutura ou suporte operacional. Posteriormente, a IdenTrust forneceu o relacionamento de certificação cruzada que tornou os primeiros certificados do Let's Encrypt amplamente utilizáveis.

Essa origem distribuída estabeleceu um método que o ISRG continuou a usar. A organização não tenta possuir todos os componentes dos sistemas que suporta. Ela cria um lar jurídico e operacional que pode coordenar instituições com diferentes capacidades, levantar financiamento alinhado à missão, publicar software e padrões abertos e operar as partes que exigem um provedor de serviços responsável.

O resultado é menos verticalmente organizado do que uma empresa de tecnologia convencional, mas permite que fornecedores de navegadores, grupos de liberdades civis, pesquisadores acadêmicos, empresas de infraestrutura e mantenedores independentes contribuam sem tornar nenhum participante o proprietário de todo o sistema.

A estrutura sem fins lucrativos fazia parte do modelo de confiança

A escolha de uma estrutura sem fins lucrativos foi mais do que uma decisão de captação de recursos. Uma autoridade certificadora pública ocupa uma posição privilegiada no sistema de confiança da internet porque navegadores e sistemas operacionais aceitam suas assinaturas como evidência de que um servidor controlava um nome de domínio ou outro identificador aprovado quando o certificado foi emitido. O operador pode influenciar o preço, o acesso, a automação, os perfis de certificado e as condições práticas sob as quais a comunicação criptografada se torna disponível.

Os fundadores do ISRG concluíram que essa função não deveria depender de acionistas esperando uma saída, de um incentivo comercial para aumentar os preços dos certificados ou de uma estratégia de produto baseada na venda de níveis de validação mais altos. Eles também queriam evitar que uma única empresa controladora pudesse redirecionar a missão ou reservar a automação como uma vantagem proprietária. A estrutura de benefício público alinhou o acesso universal e os padrões abertos com o propósito governante da organização, em vez de deixá-los dependentes de uma estratégia temporária de preços abaixo do custo.

A estrutura não eliminou as restrições econômicas. Os certificados do Let's Encrypt são gratuitos para os assinantes, mas o serviço exige engenheiros, confiabilidade do site, trabalho jurídico e de conformidade, auditorias, capacidade de data center, módulos de segurança de hardware, infraestrutura de validação, resposta a incidentes, operações de Certificate Transparency, manutenção de software e captação de recursos. O modelo sem fins lucrativos muda quem financia esse trabalho e como qualquer superávit pode ser usado; não faz os custos desaparecerem.

O status de organização sem fins lucrativos também não eliminou o risco de governança. O Conselho ainda escolhe orçamentos e direção estratégica, grandes patrocinadores podem se tornar importantes para a estabilidade financeira e programas de raiz ou o CA/Browser Forum podem impor requisitos que alterem materialmente as operações. Uma pequena equipe executiva também pode se tornar um ponto de concentração. A principal diferença é o alinhamento de incentivos: o ISRG não tem acionistas convencionais, não distribui lucros e é legalmente estruturado em torno do benefício público, em vez de extrair receita dos usuários de certificados.

Essa escolha institucional mais tarde se tornou um modelo para o Prossimo e o Divvi Up. Os projetos não compartilham um único modelo econômico, mas compartilham a premissa de que algumas capacidades de segurança e privacidade geram amplo valor público sem produzir um mercado proprietário direto. O ISRG tenta preencher essa lacuna por meio de patrocínio, bolsas, desenvolvimento de código aberto, operação direta e, no caso do Divvi Up, serviço pago onde um relacionamento contratual pode apoiar a missão.

O Let's Encrypt precisou de confiança emprestada antes de estabelecer a sua própria

Construir uma autoridade certificadora não torna seus certificados úteis. Navegadores e sistemas operacionais já devem confiar em uma raiz acima da cadeia emissora, e uma nova raiz do ISRG não tinha base instalada em 2013 ou 2014. A inclusão da raiz poderia levar anos. Os fundadores consideraram comprar uma raiz estabelecida, com estimativas históricas variando de US$ 1 milhão a US$ 8 milhões, mas, em vez disso, firmaram um acordo de certificação cruzada de longo prazo com a IdenTrust em outubro de 2014.

A certificação cruzada permitiu que uma raiz ou intermediária do Let's Encrypt aparecesse em um certificado assinado por uma autoridade na qual os dispositivos já confiavam. Um cliente poderia então construir uma cadeia até a raiz aceita da IdenTrust antes que a própria raiz do ISRG alcançasse os principais repositórios de confiança. Esse acordo preencheu a lacuna entre uma CA tecnicamente funcional e um serviço publicamente útil, demonstrando ao mesmo tempo uma característica permanente da PKI da web: a confiança não é autodeclarada.

Os programas de navegadores e sistemas operacionais estabelecem políticas, revisam auditorias e decidem quais raízes são aceitas.

O ISRG anunciou publicamente o Let's Encrypt em 18 de novembro de 2014. Dan Jeffery ingressou em abril de 2015 como o primeiro funcionário em tempo integral, ajudando a preparar as operações de produção. O primeiro certificado confiável para navegadores foi emitido em 14 de setembro de 2015, os marcos de confiança pública se seguiram em outubro e a disponibilidade geral começou em 3 de dezembro de 2015. O serviço emitiu seu milionésimo certificado em março de 2016, seu centésimo milionésimo em junho de 2017 e seu bilionésimo certificado acumulado em fevereiro de 2020.

A inclusão independente da Raiz ISRG X1 nos principais programas de confiança reduziu a dependência da IdenTrust, mas não acabou com a dependência da governança de raiz. Cada nova geração de raiz ainda exige inclusão, restrições e distribuição em uma população fragmentada de dispositivos. Dispositivos mais antigos podem não confiar em raízes mais novas, tornando a seleção de cadeia um problema contínuo de compatibilidade, em vez de uma tarefa de lançamento que pode ser concluída uma única vez.

Esse histórico mostra por que o ISRG é tanto um operador quanto um participante do ecossistema. Ele pode gerar chaves, conduzir cerimônias, emitir certificados e publicar políticas, mas não pode forçar uma raiz em bilhões de dispositivos. A confiança emerge de controles técnicos, auditorias, regras públicas e decisões de plataforma independentes. Essa autoridade distribuída limita o controle unilateral, ao mesmo tempo em que torna a migração lenta e introduz a complexidade da certificação cruzada, que por si só pode se tornar uma fonte de erro.

O ACME mudou a economia do gerenciamento de certificados

A inovação mais consequente do Let's Encrypt não foi a gratuidade isoladamente. Foi a combinação de certificados gratuitos com o protocolo Automated Certificate Management Environment (ACME). Antes da automação generalizada, um operador de servidor poderia comprar um certificado, provar o controle por meio de um processo manual, baixar arquivos, instalá-los, atualizar a configuração e repetir o fluxo de trabalho na renovação. Mesmo quando o certificado em si era barato, o trabalho e o risco tornavam a manutenção do HTTPS cara.

O ACME converteu esse ciclo de vida em um protocolo. Um cliente cria ou usa uma conta, envia um pedido, satisfaz um desafio, envia uma solicitação de assinatura de certificado e recebe o certificado. O mesmo cliente pode renovar antes do vencimento e reagir a informações de renovação atualizadas. Empresas de hospedagem, plataformas de conteúdo, servidores web, sistemas Kubernetes e dispositivos podem integrar a emissão à implantação normal, em vez de tratá-la como um projeto administrativo periódico.

O protocolo foi projetado como uma interface aberta, e não como uma API privada do Let's Encrypt. Quando o ACME se tornou a RFC 8555 em março de 2019, outras autoridades certificadoras públicas e privadas puderam implementá-lo, enquanto os clientes puderam oferecer suporte a vários provedores. Essa separação foi estrategicamente importante. O Let's Encrypt se beneficiou de um ecossistema crescente de clientes e integração sem a necessidade de possuir cada cliente. Certbot, Caddy, módulos nativos de servidor, serviços em nuvem e sistemas de gerenciamento de certificados puderam traduzir o padrão para seu próprio ambiente operacional.

A automação também mudou o tempo de vida viável do certificado. Um certificado de noventa dias não é atraente quando a renovação exige um tíquete humano, mas é gerenciável quando a renovação é um processo de software monitorado continuamente. Um certificado de seis dias seria inviável para a maioria dos usuários manuais, mas se torna plausível em infraestrutura fortemente automatizada. Portanto, o ACME fez mais do que reduzir o custo administrativo: ele permitiu um modelo de risco baseado em revalidação e substituição frequentes.

O relatório anual de 2025 do ISRG disse que o número de sites protegidos aumentou de cerca de 492 milhões para 762 milhões durante o ano e que a emissão atingiu cerca de dez milhões de certificados em alguns dias. Essas são métricas definidas pela organização, e não um censo independente, e os certificados não são os mesmos que sites, serviços ou usuários exclusivos. Mesmo com essa limitação, os números mostram que o gerenciamento de certificados passou de uma compra especializada para uma função em segundo plano da hospedagem e da implantação de aplicativos.

O Boulder separa o trabalho voltado para a internet da autoridade de assinatura

O software por trás do Let's Encrypt é chamado Boulder. É uma implementação de código aberto de uma autoridade certificadora ACME, mas descrevê-lo como um aplicativo web subestima o problema de segurança. Uma CA pública deve receber solicitações não confiáveis da internet, evitando que o comprometimento do código de manipulação de solicitações se torne um acesso direto às chaves de assinatura. O Boulder, portanto, divide o caminho de emissão em componentes com diferentes privilégios e responsabilidades.

Um fluxo simplificado começa no front-end web do ACME, continua pelo processamento de registro e pedidos, invoca autoridades de validação, realiza verificações de política e de Autorização de Autoridade de Certificação (CAA), obtém compromissos de Certificate Transparency e solicita a assinatura da camada CA. Armazenamento, revogação, limitação de taxa, registro de auditoria, Informações de Renovação ACME (ARI), geração de lista de revogação de certificados e outras funções de suporte permanecem separados.

Esses limites dividem o código voltado para a internet, os serviços de tomada de decisão e os sistemas autorizados a solicitar assinaturas criptográficas.

O material da chave raiz permanece offline. As intermediárias emissoras online usam chaves protegidas por módulos de segurança de hardware (HSMs). As raízes offline estabelecem a confiança de longo prazo, enquanto as intermediárias carregam a carga de trabalho de emissão diária e podem ser substituídas ou revogadas sem substituir toda a raiz. O relato técnico de 2019 do ISRG afirmou que os engenheiros de confiabilidade do site historicamente tinham o único acesso direto aos sistemas de emissão de certificados, mostrando como os controles de acesso organizacional complementam a arquitetura de software.

O código aberto fornece revisão e reutilização, mas não substitui a operação segura. Outra organização pode inspecionar o Boulder ou usar partes dele, mas a segurança do Let's Encrypt também depende de cerimônias de chaves, controles físicos, configuração de HSM, práticas de implantação, redundância de data center, monitoramento, procedimentos de equipe e evidências de auditoria. O código descreve mecanismos; o status de confiança depende do sistema mais amplo ao seu redor.

A interrupção completa do ACME em julho de 2025 mostrou os limites da separação de componentes. Um script de atualização de resolvedor criou dependências de encaminhamento circulares ou indisponíveis entre data centers, e o mesmo problema de DNS prejudicou o monitoramento e o diagnóstico. A interrupção durou quase oito horas. Nenhuma chave de assinatura foi comprometida, mas uma dependência compartilhada derrotou a redundância geográfica, mostrando que a resiliência exige caminhos de controle, observabilidade e recuperação que não falhem pelo mesmo serviço.

A validação de domínio prova controle, não legitimidade

O Let's Encrypt emite certificados validados por domínio (DV). Um certificado confirma que o solicitante demonstrou controle de um nome de domínio ou, para o perfil mais recente de curta duração, de um endereço IPv4 ou IPv6, de acordo com as regras de validação aplicáveis. Ele não estabelece que o operador é uma empresa legítima, que o site é inofensivo, que uma marca registrada pertence ao titular do certificado ou que o controle permanecerá inalterado após a emissão.

A distinção tornou-se mais importante à medida que o HTTPS se aproximava da universalidade. Os usuários geralmente interpretam o ícone de cadeado do navegador como um julgamento de segurança, mas o Transport Layer Security (TLS) protege principalmente a conexão e autentica o identificador do ponto de extremidade. Um site de phishing pode controlar um domínio e obter um certificado DV válido. A missão do Let's Encrypt era remover o custo e o atrito da criptografia, não criar um sistema global de identidade comercial ou moderação de conteúdo.

Os desafios comuns do ACME refletem diferentes ambientes de implantação. HTTP-01 exige que o solicitante coloque um token em um caminho web definido. DNS-01 usa um registro TXT em_acme-challenge, permitindo a emissão de curinga, mas geralmente exigindo acesso a credenciais DNS poderosas. TLS-ALPN-01 usa um certificado especial durante um handshake TLS. Os certificados de endereço IP aplicam métodos aprovados a endereços literais e são restritos ao perfil de curta duração. DNS-PERSIST-01 é um modelo emergente para autorização DNS permanente e vinculada à conta, em vez de um novo token para cada emissão.

Cada método realoca o risco. A validação na web depende de roteamento, hospedagem e manipulação de solicitações; a validação DNS depende de DNS autoritativo, credenciais de API e propagação; e a validação TLS depende do isolamento correto do serviço. A autorização persistente poderia remover o acesso rotineiro à API DNS dos sistemas de renovação, mas aumenta a importância da chave da conta ACME e do registro permanente. A CA prova o controle sob um protocolo definido; ela não pode eliminar todos os caminhos de comprometimento em torno dessa prova.

Esse escopo restrito é uma das razões pelas quais o Let's Encrypt pode operar em escala global. A Validação da Organização (OV) e a Validação Estendida (EV) exigem evidências diferentes sobre identidade jurídica e autoridade, e o ISRG optou por não oferecer esses produtos. O serviço resultante é intencionalmente limitado, mas altamente acessível, protegendo o transporte para uma população enorme, enquanto deixa a reputação, a identidade comercial e a segurança do aplicativo para outros sistemas.

A validação passou de um único ponto de vista de rede

Uma autoridade certificadora que valida a partir de um único local de rede pode ser enganada se um invasor desviar sua rota BGP ou manipular o DNS ao longo desse caminho. O Let's Encrypt iniciou a validação de múltiplas perspectivas em 2020, com suporte de pesquisa vinculado à Universidade de Princeton. Em vez de confiar em uma observação, a CA pede que validadores em diferentes posições de rede corroborem o controle antes da emissão.

Os requisitos do setor posteriormente formalizaram a abordagem. A partir de junho de 2026, as regras do CA/Browser Forum exigiram pelo menos quatro perspectivas remotas, com perspectivas corroborantes abrangendo pelo menos duas regiões de serviço do Registro Regional da Internet (RIR). O sistema de validação do Let's Encrypt, portanto, tornou-se geográfica e topologicamente distribuído por política, bem como por design.

A validação de múltiplas perspectivas muda o problema do invasor porque um sequestro de rota local que engana um ponto de vista pode não enganar redes remotas. Isso não torna a validação fraudulenta impossível. Um ataque de roteamento amplo, comprometimento de DNS autoritativo, falha de nuvem correlacionada ou falha na implementação do desafio ainda pode afetar várias perspectivas. A diversidade só ajuda quando os validadores não compartilham dependências ocultas.

CAA e Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) adicionam controles diferentes. Os registros CAA permitem que um domínio indique quais autoridades certificadoras podem emitir para ele, enquanto o DNSSEC pode fornecer integridade para respostas DNS assinadas. A partir de 15 de março de 2026, os requisitos de CAs públicas tornaram a validação DNSSEC obrigatória para validação de domínio de perspectiva primária e pesquisas CAA, e uma falha de DNSSEC não poderia mais ser tratada como permissão para prosseguir.

O incidente CAA de 2020 mostrou por que o valor de um controle depende da implementação correta. O Boulder verificava novamente um nome repetidamente em certos pedidos com vários nomes, em vez de verificar todos os nomes exigidos. Aproximadamente três milhões de certificados foram identificados como potencialmente afetados. A falha não invalidou o CAA; expôs um defeito de software em como a regra havia sido aplicada. Em escala da web, um pequeno erro de indexação ou loop pode se tornar um evento de substituição em massa e conformidade.

A segurança do certificado, portanto, se estende além da própria CA. Depende da capacidade da internet de apresentar visões consistentes de identificadores entre redes e da capacidade da CA de reconhecer discordâncias. A arquitetura de validação do Let's Encrypt conecta a PKI diretamente ao roteamento, DNS e à diversidade operacional da internet mais ampla.

A Geração Y reconstruiu a confiança por meio de outra camada de compatibilidade

A hierarquia do Let's Encrypt separa raízes de intermediárias emissoras e usa as famílias RSA e ECDSA. As raízes estabelecidas incluem ISRG Root X1 e ISRG Root X2. Em setembro de 2025, o ISRG gerou novas raízes da Geração Y, YE e YR, e posteriormente anunciou outro grupo de intermediárias. Até julho de 2026, YE1 e YE2 eram as intermediárias ECDSA ativas, YR1 e YR2 eram as intermediárias RSA ativas, e YE3 e YR3 foram mantidas como backups.

As novas raízes ainda não estavam amplamente presentes nos principais repositórios de confiança em 8 de julho de 2026. As cadeias padrão, portanto, continuaram por meio das raízes ISRG X estabelecidas usando certificados cruzados. Isso permitiu que a nova hierarquia operasse enquanto a distribuição de confiança independente continuava, mas cada certificado cruzado se tornava outro objeto de política cujas extensões, validade, revogação e comportamento de construção de caminho precisavam estar corretos.

Mudanças de geração são inevitáveis. As vidas úteis de raiz e intermediária são finitas, as preferências criptográficas evoluem e as cerimônias de chaves ou os limites operacionais precisam de renovação. Uma nova hierarquia pode introduzir algoritmos, perfis e um horizonte de planejamento mais longo. Também expõe diferenças entre políticas de navegador, repositórios de sistemas operacionais, dispositivos embarcados e comportamento alternativo de seleção de cadeia.

A hierarquia é, portanto, uma estratégia de compatibilidade, e não uma lista estática de certificados. Um cliente moderno pode preferir uma cadeia ECDSA mais curta, enquanto uma plataforma mais antiga pode precisar de um caminho por meio de uma raiz RSA amplamente instalada. Clientes e servidores ACME podem encontrar cadeias alternativas com resultados diferentes. A CA deve equilibrar a modernização criptográfica com a possibilidade de que uma cadeia válida falhe para uma população material de dispositivos.

A documentação de cadeia do ISRG funciona como uma fonte operacional atual, e não como uma referência histórica. Operadores que fixam intermediárias ou assumem um comprimento de cadeia fixo podem quebrar durante as transições. O modelo pretendido é confiar em raízes adequadas e permitir a construção normal de caminho, mas software embarcado e plataformas mais antigas nem sempre se comportam de maneira ideal. A Geração Y mostra como a confiança pública de longa duração é repetidamente reconstruída por meio de decisões operacionais de curta duração.

Uma restrição ausente tornou-se um incidente público de conformidade

A implantação da Geração Y produziu uma falha de conformidade em maio de 2026. Certificados de CA subordinada com certificação cruzada foram criados sem uma restrição de uso estendido de chave (EKU)serverAuthexigida. A omissão afetou os certificados que ligavam a nova hierarquia às raízes confiáveis existentes, não a força criptográfica das chaves dos assinantes.

O Let's Encrypt interrompeu a emissão afetada, criou certificados cruzados de substituição e revogou os defeituosos. Também usou as Informações de Renovação ACME (ARI) para incentivar os assinantes cujas cadeias poderiam ser afetadas a obter certificados de entidade final de substituição. A organização concluiu que os certificados de assinante em si não exigiam revogação porque o defeito estava no perfil de certificação cruzada subordinada e poderia ser resolvido por meio da substituição da cadeia.

O incidente é importante além de uma única extensão ausente, porque demonstra como os mecanismos de compatibilidade ampliam a superfície de conformidade. Um certificado raiz, uma chave intermediária, um certificado autoassinado e várias formas de assinatura cruzada podem representar identidades criptográficas relacionadas, mas carregam diferentes restrições de política. Um perfil adequado para uma posição em um caminho pode ser não conforme em outra.

A resposta também mostrou o valor da automação desenvolvida antes do incidente. O ARI pôde sinalizar a renovação antecipada, os clientes ACME puderam obter substituições sem outro processo de compra e as novas cadeias puderam ser distribuídas rapidamente. A mesma escala operacional que tornou o erro consequente também tornou possível a remediação técnica ampla.

A automação não pôde remover a necessidade de julgamento. O Let's Encrypt ainda teve que decidir quais objetos exigiam revogação, como as partes confiantes construiriam caminhos, se os certificados de assinante permaneciam aceitáveis e com que rapidez a transição deveria ocorrer. Uma resposta geral poderia ter criado interrupções desnecessárias, enquanto uma resposta inadequada poderia ter deixado cadeias não conformes em serviço. O tratamento de incidentes nessa camada exige um equilíbrio entre validade criptográfica, regras formais, comportamento do navegador e continuidade do serviço.

A conclusão útil não é que a Geração Y falhou ou que a certificação cruzada é inerentemente falha. É que uma migração de confiança pública deve ser gerenciada como um programa operacional, com emissão em estágios, teste de cadeia alternativa, prontidão de ARI, evidência explícita de fechamento e um relato claro de como cada forma de certificado é restringida.

Certificados de curta duração transferem risco para a automação

O Let's Encrypt disponibilizou certificados de seis dias e certificados para endereços IPv4 e IPv6 em geral em 15 de janeiro de 2026. O perfil de curta duração é válido por 160 horas, e os certificados de endereço IP devem usá-lo porque os endereços podem ser reatribuídos ou mudar de controle operacional mais prontamente do que muitos nomes de domínio. A validação frequente encurta o período durante o qual o controle obsoleto pode permanecer autenticado.

Certificados mais curtos reduzem a exposição máxima de uma chave roubada ou emissão incorreta, mas transferem mais risco para o sistema de renovação. Um certificado de noventa dias dá a um operador semanas para detectar um fluxo de trabalho quebrado. Um certificado de seis dias pode se tornar uma interrupção de serviço em dias. O sistema de segurança relevante, portanto, inclui agendamento do cliente, proteção da chave da conta, disponibilidade de desafio, planejamento de limite de taxa, instalação, recargas de serviço e monitoramento do certificado realmente apresentado aos usuários.

O perfil opcionaltlsservermudou para certificados de 45 dias em maio de 2026, enquanto o perfil padrãoclassicpermaneceu em noventa dias no corte da pesquisa. O Let's Encrypt planeja reduzir o padrão para 64 dias em fevereiro de 2027 e 45 dias em fevereiro de 2028. Separadamente, os requisitos do CA/Browser Forum reduzem a vida útil máxima do TLS publicamente confiável para 47 dias a partir de 15 de março de 2029. Essas são transições programadas, e não fatos concluídos para todos os certificados.

A mudança altera a relação entre a CA e o assinante. A renovação não é mais uma ação periódica escolhida independentemente por cada cliente. Torna-se um fluxo contínuo que a CA pode precisar distribuir ao longo do tempo e redirecionar durante incidentes. Os sistemas do assinante devem, portanto, tratar o estado da conta ACME, a lógica de renovação e a implantação do certificado como planos de controle de produção.

Os certificados IP ampliam a utilidade da confiança pública automatizada. Pontos de extremidade de infraestrutura sem nomes DNS estáveis, dispositivos de rede e certos ambientes de descoberta de serviço podem autenticar endereços literais. O recurso fornece franqueza, mas o endereço deve permanecer controlado e repetidamente acessível por meio da validação. Isso torna a PKI pública mais útil para operadores de infraestrutura, reforçando o princípio de que a identidade deve ser atualizada à medida que o controle operacional muda.

O ARI transforma a renovação em um sistema de controle coordenado

As Informações de Renovação ACME (ARI), publicadas como RFC 9773 em setembro de 2025, dão a uma autoridade certificadora uma maneira de recomendar quando um cliente deve renovar. A CA pode publicar uma janela de início e término, distribuir a carga de renovação de rotina e indicar que um certificado afetado deve ser substituído antecipadamente antes da revogação. O Let's Encrypt já havia implementado o servidor de rascunho, usando a experiência operacional para ajudar a moldar o padrão final.

O ARI transforma a renovação de um temporizador apenas do cliente em um plano de controle compartilhado. Sem ele, milhões de clientes podem renovar todos em uma fração fixa da vida útil do certificado, produzindo picos previsíveis. Durante um incidente, a CA pode revogar certificados, mas não pode garantir que cada assinante os substitua primeiro. Clientes com reconhecimento de ARI possibilitam uma resposta sequenciada: obter um novo certificado, implantá-lo, verificá-lo e, em seguida, permitir que o antigo seja revogado ou expire.

A extensão não conclui o caminho de implantação final. Um cliente pode solicitar uma substituição e ainda assim não conseguir gravar o arquivo, atualizar um balanceador de carga, recarregar um servidor web ou detectar que um nó antigo permanece em serviço. A adoção também varia entre os clientes. O valor prático do ARI, portanto, depende da implementação em todo o sistema do assinante, não apenas do suporte na API da CA.

O DNS-PERSIST-01 aborda um risco de automação separado. A renovação DNS-01 convencional geralmente fornece a um cliente ACME credenciais capazes de modificar o DNS autoritativo, de modo que o comprometimento do host de renovação pode se tornar o comprometimento do domínio. O desafio persistente proposto usa um registro permanente vinculado a um identificador de CA e uma conta ACME específica, com escopo de curinga e expiração opcionais. As renovações de rotina podem então prosseguir sem expor repetidamente credenciais amplas de API DNS.

Essa abordagem realoca a confiança em vez de removê-la. A chave da conta ACME torna-se mais poderosa e o registro permanente deve permanecer correto. No corte da pesquisa, o método permaneceu como um rascunho do IETF. O Pebble suportou a experimentação e o Let's Encrypt descreveu planos de preparação e produção, mas um anúncio oficial definitivo da conclusão da implantação em produção não foi identificado. Portanto, deve ser tratado como um controle emergente, e não como um recurso atual universal.

Juntos, ARI e DNS-PERSIST-01 mostram que o gerenciamento de certificados está indo além da emissão em direção à autorização contínua. As questões difíceis dizem respeito a quem pode renovar, quando a renovação deve ocorrer, como as credenciais são protegidas e como uma CA pode direcionar uma população distribuída de clientes durante um incidente sem se tornar responsável pelo sistema de implantação de cada assinante.

Encerrar o OCSP simplificou uma camada e ampliou outra

O Let's Encrypt encerrou seu serviço de Protocolo de Status de Certificado Online (OCSP) em 6 de agosto de 2025. No pico, o serviço lidava com aproximadamente 340 bilhões de solicitações por mês. Esse volume criava um custo substancial de infraestrutura, enquanto cada consulta podia revelar o endereço IP do cliente e o site cujo certificado estava sendo verificado. O ISRG concluiu que a carga operacional e de privacidade não era mais justificada.

O serviço agora publica informações de revogação de certificados por meio de listas de revogação de certificados (CRLs). As CRLs podem ser armazenadas em cache e distribuídas em massa, evitando uma consulta por visitante à CA. Elas simplificam a arquitetura online do emissor e se encaixam em um ecossistema de navegadores no qual os fornecedores de plataforma agregam ou distribuem cada vez mais dados de revogação por meio de seus próprios sistemas.

A compensação diz respeito à atualização e ao comportamento da parte confiável. As listas podem ser grandes, os clientes devem obtê-las e processá-las, e as plataformas podem atualizar em intervalos diferentes. Encerrar o OCSP não tornou a revogação desnecessária. Mudou o mecanismo de distribuição e transferiu mais responsabilidade para navegadores e sistemas operacionais que consomem as listas.

A estratégia mais ampla do Let's Encrypt também reduz a dependência da revogação por meio de ciclos de vida curtos e renovação rápida. Um certificado de seis dias comprometido tem uma janela de exposição natural mais curta do que um certificado de noventa dias, enquanto o ARI pode incentivar a substituição antes da revogação. A expiração ainda não é uma resposta imediata, e alguns incidentes não podem esperar. A revogação, portanto, permanece necessária, mesmo que seja uma camada imperfeita.

Eventos em massa anteriores mostraram o conflito entre prazos formais e continuidade do serviço. Em 2020, o bug do CAA potencialmente afetou cerca de três milhões de certificados, e o Let's Encrypt adiou a revogação imediata de mais de um milhão de certificados restantes em vez de quebrar abruptamente um grande número de sites. Em janeiro de 2022, um erro de validação TLS-ALPN levou a aproximadamente 2,7 milhões de revogações. Conformidade, redução de risco e disponibilidade não apontavam para uma única resposta simples.

O fim do OCSP deve ser entendido como simplificação arquitetônica, não como o fim do gerenciamento de status. O sistema agora depende mais fortemente da distribuição de CRL, integração de plataforma, ciclos de vida curtos e renovação coordenada. Se ele terá um desempenho melhor depende de todo o ecossistema da parte confiável, e não apenas do volume reduzido de solicitações da CA.

Sunlight torna a transparência mais barata de operar

O Certificate Transparency (CT) exige que certificados publicamente confiáveis sejam enviados a registros somente de acréscimo. Esses registros permitem que os proprietários de domínio monitorem a emissão, permitem que os navegadores exijam provas de que os certificados foram registrados e fornecem aos pesquisadores um conjunto de dados públicos para examinar a emissão incorreta e o comportamento da PKI. O Let's Encrypt opera registros CT públicos desde 2019, tornando o ISRG tanto um grande emissor de certificados quanto um operador de outra camada de infraestrutura de confiança.

Os sistemas CT tradicionais geralmente dependem de APIs de leitura com suporte de banco de dados que exigem armazenamento, capacidade de consulta, controles de consistência e suporte operacional substancial. O Let's Encrypt introduziu o Sunlight em março de 2024 como uma arquitetura de blocos estáticos. A árvore de Merkle é representada em arquivos ou objetos que podem ser colocados em armazenamento de objetos, armazenados em cache por redes de distribuição de conteúdo, compactados e espelhados de forma independente.

O caminho de gravação é intencionalmente mais simples. Um único gravador avança os pontos de verificação usando proteção de comparação e troca. O argumento de design do Let's Encrypt é que o CT já exige que os certificados sejam enviados a vários registros independentes, de modo que a redundância em nível de ecossistema pode substituir a transformação de cada registro em um banco de dados distribuído complexo. Se um registro falhar, outros continuam fornecendo inclusão enquanto o serviço com falha pode se recuperar de um estado mais simples.

Isso é característico da abordagem de engenharia do ISRG: usar estruturas de dados criptográficas e operadores independentes para reduzir a complexidade de cada serviço. O design não garante que cada registro de bloco estático seja aceito por todos os programas de navegador ou que todos os modos de falha desapareçam. Os programas de registro ainda avaliam o gerenciamento de chaves, o comportamento do operador, o atraso máximo de mesclagem, o monitoramento e a disponibilidade.

O Sunlight também aborda as restrições econômicas da organização. Uma autoridade certificadora gratuita pode reduzir custos simplificando a infraestrutura pública adjacente, em vez de expandir continuamente as frotas de serviços. Objetos estáticos são mais fáceis de armazenar em cache, espelhar e inspecionar. Se o design for adotado além do Let's Encrypt, poderá reduzir a barreira para operadores de registro adicionais e aumentar a diversidade.

O teste estratégico, portanto, é a adoção, e não a elegância arquitetônica. O Sunlight se torna infraestrutura pública apenas se programas de navegador, outras CAs, monitores e operadores independentes o usarem em produção sem recriar outra dependência central oculta.

Merkle Tree Certificates propõem um caminho pós-quântico diferente

As assinaturas pós-quânticas criam um problema de tamanho para a PKI da web porque algoritmos projetados para resistir a futuros ataques quânticos geralmente usam chaves públicas e assinaturas maiores do que os sistemas ECDSA ou RSA atuais. Substituir cada assinatura em uma cadeia X.509 convencional pode aumentar os handshakes TLS, aumentando a largura de banda e a latência em bilhões de conexões.

Em junho de 2026, o Let's Encrypt anunciou um programa centrado em Merkle Tree Certificates (MTCs). Em vez de assinar cada certificado individualmente com uma grande assinatura pós-quântica, um emissor pode colocar muitos certificados em uma árvore de Merkle, assinar um ponto de verificação comum e fornecer a cada certificado uma prova de inclusão compacta. O modelo poderia reduzir a sobrecarga de assinatura repetida, integrando a transparência à estrutura de emissão.

O roteiro visava a preparação no final de 2026 e um ambiente pronto para produção em 2027. Esses eram planos, e não uma implantação concluída. Os assinantes comuns continuaram a receber certificados convencionais no corte da pesquisa, enquanto o suporte do navegador, a padronização do protocolo, o comportamento do cliente e a interoperabilidade permaneceram dependências externas.

Os MTCs mostram que o ISRG está preparado para questionar o formato que envolve a CA existente, em vez de apenas substituir algoritmos dentro dela. Uma substituição pós-quântica direta poderia preservar a semântica X.509 convencional, mas impor um custo de tamanho duradouro. Um sistema baseado em árvore muda a emissão, a distribuição de provas e a validação da parte confiável, criando uma transição mais exigente, mas com uma economia de rede potencialmente melhor.

O principal risco é a coordenação. Um formato de certificado é útil apenas se os servidores puderem obtê-lo e apresentá-lo, os navegadores puderem validá-lo, os organismos de padronização puderem especificá-lo e o comportamento de fallback não introduzir problemas de downgrade ou compatibilidade. O X.509 convencional e os novos mecanismos podem precisar coexistir por anos, adicionando outro problema de implantação e seleção de cadeia a um sistema de confiança já complicado.

A escala operacional do ISRG lhe dá uma vantagem porque pode testar propostas contra padrões reais de emissão e construir infraestrutura de preparação. Sua autoridade permanece limitada porque não pode fazer a web adotar os MTCs por anúncio. O programa depende da convergência independente entre navegadores, servidores, padrões e comunidades criptográficas.

Incidentes revelam tanto a escala quanto o modelo de aprendizado

O histórico do Let's Encrypt inclui vários incidentes que definem seus limites tão claramente quanto seu crescimento. O TLS-SNI-01 foi desativado em janeiro de 2018 depois que o comportamento de hospedagem compartilhada criou um caminho de validação não autorizado. O bug de reverificação do CAA em fevereiro de 2020 levou a um grande programa de substituição e revogação. Um erro de validação TLS-ALPN em janeiro de 2022 desencadeou aproximadamente 2,7 milhões de revogações. Uma dependência de DNS causou uma interrupção completa da API em data centers por quase oito horas em julho de 2025.

Os certificados cruzados da Geração Y tiveram que ser substituídos em maio de 2026 devido à restrição de EKU ausente.

Esses eventos, por si só, não estabelecem que o Let's Encrypt não é confiável de forma única. Um serviço que emite nessa escala exporá interações raras e enfrenta um escrutínio minucioso de programas de raiz e pesquisadores de segurança. O teste mais relevante é como a organização detecta, divulga, contém e aprende com as falhas.

O registro mostra a publicação repetida de detalhes de incidentes, suspensão da emissão afetada, ferramentas de substituição e mudanças na arquitetura ou procedimento. Também mostra que a conformidade formal e a continuidade operacional podem entrar em conflito. A revogação imediata pode satisfazer um prazo, ao mesmo tempo em que interrompe serviços cujos operadores não renovaram, enquanto a revogação adiada pode preservar a disponibilidade, deixando os certificados potencialmente afetados válidos e atraindo escrutínio.

A automação amplifica tanto as consequências quanto a recuperação. Um defeito pode afetar milhões de certificados, enquanto a mesma automação pode substituir esses certificados mais rapidamente do que um sistema manual. O ARI se desenvolveu em parte a partir da necessidade de coordenar a substituição em escala. A validação de múltiplas perspectivas e os requisitos de DNSSEC refletem o reconhecimento de que os caminhos de rede e o comportamento do DNS podem minar a validação do certificado.

Os usuários profissionais devem, portanto, evitar tratar a CA como a única parte responsável. Os operadores precisam de monitoramento de renovação, clientes atuais, failover testado, contatos confiáveis e conhecimento dos canais de incidentes. Os programas de raiz precisam de regras e evidências proporcionais, enquanto o ISRG precisa de sistemas de monitoramento e recuperação que permaneçam utilizáveis quando uma dependência compartilhada falha. A confiança pública é mantida por meio de falhas visíveis e recorrência reduzida, não pela suposição de que os incidentes podem ser eliminados.

O Prossimo financia o caminho difícil do código mais seguro à adoção

O Prossimo aborda outra classe de risco de infraestrutura: corrupção de memória em software escrito em linguagens que não impõem segurança de memória. Condições de uso após liberação, estouros de buffer e acesso a ponteiros inválidos afetam bibliotecas TLS, software DNS, sistemas operacionais, ferramentas de gerenciamento de privilégios e codecs há décadas. Reescrever componentes críticos pode reduzir essa categoria de defeito, mas o trabalho é caro e os beneficiários compartilhados muitas vezes não têm um incentivo único para financiá-lo.

O Conselho do ISRG aprovou o projeto de segurança de memória em 9 de dezembro de 2020, e o Prossimo foi estabelecido publicamente em 2021. O programa não emprega uma equipe central para reescrever a internet. Ele identifica um componente importante, define uma iniciativa, levanta fundos dedicados, contrata mantenedores ou empresas de engenharia especializadas, paga por auditorias e ferramentas, apoia empacotamento e compatibilidade e tenta mover o resultado para a implantação real.

O modelo operacional é importante porque a conclusão técnica não é o mesmo que a adoção. Uma implementação em Rust pode ser segura em termos de memória, mas carecer de uma API exigida por aplicativos existentes. Pode ter desempenho diferente, precisar de uma interface C, exigir empacotamento ou falhar em um ambiente restrito. O Prossimo, portanto, financia o trabalho pouco glamoroso entre o protótipo e a infraestrutura padrão: camadas de compatibilidade, benchmarks, auditorias de segurança, operaçãono_std, integração de distribuição e transferência para mantenedores.

O programa funciona por meio de uma ampla rede. Os financiadores incluíram AWS, Sovereign Tech Agency, Alpha-Omega, Google, Cisco, Cloudflare, Shopify, ICANN e outros. Contratados e parceiros incluíram Ferrous Systems, Tweede Golf, a Rust Foundation e a Trifecta Tech Foundation. Esses relacionamentos não tornam o ISRG o proprietário de todos os projetos resultantes. Direitos autorais, governança e manutenção podem permanecer com comunidades independentes ou passar para uma fundação especializada.

O Prossimo é melhor entendido como um motor de adoção. Ele concentra capital e coordenação onde beneficiários fragmentados não podem financiar facilmente uma infraestrutura comum. Seu sucesso deve ser medido pela auditoria, empacotamento, implantação, manutenção e eventual tratamento das implementações como escolhas comuns, e não pelo número de iniciativas anunciadas.

O Rustls mostra por que um código mais seguro ainda precisa de engenharia de compatibilidade

O Rustls é uma das iniciativas mais desenvolvidas do Prossimo. É uma implementação TLS escrita em Rust e projetada para fornecer segurança de memória, atendendo aos requisitos criptográficos e operacionais modernos. Uma API Rust nativa não seria suficiente para substituir bibliotecas maduras, então o trabalho incluiu uma interface C, uma camada de compatibilidade OpenSSL, suporte assíncrono, modosno_stde sem alocação, opções criptográficas compatíveis com FIPS e troca de chaves pós-quântica.

Cada capacidade aborda uma barreira de adoção diferente. A compatibilidade C permite que o software existente use a biblioteca sem ser reescrito em Rust. A compatibilidade com OpenSSL visa aplicativos que assumem APIs familiares. Ono_stdsuporta ambientes sem uma biblioteca padrão completa de sistema operacional, enquanto o trabalho sem alocação atende a sistemas restritos. O suporte FIPS é importante em implantações regulamentadas, e a engenharia de desempenho responde a operadores que não estão dispostos a aceitar uma penalidade de infraestrutura material em troca de segurança teórica.

O Prossimo publicou benchmarks favoráveis, mas os resultados devem permanecer atribuídos, em vez de tratados como prova universal. O desempenho do TLS depende da escolha do algoritmo, hardware, tamanhos de registro, concorrência, reutilização de sessão e integração do aplicativo. Uma biblioteca pode liderar um teste enquanto encontra limites de compatibilidade ou operacionais em outros lugares.

A transição de governança é tão importante quanto o código. Em 2025, o Rustls tornou-se um projeto hospedado inaugural no Laboratório de Inovação da Rust Foundation. Esse movimento pode fornecer um lar durável além de uma sequência de contratos do ISRG. Reflete o ciclo de vida desejado do Prossimo: financiar o trabalho ausente, reduzir as barreiras de adoção e, em seguida, colocar a custódia onde mantenedores e usuários possam continuá-la.

O Rustls mostra por que a segurança de memória é um problema institucional tanto quanto uma escolha de linguagem. A implementação deve ser confiável, mas o ecossistema circundante deve ser capaz de adotá-la. O Prossimo financia as interfaces, auditorias, relacionamentos organizacionais e evidências de implantação que transformam uma biblioteca mais segura em uma opção prática de infraestrutura.

A adoção em produção separa o trabalho maduro da ambição financiada

Os resultados mais claros do Prossimo são os projetos que passaram do desenvolvimento para a produção. A iniciativantpd-rsfinanciou uma implementação de Network Time Protocol com segurança de memória, com suporte a servidor, cliente e Network Time Security. Passou por uma auditoria externa, foi transferida para a Trifecta Tech Foundation para custódia, ganhou pacotes para Fedora e Ubuntu e entrou na infraestrutura do Let's Encrypt em junho de 2024.

Essa sequência é importante porque a sincronização de tempo é uma dependência oculta para certificados, registros, autenticação e sistemas distribuídos. Um novo daemon só se torna útil quando os operadores confiam em sua precisão, podem instalá-lo por meio de pacotes normais e estão dispostos a executá-lo. Ao implantar ontpd-rs, o ISRG tornou-se um adotante do trabalho de segurança que financiou, em vez de apenas um administrador de bolsas.

Osudo-rsoferece um exemplo em nível de distribuição. A Canonical o tornou a implementação sudo padrão no Ubuntu 26.04 LTS, mantendo a implementação original como um fallback de compatibilidade. Esta é uma forte evidência de adoção, mas não uma prova de paridade completa de recursos. Um fallback reconhece que ferramentas maduras acumulam plugins, fluxos de trabalho e casos extremos não documentados que uma substituição pode ainda não reproduzir.

O suporte a Rust no kernel do Linux, mesclado em 2022 e apoiado por financiamento relacionado, é um marco mais amplo do ecossistema. Ele permite que drivers e módulos selecionados sejam escritos em uma linguagem com segurança de memória sem substituir o código C existente. O benefício é prospectivo: novos componentes podem evitar algumas classes de erro de memória, permanecendo parte de um grande sistema legado.

O Hickory DNS permanece um caso mais cauteloso. O projeto está desenvolvendo um resolvedor recursivo de alto desempenho em Rust com DNSSEC, NSEC3, criptografia oportunista, auditorias e trabalho de preparação para produção. O Prossimo descreveu a preparação para o volume de consultas do Let's Encrypt, mas uma migração completa não foi verificada no corte. Uma implementação financiada, uma auditoria, um plano de implantação e um serviço operacional permanecem estágios de evidência separados.

Juntos, esses projetos definem a escada de adoção que o Prossimo está tentando padronizar: construir, auditar, empacotar, implantar em um ambiente exigente, transferir a custódia e tornar o componente mais seguro um padrão com um fallback controlado. O valor de longo prazo do programa depende de repetir essa progressão com mais frequência do que anunciar novas reescritas.

A segurança de memória reduz uma classe de falhas

Linguagens com segurança de memória podem evitar muitos acessos inválidos, condições de uso após liberação e erros de buffer, tornando estados inseguros difíceis ou impossíveis de representar no código comum. Essa redução é valiosa em analisadores de infraestrutura e mecanismos de protocolo que rotineiramente manipulam entradas controladas por invasores.

A segurança de memória não é segurança de software completa. Uma implementação em Rust ainda pode conter erros de lógica, uso indevido de criptografia, fraquezas de negação de serviço, blocos inseguros, escolhas inadequadas de dependências, erros de privilégio ou defeitos de interoperabilidade. Uma reescrita pode introduzir um novo comportamento, mesmo removendo classes antigas de bugs. Revisão, fuzzing, auditorias, compilações reproduzíveis, governança de dependências e migração cuidadosa permanecem necessários.

A compatibilidade cria outra fonte de risco. Componentes C maduros geralmente expõem décadas de comportamento não totalmente documentado em suas interfaces formais. Os aplicativos podem depender de códigos de erro, temporização, sintaxe de configuração ou convenções de plugin que uma substituição não reproduz. Uma implementação com segurança de memória que é teoricamente correta, mas operacionalmente incompatível, pode não conseguir adoção ou causar interrupções durante a migração.

O design do programa Prossimo reconhece isso financiando APIs C, compatibilidade com OpenSSL, empacotamento e padrões em estágios. Também levanta uma questão econômica: quando o ecossistema deve financiar uma reescrita em vez de continuar a fortalecer o código existente? A resposta depende do histórico de vulnerabilidades, da capacidade do mantenedor, da estabilidade da interface e se a nova implementação pode atrair uma custódia durável.

O portfólio inclui Rustls, Hickory DNS,sudo-rs,su-rs,ntpd-rs, o decodificador AV1rav1d, trabalho com zlib com segurança de memória, Rust para Linux, o proxy reverso River,mod_tlsdo Apache e trabalho selecionado com curl. A maturidade varia muito, e listar os projetos juntos não significa que todos estejam prontos para produção ou sejam governados pelo ISRG.

A avaliação defensável é que o Prossimo construiu um método repetível de financiamento e adoção, não uma garantia de que a infraestrutura insegura em termos de memória desaparecerá. Sua contribuição é converter uma preferência política geral em projetos com mantenedores, auditorias, interfaces e metas de implantação. O resultado final será visível em padrões, uso de pacotes, continuidade e exposição a vulnerabilidades ao longo de vários anos.

O Divvi Up evita coletar o texto simples que não precisa

O Divvi Up aborda o custo de privacidade da telemetria convencional. A maioria dos sistemas de análise envia eventos individuais para uma organização, que armazena registros em texto simples e depois calcula agregados. Mesmo quando o resultado desejado é uma simples contagem ou soma, o coletor geralmente recebe um conjunto de dados mais rico do que a pergunta final exige.

O Divvi Up muda essa arquitetura. Um cliente usa uma Função de Agregação Distribuída Verificável (VDAF) para dividir uma medição em compartilhamentos criptografados. Um compartilhamento vai para um agregador líder e outro para um ajudante. Nenhum dos servidores recebe a medição original em texto simples. Cada um calcula um agregado parcial, e um coletor combina os resultados parciais para obter uma estatística da população.

A garantia de privacidade depende da separação institucional. Se pelo menos um agregador se comportar honestamente e os dois não conspirarem, nenhum deles poderá reconstruir uma medição individual a partir de seu compartilhamento. Se ambos conspirarem ou uma organização controlar efetivamente os dois, a principal suposição falha. O Divvi Up, portanto, torna a independência organizacional parte do design criptográfico.

O ISRG aprovou o projeto em outubro de 2020 e anunciou o ISRG Prio Services em novembro. Seu primeiro uso ao vivo apoiou análises privadas para sistemas de notificação de exposição à COVID-19 em dezembro de 2020. O serviço foi renomeado para Divvi Up em dezembro de 2021 e posteriormente expandido para telemetria de navegador, direitos humanos e aplicativos.

Este modelo difere do Let's Encrypt. Os assinantes de certificados não pagam ao ISRG, enquanto o Divvi Up convida as organizações a discutir pilotos pagos e serviço de produção. O produto combina protocolos abertos, a implementação de código aberto Janus e um agregador operado por uma organização sem fins lucrativos com um relacionamento comercial. Essa receita pode apoiar a missão, mas também cria expectativas em torno de confiabilidade, governança de dados, níveis de serviço e suporte ao cliente.

A principal proposta do Divvi Up não é que a coleta de dados se torne livre de riscos. É que os aplicativos podem decidir antecipadamente qual agregado precisam e evitar a construção de um repositório central de medições individuais em texto simples. Essa restrição reduz a flexibilidade analítica futura, mas também remove uma fonte significativa de risco de privacidade e violação de dados.

A privacidade depende da implantação completa, não de um protocolo

O Divvi Up combina várias camadas que resolvem problemas diferentes. As Funções de Agregação Distribuída Verificáveis (VDAFs) definem como uma medição é dividida, validada e agregada. O Prio3 suporta contagens, somas e histogramas gerais, enquanto outras famílias visam tarefas mais especializadas. A verificação é importante porque um cliente mal-intencionado não deve ser capaz de enviar valores malformados que corrompam o agregado final.

O Protocolo de Agregação Distribuída (DAP) coordena o upload de relatórios, trabalhos de agregação, comunicação entre o líder e o ajudante, coleta e tratamento de erros. No corte da pesquisa, o DAP era o Internet-Draft 19, datado de 6 de julho de 2026, enquanto o VDAF era um rascunho do IRTF, versão 20, datado de 24 de junho de 2026. Esses eram esforços de padrões ativos, e não RFCs finais, portanto os formatos de transmissão e a semântica podem continuar mudando.

O Janus é a implementação Rust do DAP do ISRG e alimenta o Divvi Up. Ele permaneceu em desenvolvimento ativo e suportava VDAFs com parâmetros de agregação triviais, incluindo Prio3. Não suportava todos os esquemas, incluindo aqueles com parâmetros não triviais, como o Mastic. Uma organização, portanto, precisa avaliar a implementação em relação à medição exata de que precisa.

O DAP protege o conteúdo dos relatórios durante a agregação, mas não oculta automaticamente os metadados de rede. Um agregador ainda pode ver o endereço IP do cliente, o horário da solicitação e a participação na tarefa. O HTTP Oblivious (OHTTP) pode colocar um retransmissor independente entre o cliente e o agregador, permitindo que o retransmissor veja a conexão, mas não o conteúdo criptografado do destino, enquanto o agregador vê o relatório sem a identidade de rede original. O retransmissor e o agregador devem permanecer operacionalmente separados.

A agregação distribuída também não pode evitar todas as inferências do resultado. Consultas em grupos muito pequenos ou consultas sobrepostas repetidas podem revelar informações, mesmo quando os relatórios individuais nunca foram expostos. A privacidade diferencial pode adicionar ruído controlado, limitar consultas e rastrear um orçamento de privacidade, ao custo da precisão estatística.

Esses controles não devem ser resumidos em uma única afirmação. Uma implantação pode usar DAP sem OHTTP ou agregação privada sem privacidade diferencial. A propriedade final de privacidade depende da versão do protocolo, independência do agregador, separação do retransmissor, tamanho do lote, política de consulta, implementação criptográfica e controles organizacionais. O Divvi Up fornece uma arquitetura e um serviço, mas cada cliente deve definir o modelo de ameaça que está tentando abordar.

Existem evidências de produção, mas o mercado permanece restrito

A primeira fase operacional do Divvi Up estava vinculada à análise de notificação de exposição. O ISRG relatou que o serviço havia processado mais de 40 bilhões de métricas até 2022. O número é relatado pela organização, mas mostra que a agregação distribuída operou além de um protótipo de laboratório.

As implantações posteriores são mais reveladoras. A Horizontal tornou-se o primeiro assinante de produção anunciado publicamente, usando o serviço em aplicativos ligados a direitos humanos e comunicações sensíveis. A Mozilla usa um agregador operado pelo ISRG juntamente com um agregador operado pela Mozilla para telemetria do Firefox. Esse arranjo reflete o modelo de não conluio, porque duas organizações processam compartilhamentos separados e nenhuma deve receber a medição original.

O ISRG também identifica a Tinfoil e uma integração de protótipo com o ecossistema de aprendizado federado Flower. O trabalho com a Flower sugere um papel potencial em sistemas de aprendizado de máquina que precisam de informações em nível de população sem centralizar dados locais. Continua sendo um protótipo, e não uma evidência de um mercado de produção maduro.

Esses exemplos mostram por que a medição privada é mais atraente onde a telemetria convencional cria um risco de confiança excepcional. Navegadores observam comportamentos sensíveis do usuário, aplicativos de direitos humanos podem colocar usuários em perigo se os dados forem expostos e sistemas de saúde pública precisam de estatísticas populacionais sem criar registros de movimento centralizados. O aprendizado federado pode se beneficiar de sinais agregados sem coletar exemplos brutos.

A arquitetura também muda o gerenciamento de produtos. Uma equipe de análise convencional pode coletar eventos detalhados e decidir posteriormente quais consultas executar. O Divvi Up exige que a equipe escolha uma função de agregação, defina o lote, estabeleça limites de privacidade e aceite que detalhes não coletados não possam ser recuperados. A tecnologia, portanto, limita a curiosidade organizacional, além de proteger os dados.

As evidências públicas de clientes permanecem incompletas. O ISRG não divulgou um censo completo de assinantes, volume de tráfego, registro de nível de serviço ou estudos de caso detalhados para cada implantação. Firefox e Horizontal são sinais de produção significativos, mas não estabelecem ampla adoção no mercado. O próximo estágio será determinado pelo fato de mais organizações aceitarem o custo de integração em troca da redução da exposição de dados.

A infraestrutura de privacidade paga ainda não provou sua economia

O Divvi Up complica as descrições do ISRG como totalmente apoiado por doações. Seu site oferece pilotos pagos e serviço de produção, enquanto os preços permanecem privados. Nos números não auditados do ISRG de janeiro a outubro de 2025, o Divvi Up representou 9% da receita e 19,2% das despesas.

Essas porcentagens não estabelecem rentabilidade. O relatório não divulgou a alocação subjacente em dólares, o tratamento de despesas gerais compartilhadas, a concentração de clientes ou o valor do financiamento restrito de bolsas que apoia o projeto. Uma participação de 9% na receita pode indicar diversificação útil sem cobrir o custo total de operação e desenvolvimento do serviço.

O modelo comercial tem vantagens práticas. O pagamento pode alinhar a capacidade do serviço à demanda do cliente e reduzir a dependência de bolsas anuais. Um contrato de produção cria feedback direto sobre confiabilidade, integração e suporte, enquanto financia a engenharia de protocolo que beneficia o ecossistema aberto.

Também cria tensões. Uma organização sem fins lucrativos precisa decidir quais recursos atendem a um cliente pagante e quais avançam o padrão público. A precificação privada torna o acesso ao mercado mais difícil de avaliar, e um pequeno número de grandes assinantes pode se tornar operacionalmente ou financeiramente influente. O design de dois agregadores também pode exigir cooperação com outro provedor confiável, tornando o serviço mais difícil de vender como uma solução de fornecedor único.

O Divvi Up é, portanto, um teste para saber se a privacidade pode ser vendida como uma propriedade de infraestrutura, e não adicionada posteriormente como um recurso de conformidade. Suas alternativas incluem análise centralizada, sistemas internos de computação segura, privacidade diferencial local e a decisão de não coletar uma métrica.

Um serviço financeiramente significativo poderia dar ao ISRG uma receita recorrente ligada ao valor direto para o cliente. Um serviço especializado que permanece dependente de subsídios ainda poderia ser estrategicamente útil se avançar os padrões e habilitar aplicativos de alto risco. As evidências atuais não suportam a escolha entre esses resultados. As medidas relevantes são usuários de produção pagantes, estabilidade do protocolo, revisão de privacidade independente, confiabilidade operacional e uma contabilidade mais clara de como a receita apoia a missão mais ampla.

A identidade digital ainda é pesquisa, e não um serviço operacional

A pesquisa atual do ISRG estende seu interesse em privacidade da telemetria de máquina para credenciais humanas. Está desenvolvendo uma implementação Rust de código aberto do Longfellow, um sistema de prova de conhecimento zero associado ao Google. O trabalho está sendo conduzido com a SIROS Foundation e pretende apoiar um backend de PKI para o esforço europeu de identidade digital conhecido como wwWallet.

O objetivo é a divulgação seletiva. Um usuário poderia provar uma declaração sobre uma credencial existente, como estar acima de um limite de idade ou possuir uma licença, sem apresentar todos os campos da credencial. As provas de conhecimento zero podem reduzir a quantidade de dados pessoais que os verificadores recebem e retêm.

Isso permanece como trabalho de pesquisa e implementação, e não como um serviço de identidade maduro do ISRG. O sistema depende de emissores de credenciais, carteiras, software de verificação, registros de confiança, sistemas de revogação e padrões fora da organização. Uma prova criptográfica pode estabelecer que uma credencial assinada contém uma propriedade, mas não pode estabelecer se o emissor original conduziu um processo de identidade sólido.

O trabalho também introduz uma consideração pós-quântica porque os tempos de vida das credenciais podem exceder os dos certificados da web. O programa Merkle Tree Certificate do ISRG e a pesquisa Longfellow, portanto, abordam diferentes partes de uma transição mais ampla. Um diz respeito à autenticação de servidor em escala de internet; o outro, à divulgação mínima de credenciais humanas.

A identidade poderia eventualmente se tornar outro projeto operacional, mas as evidências disponíveis não mostram que essa decisão foi tomada. A descrição prudente é uma área de pesquisa emergente com uma implementação de prova de conceito e um relacionamento de integração planejado. Sua relevância está na tese institucional que reflete: onde a infraestrutura de confiança coleta dados excessivos ou impõe custos desnecessários, sistemas criptográficos abertos e um operador de benefício público podem ser capazes de mudar o padrão.

Um pequeno Conselho supervisiona vários sistemas de alta consequência

O Conselho público atual do ISRG lista oito diretores: Josh Aas, Vicky Chin, Jennifer Granick, J. Alex Halderman, Pascal Jaillon, David Nalley, Erica Portnoy e Christine Runnegar. Suas afiliações conectam a organização com o próprio ISRG, Mozilla, Universidade de Michigan, OVHcloud, Amazon, EFF e experiência jurídica ou política independente. Christine Runnegar foi identificada como Presidente do Conselho no relatório anual de 2025, enquanto a página atual do Conselho a mantém como diretora sem reafirmar os títulos de diretoria.

A lista mudou após o relatório anual. Richard Barnes, da Cisco, e Aanchal Gupta estavam entre os dez diretores listados no relatório, mas não apareciam mais na página ativa. Nenhum anúncio público de saída ou data exata de efetivação foi identificado. Essa ausência não implica má conduta, mas mostra uma lacuna de transparência: a composição atual é visível enquanto o momento e as razões das transições podem não ser.

Josh Aas permanece como Diretor Executivo. O relatório de 2025 também identificou liderança em finanças, jurídico, desenvolvimento, pessoas e engenharia, embora muitos funcionários tenham sido apresentados apenas pelo primeiro nome. O ISRG é remoto e distribuído, e seus endereços em São Francisco e Minneapolis servem para funções legais ou de correspondência, em vez de indicar um grande local de operações central.

Os controles externos reforçam a governança interna. O Let's Encrypt publica políticas de certificados e declarações de práticas, passa por auditorias WebTrust, relata incidentes e opera sob os requisitos do programa de raiz. O software de código aberto e a participação em padrões tornam as decisões técnicas visíveis. Esses mecanismos não substituem a responsabilidade do Conselho, mas criam públicos independentes que podem contestar erros.

O modelo de equipe pequena continua sendo um risco material. A experiência em operações de CA, HSMs, criptografia, padrões e confiabilidade pode estar concentrada entre relativamente poucas pessoas. O crescimento do portfólio também pode puxar a capacidade jurídica, de engenharia, financeira e operacional em diferentes direções. A supervisão do Conselho, portanto, precisa avaliar se a organização pode apoiar vários sistemas de alta consequência sem criar dependências ocultas de uma única pessoa ou de serviços compartilhados.

O ISRG coordena relacionamentos sem possuir o ecossistema

A rede de relacionamentos do ISRG é extensa, mas os mecanismos diferem. Mozilla, EFF e a Universidade de Michigan pertenciam à coalizão fundadora. Cisco e Akamai forneceram financiamento ou infraestrutura iniciais, enquanto a IdenTrust forneceu a certificação cruzada. Empresas de navegadores e sistemas operacionais, incluindo Apple, Google e Microsoft, atuam como partes interessadas do programa de raiz ou da parte confiável. Nenhuma delas é proprietária do ISRG.

Os relacionamentos com padrões também são distribuídos. A Internet Engineering Task Force (IETF) produziu o ACME como RFC 8555 e o ARI como RFC 9773, enquanto o DNS-PERSIST-01 permaneceu como rascunho. O grupo de trabalho IETF Privacy Preserving Measurement desenvolve o DAP, a Internet Research Task Force (IRTF) desenvolve o VDAF e o CA/Browser Forum define os requisitos de linha de base para certificados TLS públicos. O ISRG participa e implementa, mas não controla esses órgãos unilateralmente.

O Prossimo funciona por meio de financiadores, contratados e custódios downstream. AWS, Sovereign Tech Agency, Alpha-Omega, Google, Cisco, Cloudflare, Shopify e ICANN apoiaram iniciativas, enquanto Ferrous Systems e Tweede Golf realizaram trabalhos de engenharia. A Rust Foundation hospeda o Rustls, e a Trifecta Tech Foundation é custódio dontpd-rs. A adoção dosudo-rspela Canonical é um relacionamento de distribuição, e não uma aquisição ou transferência de controle para o ISRG.

O Divvi Up depende de outro conjunto de instituições. A Mozilla é assinante e operadora do segundo agregador do Firefox, enquanto a Cloudflare contribui para o trabalho de protocolo relacionado. O Open Technology Fund, a Ford Foundation, a Internet Society Foundation, a Meta e outros apoiadores financiaram a medição de privacidade. A Horizontal é um usuário de produção, e a SIROS com o wwWallet conecta a pesquisa de identidade emergente ao ecossistema europeu de identidade digital.

A habilidade institucional do ISRG é coordenar sem reivindicar a propriedade. Ele pode fornecer capacidade jurídica, captação de recursos, engenharia, operação de serviço ou participação em padrões enquanto outra entidade controla o navegador, a zona DNS, a distribuição, o projeto de software ou o segundo agregador. Isso reduz a concentração vertical, mas depende do alinhamento contínuo. Cada relacionamento, portanto, deve ser entendido por seu mecanismo: financiamento, decisão de confiança, implementação, governança, uso do serviço ou autoridade de padrões.

A recuperação financeira não elimina a volatilidade do financiamento

A receita do ISRG cresceu de aproximadamente US$ 100.400 em 2014 para US$ 9.563.960 em 2024. Seu Formulário 990 de 2024 relatou US$ 7.925.896 em despesas, uma variação positiva de US$ 1.638.064 e ativos líquidos no final do ano de US$ 5.110.071. Os ativos totais eram de US$ 6.887.136 e os passivos de US$ 1.777.065. A reserva é significativa para uma pequena organização sem fins lucrativos, mas modesta em relação às consequências dos serviços que opera.

O padrão anual é irregular. A receita aumentou até 2022, atingindo cerca de US$ 8,08 milhões, antes de cair para US$ 5,16 milhões em 2023, enquanto as despesas atingiram US$ 7,81 milhões. O déficit resultante de US$ 2.651.888 reduziu os ativos líquidos para US$ 3,39 milhões. A receita se recuperou fortemente em 2024 e devolveu a organização ao superávit.

A volatilidade reflete um modelo baseado em patrocínios, contribuições e bolsas, e não em taxas de uso do Let's Encrypt. O gráfico não auditado do ISRG de janeiro a outubro de 2025 atribuiu 40% da receita a patrocínios, 24% a bolsas, 23% a contribuições, 9% ao Divvi Up e 4% a juros e dividendos. As despesas foram alocadas 50,8% para o Let's Encrypt, 19,2% para o Divvi Up, 12,3% para desenvolvimento, 11% para operações e administração e 6,8% para o Prossimo.

Os números mostram que a captação de recursos faz parte da operação da infraestrutura, e não uma sobrecarga discricionária. O desenvolvimento consome recursos porque o serviço de certificado gratuito não tem relacionamento de cobrança com o assinante. Também mostram um modelo de receita mais misto: o apoio filantrópico permanece central, mas o Divvi Up e a receita de investimentos tornam as alegações de que o ISRG é financiado apenas por generosidade muito simplistas em um sentido contábil.

O registro de 2024 relatou US$ 352.850 em remuneração reportável e US$ 44.856 em outra remuneração para o Diretor Executivo Joshua Aas. Essas categorias regulatórias não são idênticas ao salário base e devem ser interpretadas dentro das regras de divulgação do Formulário 990. Sua relevância está na visibilidade pública da remuneração em uma organização cujos orçamentos de projetos individuais permanecem menos claros.

As maiores questões financeiras não resolvidas dizem respeito à concentração e alocação. O ISRG não publica a concentração de patrocinadores, contas auditadas autônomas para cada projeto ou valores exatos em dólares por trás do gráfico percentual de 2025. Um serviço global pode parecer saudável no nível organizacional enquanto um projeto permanece subfinanciado ou um patrocinador é excepcionalmente importante. A resiliência, portanto, precisa ser avaliada em relação ao custo de substituição, capacidade de resposta a incidentes e dependência de suporte em espécie, e não apenas se o último ano produziu um superávit.

O portfólio testa se uma instituição pode apoiar vários bens públicos

Em todos os seus projetos, o ISRG segue um método consistente. Ele identifica um problema de segurança ou privacidade que os incentivos convencionais de produto não resolveram, trabalha por meio de padrões abertos e implementações de código aberto, levanta financiamento alinhado à missão, opera infraestrutura onde um serviço neutro é necessário e busca adoção além da organização.

O Let's Encrypt é a forma madura do modelo: um serviço global gratuito com raízes públicas, auditorias, um protocolo aberto e um amplo ecossistema de clientes. O Prossimo é a forma de financiamento e adoção: o ISRG não opera todos os componentes resultantes, mas paga pelo caminho do código mais seguro à implantação real. O Divvi Up é um híbrido, combinando protocolos criptográficos abertos e software com um serviço pago. A identidade digital permanece exploratória.

Essa abordagem pode resolver lacunas de coordenação e financiamento. Pode reduzir as barreiras de acesso, reduzir o aprisionamento proprietário e fornecer um operador confiável onde os mercados, de outra forma, centralizariam dados ou cobrariam por uma função básica de confiança. Também pode alinhar os financiadores em torno de infraestrutura compartilhada, em vez de incentivar várias implementações privadas incompatíveis.

Não pode remover a dependência. O Let's Encrypt depende de programas de raiz, DNS, BGP, Certificate Transparency, data centers e automação do assinante. O Prossimo depende de mantenedores, distribuições de software e lares de projeto de longo prazo. O Divvi Up depende de agregadores independentes, padrões em evolução, retransmissores, integração do cliente e governança de consulta. O trabalho de identidade depende de emissores, carteiras e sistemas verificadores.

O status de benefício público também não pode substituir a disciplina de escala. Cada projeto adicional cria demandas sobre a capacidade jurídica, financeira, de engenharia e de governança. Uma pequena organização pode lançar infraestrutura com eficiência por meio da automação, mas a resposta a incidentes, a transferência de conhecimento e a sucessão não escalam tão barato quanto o tráfego de rotina. O ISRG corre o risco de se estender demais se interpretar cada tecnologia promissora de interesse público como um mandato para operar outro serviço permanente.

O significado de longo prazo da organização, portanto, depende da seletividade. Ela deve distinguir projetos que exigem um serviço operado pelo ISRG daqueles que são mais bem apoiados por meio de bolsas, trabalho de padrões ou transferência para outra fundação. A versão mais forte do modelo não é um conglomerado sem fins lucrativos em constante expansão, mas uma instituição que sabe quando operar, quando financiar e quando entregar a responsabilidade para outro lugar.

A infraestrutura de interesse público ainda cria poder concentrado

O ISRG mudou as suposições em torno de várias camadas de infraestrutura. O Let's Encrypt tornou a criptografia um padrão esperado, em vez de um produto premium. O ACME tornou a automação do ciclo de vida do certificado parte da operação normal do software. A validação de múltiplas perspectivas conectou a emissão de certificados à diversidade de roteamento, o Sunlight tratou os dados estáticos verificáveis como uma alternativa a sistemas de registro complexos, o Prossimo transformou a defesa da segurança de memória em adoção financiada e o Divvi Up tornou a telemetria não centralizada disponível como um serviço.

O fio condutor é a redução da concentração de confiança desnecessária. Um operador de site não deve precisar de um relacionamento comercial manual para criptografar o tráfego. Uma implementação mais segura não deve falhar porque cada beneficiário espera que outro financie a compatibilidade. Um serviço de análise não deve receber todas as medições individuais quando apenas um agregado é necessário. Um verificador de credenciais não deve receber todos os campos pessoais quando um predicado é suficiente.

No entanto, o próprio ISRG se torna um ponto de concentração. Sua CA assina certificados para uma vasta população, suas escolhas de serviço influenciam as práticas operacionais e suas decisões de financiamento podem afetar quais substituições de código aberto avançam. A infraestrutura de benefício público não elimina o poder; ela muda os incentivos, controles e mecanismos de revisão por meio dos quais esse poder é exercido.

Os operadores devem, portanto, tratar os serviços do ISRG como dependências de produção, em vez de conveniências de fundo. Chaves de conta ACME, clientes de renovação, registros DNS, instalação de certificados, consumo de CRL e monitoramento de incidentes pertencem ao gerenciamento de risco comum. O Divvi Up exige um modelo de privacidade explícito e processadores genuinamente separados. As substituições financiadas pelo Prossimo exigem a mesma avaliação técnica e operacional de qualquer outro componente de infraestrutura.

Para formuladores de políticas e financiadores, o ISRG mostra que uma pequena organização sem fins lucrativos pode criar bens públicos globais quando software, padrões e automação produzem alavancagem. Esse modelo merece apoio porque os benefícios são amplamente compartilhados. O apoio deve ser acompanhado por uma divulgação mais clara dos custos do projeto, reservas, concentração de patrocinadores, sucessão do Conselho e capacidade de resposta a incidentes.

A conquista mais importante da organização não é o número de certificados emitidos ou iniciativas financiadas. É se a infraestrutura pode se tornar comum, permanecendo aberta, confiável, substituível e resiliente. Quanto menos visíveis se tornarem os serviços do ISRG no uso diário, mais consequente se torna a instituição por trás deles.