Resumo

  • A política atual da Mozilla separa manutenção do repositório de raízes, asseguração por período e as verificações exigidas antes de informação do assinante entrar em um certificado.
  • Uma política ou auditoria anual não recompõe uma solicitação concreta, uma observação de validação, a emissão, a revogação posterior ou o resultado de um cliente.

A Mozilla Root Store Policy 3.1, em vigor desde 1º de julho de 2026, é útil justamente porque coloca lado a lado afirmações verdadeiras sem transformá-las em equivalências. A Mozilla distribui certificados de AC com bits de confiança para finalidades diferentes. Exige auditorias determinadas antes da inclusão e ao menos anualmente depois para raízes e intermediárias tecnicamente capazes sob seu escopo. Também exige que informações fornecidas pelo assinante sejam verificadas por fonte independente ou canal alternativo antes de integrar um certificado.

Para TLS, a AC deve assegurar autorização sobre os nomes de domínio e controle dos endereços IP pelos métodos documentados.

Cada afirmação tem valor. Nenhuma é recibo automático da seguinte.

Auditoria tem uma fronteira de asseguração: sistema coberto, critérios, período, método, evidência testada, achados e limitações. A política requer atualização de informações de auditoria de período ao menos anualmente. Para períodos anuais iniciados em 1º de julho de 2027 ou depois, prevê também um Detailed Controls Report para certas ACs com bit de confiança para websites. O relatório se destina a explicar limites de sistema, controles, implementação, testes e eficácia operacional. É evidência institucional importante, não um livro-razão de cada pedido nem a prova contemporânea de uma emissão.

Isso fica claro ao olhar um certificado. Número de série, emissor, validade e nomes alternativos descrevem um objeto. Não dizem qual pedido chegou, qual versão de procedimento valia, qual pessoa ou controle automatizado tinha competência, o que a fonte independente observou, se a observação estava dentro da janela permitida, ou por que uma chave foi ligada àqueles nomes. Uma opinião de auditoria não cria essas ligações ausentes apenas por existir.

A substituição inversa também é fraca. Um registro de emissão pode provar que um objeto foi criado, mas não que o ambiente inteiro de controle operou em todo o período, que todos os locais entraram no escopo, que nenhum fato posterior ocorreu ou que cada distribuição derivada conservou o mesmo tratamento de raiz. A política diz que distribuidores de software baseado no da Mozilla podem adicionar, remover ou alterar certificados e bits de confiança. Ela governa o conjunto padrão distribuído pela Mozilla, não toda compilação possível.

Emitir tampouco é aceitar depois. A documentação NSS separa blocos de certificado e blocos de confiança; uma raiz é o certificado mais suas configurações de confiança. O cliente ainda constrói e avalia um caminho conforme seu software e seu contexto local. Nome de host, hora, extensões, construção de cadeia, informação de revogação, uso na aplicação e o serviço observado na conexão são perguntas distintas. Isto não afirma falha de cliente algum; apenas limita o que a auditoria ou o arquivo da AC pode provar sem evidência do lado do cliente.

O remédio prático é um recibo de evidência de emissão com limites. Sob proteção, ele deve guardar identificador da solicitação; nomes pedidos e impressão da chave; versão de regra e procedimento; agente autorizado ou controle automático; observação independente e janela temporal; depois, série, emissor, validade, extensões pertinentes e instante de emissão. A revogação posterior deve ficar em registro separado, com hora de consulta e contexto da resposta. O resultado do cliente deve ser separado de novo, com versão ou limite de política, host, cadeia e hora, sem coletar dados desnecessários do usuário.

Não se pede publicação de provas de controle de domínio, dossiês de cliente ou detalhes defensivos. Pede-se que uma afirmação não ocupe o lugar de outra. Evidência sensível pode ser revista sob autoridade adequada. O que precisa sobreviver é o mapa dos vínculos: qual decisão sustentou qual objeto, sob qual regra, e qual observação posterior é realmente invocada.

Limites da evidência

As fontes não nomeiam AC, assinante, certificado, opinião de auditoria, DCR, incidente ou evento de parte confiável. Não demonstram descumprimento. O recibo é análise editorial, não requisito da Mozilla, CA/Browser Forum, NSS ou RFC.

Fontes

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS: Updating NSS’s Root Store
  3. RFC 5280