Resumo

  • O endereço Onion v3 incorpora a chave pública de identidade do serviço e não depende de delegação DNS; responder pela rede não basta para provar seu controle.
  • onion-csr-01 usa uma CSR de validação assinada pela identidade Onion, vinculada aos nonces da CA e do solicitante e separada da CSR do certificado.
  • Em serviços restritos, a CA recebe uma chave de acesso própria e só depois pode ler CAA no descritor; alternativamente, o cliente apresenta um conjunto assinado e temporário no finalize.

A CA não ganha visibilidade por default

Um Onion Service pode ser conhecido e, ainda assim, revelar seu descritor interno apenas a clientes autorizados. Essa separação é central para a RFC 9799. A CA precisa provar que viu a política certa sem transformar o próprio mecanismo de validação em um novo identificador permanente do operador.

O ponto de partida é o nome. A RFC 7686 coloca .onion fora do DNS normal. No formato v3, a sequência de caracteres codifica a chave pública Ed25519 de identidade, checksum e versão. A RFC 9799 reutiliza o identificador ACME dns, mas apenas como recipiente compatível. A autoridade não vem de um registrador nem de uma delegação.

Por isso, dns-01 não pode ser usado. http-01 e tls-alpn-01 são aceitos com mudanças: a própria CA deve conectar ao serviço por Tor, sem Tor2Web, e lidar com autenticação restrita. Essas formas verificam um ponto de atendimento e não emitem wildcard.

Quando é necessária prova direta da raiz do nome, entra onion-csr-01. A CA envia um nonce de pelo menos 64 bits de entropia; respostas baseadas em um nonce gerado há mais de trinta dias devem ser rejeitadas. O cliente cria uma CSR especial, inclui os bytes crus em caSigningNonce, acrescenta seu applicantSigningNonce de pelo menos 64 bits e assina com a chave privada Onion.

A CA verifica formato PKCS#10, correspondência entre chave e nome, assinatura, igualdade do nonce e entropia do nonce do solicitante. O subject não tem valor probatório. A chave pública dessa CSR deve ser diferente da chave da CSR final.

Assim, a conta ACME autentica mensagens; a identidade Onion prova o nome; a chave final recebe o certificado. O desafio dispensa o key authorization tradicional porque a CSR de validação já está dentro de uma solicitação ACME assinada pela conta.

Uma chave da CA para cada serviço

O authKey opcional anuncia a chave pública Ed25519 que a CA pretende usar para obter o descritor. A mesma chave não pode aparecer em Onion Services diferentes, embora possa voltar numa revalidação do mesmo serviço. A regra evita que a credencial de acesso conecte identidades que o operador queria manter apartadas.

A CA calcula seu CLIENT-ID e busca a linha auth-client correspondente. Não existe um bit independente que declare a autenticação obrigatória; sem correspondência, ela deve presumir que a restrição não é exigida. Se o authKey for novo, o operador o inclui, assina novamente o descritor e republica.

A propagação tem duração indeterminada. O texto espera poucos minutos, mas não fixa um limite; recomenda ao menos trinta minutos antes de a CA expirar o desafio. A resposta do cliente funciona como sinal de que a atualização já poderia ter sido feita. Não prova que a CA recebeu a nova revisão.

Um registro útil liga a chave anunciada à revisão, ao horário de publicação, ao identificador calculado e à primeira descriptografia bem-sucedida. Sem isso, uma demora de diretório parece uma recusa de política e provoca a correção errada.

CAA visível, invisível ou trazido pelo cliente

CAA continua decidindo qual emissor pode emitir. A RFC 9799 coloca registros no segundo nível cifrado do descritor, usando a forma canônica de RFC 8659. Não há árvore DNS para subir nem TLD .onion para consultar. Os subdomínios de um mesmo endereço-base compartilham a política.

Para uma CA ainda não autorizada, o conteúdo pode estar oculto. O marcador caa-critical no primeiro nível informa que existe CAA e impede emissão até a leitura do segundo nível. Ele fecha a operação sem divulgar a política, mas não comprova que a leitura ocorreu.

No caminho in-band, o finalize recebe onionCAA com o texto ou null, expiração Unix e assinatura Ed25519 da identidade Onion. A expiração não deveria estar mais de oito horas no futuro e requer pelo menos 64 bits. A assinatura cobre exatamente onion-caa|, a expiração decimal sem zeros iniciais, | e o texto CAA; null vira texto vazio.

Uma assinatura válida permite atribuir aquele conjunto ao serviço. A CA ainda escolhe: usar apenas o conjunto enviado, ignorá-lo e buscar o descritor, ou buscar ambos. Se não suporta a busca e o cliente não envia o objeto, responde onionCAARequired; inBandOnionCAARequired pode avisar isso no diretório ACME.

O recibo da operação precisa mostrar a escolha. Certificado emitido não revela qual conjunto controlou a decisão. Diretórios Tor são distribuidores não confiáveis, de modo que tanto o descritor quanto o objeto in-band dependem da verificação pela mesma chave Onion.

Privacidade também tem estados

A CA deve conectar por Tor diretamente. O cliente ACME também deveria usar Tor e preferir um endpoint Onion da CA. Conectar diretamente a um endereço conhecido de CA pode denunciar que o host solicitante mantém um serviço oculto.

Um redirect de http-01 para a internet pública pode expor IP e relação de hospedagem. A CA não deve validar esse destino público por uma saída Tor, pois o exit hijacking cria risco de controle falso.

Por fim, um certificado WebPKI torna o nome público nos logs de Certificate Transparency. Pode ser uma escolha legítima, mas é permanente. Serviços não públicos podem optar por confiança privada ou certificado autofirmado. Dados de assinante devem ser minimizados; contas ACME separadas são obrigatórias quando o operador não quer correlação entre serviços pela CA.

O desenho completo registra identidade, conta, prova com nonces, acesso específico, propagação observada, fonte de CAA, chave final e cada exposição. A RFC 9799 oferece regras comuns para a passagem entre estados. Ela não transforma um resultado de emissão em prova retroativa de tudo o que veio antes.

Fontes