Resumo

  • A revisão 02 permite que a autoridade certificadora compare o registro persistente com a impressão JWK SHA-256 de qualquer chave pública usada pela conta ACME durante sua existência.
  • A antiga chave privada deixa de autenticar novos pedidos, mas sua impressão ainda pode sustentar a autorização. Remover o TXT, expirar o cache, reduzir persistUntil e terminar a reutilização são eventos separados.
  • Desativar a conta é a interrupção imediata em todo o seu alcance. Até lá, o operador precisa de um recibo com geração da chave, observação DNS, CAA, estado da conta e prazo de reutilização.

Uma troca de chave bem-sucedida pode encerrar o segredo e preservar o poder. Esse é o paradoxo operacional exposto pela revisão 02 do ACME DNS Persistent Challenge: a CA pode continuar usando validação obtida antes da troca ou do desaparecimento do TXT.

Publicada em 20 de setembro de 2026, a revisão permanece em I-D Exists no histórico do Datatracker. É um Internet-Draft ativo do grupo de trabalho. O cabeçalho diz Standards Track, mas não há intended status, shepherd, diretor de área nem etapa do IESG registrados. Não é RFC, Last Call ou prova de implantação por qualquer CA.

O mecanismo usa um TXT sob _validation-persist. O valor reúne dns-persist-01, uma impressão JWK SHA-256 com 43 caracteres em base64url sem preenchimento e um hash que liga domínio, impressão e URL da conta. A impressão segue a RFC 7638; a representação do hash, a RFC 6920.

A CA calcula primeiro com a chave atual. Se não houver correspondência, percorre as chaves públicas históricas da conta, da mais recente para a mais antiga. O diff entre 01 e 02 exige que um servidor compatível retenha a impressão de toda chave pública usada, por toda a vida da conta. O repositório do grupo ACME mostra a elaboração, não uma política implantada.

Há uma justificativa útil. A RFC 8555 permite trocar a chave da conta. Se o registro persistente aceitasse somente a chave corrente, a manutenção normal obrigaria a equipe DNS a refazer a delegação. O servidor guarda material público, não a antiga chave privada. A impressão reconhece a origem da permissão; não assina um novo pedido.

Essa continuidade deixa autoridade residual. Uma validação obtida com K1 continua ligada à mesma conta válida depois da passagem para K2. Se uma nova consulta for necessária, o TXT de K1 ainda pode corresponder ao histórico. Portanto, trocar quem autentica o pedido não retira automaticamente a concessão publicada no DNS.

A remoção do TXT também tem atraso. Resolvedores recursivos podem servir a resposta até o TTL vencer. O rascunho distingue TTL de janela de reutilização: o primeiro governa cache; a segunda, quanto tempo a CA confia em dados já validados. persistUntil impõe um teto na validação, mas apagar o registro ou encurtar o valor depois não reduz retroativamente uma autorização já adquirida.

Quatro relógios precisam aparecer no controle: chave ativa da conta; publicação autoritativa e caches; expiração da autorização ACME; e limite persistUntil capturado na observação. Um painel que mostra apenas “chave trocada” ou “TXT ausente” informa o estado atual, não o poder ainda exercitável.

O rascunho oferece uma parada imediata: desativar a conta ACME. A CA deve confirmar que ela permanece válida, e a desativação prevalece sobre o histórico de chaves. É uma ação ampla, que interrompe a conta inteira, enquanto apagar um TXT pretende retirar um domínio. O plano de incidente precisa saber quando usar cada uma.

Por padrão, o domínio participa do hash. Com domain_name=*, o mesmo valor pode ser usado em vários domínios da conta e chave. O ganho de operação amplia correlação e raio de impacto. O recibo de emissão deve registrar o identificador e o alcance de curinga exatos.

CAA continua independente. O accounturi da RFC 8657 usa a URL real; o TXT persistente inclui essa URL no hash. A correspondência do TXT não substitui CAA, e CAA não comprova a autorização persistente.

DNSSEC autentica a resposta, não a intenção presente. O texto recomenda validá-lo quando disponível e falhar se a validação tentada falhar. A RFC 4033 delimita a integridade e origem fornecidas. Ainda resta decidir se uma resposta em cache continua desejada e se a conta deve permanecer ativa.

O pré-provisionamento pode ser delegado. Depois que um POST-as-GET autenticado confirma a conta válida, outra parte recebe URL pública e impressão para montar o TXT, sem a chave privada. Essa separação entre equipe DNS e controladora ACME exige registrar quem solicitou, aprovou e instalou a concessão.

Os registros ACME da IANA ainda não listam dns-persist-01. A votação SC-088v3 do CA/Browser Forum documenta apoio setorial a um método TXT persistente vinculado à conta. Isso não prova adoção desta revisão nem equivalência entre os regimes.

O artefato correto é um recibo da vida da autorização: FQDN e escopo; hash e hora; respostas autoritativa e recursiva; TTL e horizonte de cache; emissor; uso de domain_name=*; conta protegida; geração atual ou histórica que coincidiu; estado ao vivo; CAA e DNSSEC; persistUntil; expiração da autorização; pedido e emissão que consumiram o resultado.

Com isso, uma auditoria separa rotação com correspondência histórica, remoção com cache sobrevivente, reutilização sem nova consulta e desativação anterior à emissão. Sem isso, tenta-se explicar uma decisão de ontem consultando apenas o DNS de hoje.

O texto ainda pode mudar. A fronteira de governança já está posta: persistência transfere autoridade de uma prova ao vivo para uma história administrada. Rotação é manutenção. Retirada exige atingir a autorização que continua vigente.

Fontes