Resumo

  • accounturi liga uma propriedade CAA reconhecida à conta solicitante, e validationmethods limita os métodos; a URI identifica uma conta, mas não é o segredo que a controla.
  • O suporte é opcional e específico da CA. Se vários sistemas usam o mesmo domínio identificador, todos devem reconhecer os parâmetros de forma consistente ou adotar identificadores separados.
  • Autorizações CAA são aditivas, e uma política mais restrita hoje não revoga certificados emitidos durante uma alternativa ou janela permissiva anterior.

Para compras, uma única conta de emissão parece uma economia evidente. Há menos relações para inventariar, menos exceções para explicar e uma política DNS que cabe numa revisão. Para a equipe que responde pelas renovações, a mesma decisão concentra outra coisa: recuperação de conta, colisões de identificador, mudanças de método e o custo de manter sistemas antigos compatíveis.

RFC 8659 situa o limite. CAA diz se uma autoridade certificadora está autorizada a emitir para os nomes pedidos naquele momento. A busca acompanha aliases na consulta CAA, sobe até o primeiro RRset não vazio e verifica cada nome da solicitação. Ela não instrui o cliente a invalidar um certificado existente; alterar o DNS depois não equivale a revogar.

RFC 8657 acrescenta accounturi. Quando a CA reconhece o parâmetro, a propriedade issue ou issuewild só autoriza a conta identificada pela URI da solicitação, além de exigir a correspondência do domínio identificador da CA. Sem o parâmetro, qualquer conta pode satisfazer aquela propriedade. URI inválida, não reconhecida ou repetida torna a propriedade incapaz de autorizar.

A URI de conta é pública. Ela não contém necessariamente a credencial, e conhecê-la não prova controle do account key. Uma implementação ACME que suporta a extensão reconhece a URI do objeto de conta; um sistema não ACME pode atribuir outra URI. Também não há portabilidade automática: uma identificação válida numa CA não vira autoridade noutra.

validationmethods reduz a escolha de validação aos nomes aceitos na lista. Lista vazia não autoriza método algum. Rótulos ACME estão em registro, mas um método não ACME pode precisar de um rótulo definido pela própria CA. O suporte não nasce da sintaxe; o emissor precisa declarar que reconhece o parâmetro e seus valores.

A documentação pública mostra como esse compromisso pode ser delimitado. Let's Encrypt informa letsencrypt.org, seu formato de URI de conta e o reconhecimento de http-01, dns-01 e tls-alpn-01. É evidência do que o serviço afirma suportar, não auditoria independente de todas as rotas nem prova de adoção universal.

O ponto organizacional de RFC 8657 é direto: todos os sistemas de emissão que usam um domínio identificador de CA devem reconhecer os mesmos parâmetros de maneira consistente. O texto inclui a convivência de ACME e não ACME e a integração após fusões. Se os sistemas não puderem convergir, a CA pode usar domínios identificadores distintos. Não pode representar compatibilidade sob um nome comum enquanto uma porta mantém outra interpretação.

O inventário de contas precisa atravessar essa fronteira. As URI devem ser inequívocas em todos os domínios identificadores reconhecidos por uma CA, inclusive quando namespaces são unidos. Dois sistemas que possuem a “conta 1042” precisam conservar a origem; uma URI com componente de autoridade ajuda. Isso não obriga CAs independentes a compartilhar cadastro.

Uma conta central, porém, não basta para tornar o RRset restritivo. CAA soma autorizações. Outra propriedade aplicável pode autorizar a mesma CA sem accounturi ou sem método. Para curingas, issuewild prevalece quando existe e issue é ignorado; para nomes comuns, vale issue. A exceção pode estar na outra linha ou na outra classe de nome.

O bit crítico também não resolve reconhecimento de parâmetro. Ele trata de tags de propriedade desconhecidas ou não suportadas. Tornar issue crítico não força a compreensão de accounturi. A tag conhecida e o parâmetro opcional são decisões diferentes.

No tempo, validar domínio e emitir certificado podem ocorrer separadamente. Autorizações curtas e nova consulta CAA próxima da emissão são meios sugeridos para reduzir o intervalo, não garantias. O exemplo de cerca de uma hora não é prazo universal. Uma janela de contingência pode deixar certificados válidos muito além do retorno à política estrita.

A evidência necessária acompanha a dependência: nome solicitado, RRset efetivo, caminho DNS e DNSSEC, propriedade aplicável, identificador da CA, URI da conta, método, sistema emissor, instante da decisão e certificado produzido. Sem essa ligação, a centralização simplifica o painel e obscurece o ponto de falha.

Fontes

  1. RFC 8657 — Extensões CAA para URI de conta e vinculação de método ACME
  2. RFC 8659 — Registro DNS Certification Authority Authorization
  3. Let's Encrypt — Documentação de CAA
  4. Heng Lu — O problema de agência no núcleo da governança da Internet
  5. Heng Lu — Por que a BTW Media existe e por que a realidade é o produto