Proposta pós-quântica do ACME elimina perfil estrito

O ACME pós-quântico perdeu o modo rígido; a chave antiga fica na mão do servidor

Por que isso importa

Em junho, a proposta tinha uma regra fácil de testar: no perfil estrito, uma assinatura apenas tradicional não passava. A revisão de 28 de outubro apagou esse perfil. Agora, a autoridade que opera o servidor pode escolher os algoritmos aceitos e o prazo de convivência com a assinatura antiga. O nome “pronto para a era quântica” não diz quando a porta fecha.

Daniel Kade28 de outubro de 2026 às 22:54 UTCTempo de leitura 3 minÚltima atualização: 28 de outubro de 2026

O rascunho ACME de outubro retira o perfil rígido; o servidor decide quando parar de aceitar a assinatura antiga.

Resumo

A versão 01 de uma proposta individual para ACME elimina o perfil estrito da versão 00, que exigia assinaturas pós-quânticas ou híbridas para autenticar servidor TLS e requisições JWS, sem retorno a assinaturas tradicionais isoladas.
O novo texto permitiria deixar de implementar ES256, hoje obrigatório na RFC 8555 §6.2. Se o servidor conservar ES256, poderá aceitar JWS tradicional durante um período de transição definido por ele.

A conexão mudou; a autorização do pedido talvez não

Um operador automatiza a emissão de certificados por ACME e troca o acordo de chaves do TLS por uma opção pós-quântica ou híbrida. Isso trata do tráfego que alguém pode gravar hoje para tentar decifrar no futuro. Mas cada pedido ACME leva uma assinatura JWS da conta. O servidor ainda precisa decidir se uma assinatura antiga basta para abrir uma nova ordem de certificado. Fortalecer o transporte não toma essa decisão por ele.

A redação de junho separava claramente um perfil estrito. Nesse perfil, o servidor TLS e o cliente que assina a requisição precisavam usar assinaturas pós-quânticas ou híbridas; o retorno à autenticação puramente tradicional era rejeitado. A revisão de outubro retira a seção. Seu único mecanismo “quantum-ready” mantém TLS 1.3 ou posterior e troca de chaves pós-quântica ou híbrida em todas as conexões cobertas. O suporte à autenticação nova permanece, mas a aceitação da antiga pode continuar por uma transição explicitamente delimitada. O documento não fixa a data do corte.

O comando técnico mais importante está no §4.2. Antes, o servidor do perfil tinha de implementar variantes ML-DSA e uma assinatura composta, além de ES256. Agora ele pode aceitar algoritmos JWS registrados no catálogo JOSE, sem conjunto ou parâmetros obrigatórios. Pode até não implementar ES256. Se mantiver esse algoritmo para clientes legados, poderá aceitar suas assinaturas tradicionais pelo período que escolher. Essa liberdade ajuda a planejar a migração, mas também faz a mesma expressão “pronto para a era quântica” cobrir políticas de aceitação diferentes.

Há um ponto que precisa ser resolvido no próprio texto. A introdução chama assinaturas pós-quânticas e híbridas de obrigatórias para implementação; o §4.2 usa “MAY” e afirma não impor algoritmo JWS específico. Quem prepara testes de interoperabilidade precisa saber qual frase vira requisito de servidor. A ficha do IETF classifica o material como Internet-Draft individual atualizado em 28 de outubro. Não há nele cronograma universal nem prova de adoção em produção. Uma política publicada, acompanhada de testes que mostrem a rejeição das assinaturas antigas depois da data prometida, daria substância à promessa.

Fontes: revisão de outubro; texto de junho; RFC 8555; registro do IETF.