Resumo

  • draft-ietf-acme-pop-00 substitui o CSR final, em um fluxo opcional, por popKey, uma autorização pop e um desafio pop-01 específico da ordem.
  • A autorização não pode vir de pré-autorização, não pode ser herdada de outra ordem e não pode ser satisfeita por uma validação anterior.
  • A prova cobre SHA-256 dos bytes exatos do payload newOrder; controle do identificador continua sendo validado em autorizações separadas.
  • ML-KEM usa ciphertext novo e HMAC derivado após decapsulação. O resultado convence o servidor, mas não oferece não repúdio verificável por terceiros.
  • A revisão 00 é um Internet-Draft em evolução, não um RFC nem evidência de implementação ou implantação.

A chave pode voltar; a autorização, não

Reutilizar uma chave em renovação, hardware pré-provisionado ou pinning pode ser uma decisão válida. O rascunho não proíbe esse uso. Ele proíbe outra coisa: transportar a autorização pop de uma ordem para outra.

Em cada novo pedido, o cliente envia a chave pública no campo popKey e inclui um identificador pop de valor vazio. O servidor cria exatamente uma autorização com exatamente um desafio pop-01. Ela não pode ser obtida antes da ordem nem substituída por uma autorização antiga ainda válida.

A diferença é essencial. A posse é observada em um momento e em um contexto. Uma prova feita ontem para outra lista de nomes, outro perfil ou outro ciclo de emissão não demonstra que a mesma chave privada está disponível hoje para este pedido.

O sistema pode correlacionar o popKey entre ordens para inventário, mas deve preservar uma identidade diferente para cada prova.

O hash fixa a ordem que realmente saiu do cliente

newOrder_hash é SHA-256 dos bytes obtidos ao decodificar o payload JWS antes de analisar JSON. O servidor não pode montar um novo objeto e hasheá-lo. Entradas com chaves duplicadas ou interpretação não única devem ser rejeitadas.

No modo de assinatura, a chave privada assina um prefixo de domínio, um popNonce aleatório de 32 bytes e o hash. No modo ML-KEM, o servidor encapsula para popKey, publica challenge_ciphertext, deriva mac_key por HKDF-SHA-256 e verifica um HMAC do mesmo hash.

O vínculo impede que uma resposta capturada seja aplicada a outra ordem. O nonce ou ciphertext também muda a cada desafio. Repetir o mesmo popKey não repete o transcript.

Posse e controle do nome continuam separados

O identificador pop vazio não vai para o certificado. Ele não representa DNS, e-mail, dispositivo ou pessoa. Apenas pede que o servidor verifique a posse da chave declarada.

Os identificadores do certificado continuam com seus desafios ACME próprios. A ordem só fica pronta quando a autorização pop e todas as autorizações de identificador estão válidas. Quem controla um domínio mas não a chave não satisfaz o pedido. Quem possui a chave mas não controla o domínio também não.

Perfis, atestação de dispositivo e RATS podem compor a mesma ordem sem apagar essa divisão. Cada verificação precisa manter a sua pergunta, a sua evidência e o seu responsável.

O material efêmero precisa terminar junto com o desafio

O servidor deve destruir o popNonce armazenado ou a mac_key quando o desafio termina, a autorização entra em estado terminal, a ordem falha, a conta é desativada ou uma ordem STAR é cancelada. Um novo envio não pode ressuscitar o material consumido.

Para KEM, o segredo compartilhado bruto não deve ser persistido. Ciphertexts não podem ser reutilizados ou compartilhados entre ordens. Além do risco criptográfico, há um risco de capacidade: criar uma ordem pode forçar ML-KEM.Encaps. Limites de taxa precisam agir antes que uma enxurrada de pedidos transforme o servidor em recurso de cálculo gratuito.

O HMAC retornado mostra ao servidor que o cliente conseguiu decapsular. Como o próprio servidor conhece o segredo derivado, ele também poderia produzir a resposta. O transcript serve à decisão de emissão, mas não se torna assinatura independente do cliente.

O CSR saiu; a política da CA ficou

Depois de todas as autorizações, o finalize contém {}. A CA coloca no certificado uma chave equivalente ao popKey aceito e usa os identificadores autorizados. Os demais campos — validade, usos de chave, subject e extensões — continuam sob política da CA ou de um perfil aplicável.

A emissão ainda não prova instalação. O certificado pode não alcançar todos os endpoints, pode estar associado à chave errada ou ser recusado por um cliente. A posse verificada no desafio também não garante custódia contínua.

A exceção STAR muda o horizonte, não a regra

Dentro de uma única ordem STAR, o popKey de bootstrap persiste e a prova inicial é aproveitada nas renovações automáticas. Isso não autoriza o reúso entre ordens. Trocar a chave exige outra ordem e outra autorização.

Com KEM, a chave do certificado não pode assinar uma revogação. A chave da conta ACME passa a carregar a revogação comum e, em STAR, o cancelamento que interrompe novas emissões. Perder essa chave pode deixar a renovação em andamento até a intervenção ou o fim da ordem.

Publicada em 1º de setembro de 2026, a revisão 00 pode mudar ou expirar. Não há aqui alegação de suporte por uma CA ou cliente específico, emissão real, interoperabilidade, incidente ou adoção.