Crie uma lista de observação em vez de uma promessa de migração
Pós-quântico DKIM as discussões combinam diversas questões que merecem respostas separadas. A primitiva criptográfica é padronizada? Seu uso em um protocolo de correio específico está especificado em um documento aprovado? O verificador implantado entende esse formato? A rota relevante foi testada? Uma resposta positiva à primeira questão não resolve as restantes três. Uma lista de observação de padrões útil registra cada um de forma independente e deixa respostas não suportadas explicitamente desconhecidas.
Este guia revisou fontes primárias públicas em 8 de novembro de 2026. O Registro de especificação DKIM2 mostrou a revisão 09, atualizada em 1º de novembro, como um grupo de trabalho ativo para Internet-Draft. O Criptografia Pós-Quantum no registro DKIM mostrou a revisão 00, atualizada em 2 de novembro, como um rascunho individual ativo da Internet. O último registro distingue expressamente a submissão individual do endosso IETF . Nenhum dos registros estabelece uma migração de produção aprovada.
Separar as orientações DKIM estabelecidas dos formatos propostos
RFC 8301 proíbe rsa-sha1 para assinatura e verificação. Sua orientação RSA requer chaves de assinatura de pelo menos 1.024 bits e recomenda pelo menos 2.048 bits; Assinaturas RSA menores que 1024 bits não devem ser consideradas válidas. RFC 8463 adiciona Ed25519-SHA256 e especifica suporte ao verificador. Esses requisitos publicados são distintos da observação de que um determinado produto instalado realmente os cumpre.
O rascunho do PQ-DKIM1 discute opções de assinatura resistentes a quantum para a versão DKIM existente. DKIM2 é um esforço separado de desenvolvimento de protocolo com sua própria proposta de material e sintaxe assinados. Na revisão 09, sua seção criptográfica inclui o ML-DSA-44 e especifica o ML-DSA puro para esse uso. Não troque os rótulos ou exemplos de algoritmos de uma proposta DKIM1 com o rascunho DKIM2 apenas porque ambos discutem uma família matemática semelhante. Copiar uma chave proposta no DNS não resolveria essas diferenças.
Verifique o primitivo sem reivindicar uma implantação de email
NIST FIPS 204 foi publicado em 13 de agosto de 2024 e especifica ML-DSA. A página de publicação também traz um aviso de possíveis atualizações de 31 de julho de 2026. Isso estabelece um padrão criptográfico e uma consideração de manutenção; não estabelece que uma determinada ligação, implementação ou serviço de e-mail hospedado DKIM tenha sido aprovado ou testado. Este guia não analisa a correção da implementação ou o conteúdo dessa planilha de errata.
A discussão sobre ameaças diz respeito à falsificação de assinaturas, não à transformação DKIM em criptografia. Modelo publicado da DKIM associa um domínio de assinatura a uma assinatura no material de mensagem selecionado. Um novo algoritmo de assinatura não ocultaria a mensagem, não autorizaria uma solicitação comercial ou estabeleceria a identidade de um correspondente humano. Mantenha a confidencialidade, autenticação, alinhamento de domínio e segurança de conteúdo separados ao explicar por que um algoritmo futuro pode ser importante.
Torne as questões de tamanho e transporte mensuráveis
Uma chave maior levanta mais de uma questão operacional. Distinguir os bytes de chave pública, conteúdo TXT codificado, resposta DNS completa, bytes de assinatura e tamanho do cabeçalho da mensagem resultante. Um limite de cadeia de caracteres TXT não é o tamanho máximo de um registro inteiro ou de uma mensagem DNS . Por outro lado, o suporte para múltiplas strings não prova que cada caminho DNS , interface de provisionamento ou analisador de correio irá lidar com a resposta pretendida. Formato de registro do DNS é apenas parte dessa investigação.
Propor medições em vez de importar conclusões de benchmark para o ambiente da organização. Registre o resolvedor e o software autoritativo, o comportamento do transporte, as restrições de tamanho da mensagem, a carga de trabalho de assinatura e a carga de trabalho de verificação. Inclui entradas malformadas e sem suporte, não apenas um exemplo válido e conveniente. Qualquer declaração de rendimento ou latência precisa de uma configuração de teste reproduzível e resultados reais. Nenhum resultado numérico de desempenho, publicação de chave, geração de mensagem ou execução de verificador é reivindicado aqui.
Definir o que significaria o apoio demonstrado
Para uma matriz de laboratório fictícia, atribua uma linha a cada par de versão signatário/verificador e a cada transformação intermediária. A linha deve nomear o rascunho preciso da revisão, a representação do algoritmo, o comportamento esperado e as evidências ainda necessárias. Os casos planejados podem incluir uma assinatura intacta, conteúdo assinado modificado, um algoritmo desconhecido e uma chave indisponível. Rotule cada resultado não executado até que um teste autorizado produza um registro inspecionável. Não preencha células desconhecidas da declaração geral de um fornecedor sobre a prontidão pós-quântica.
A compatibilidade também precisa de uma questão política. Se múltiplas assinaturas estiverem presentes, que combinação o protocolo proposto exige e o que um receptor mais antigo realmente avaliará? Uma assinatura convencional válida não demonstra que uma assinatura PQ foi verificada. Um novo cabeçalho ignorado não é uma verificação bem-sucedida do novo protocolo. Os planos de transição futuros devem preservar um caminho de autenticação aprovado enquanto testam explicitamente o downgrade e o comportamento de suporte misto, em vez de assumir que a publicação dupla é automaticamente segura.
Mantenha o comissionamento e a aprovação de alterações abertas
O catálogo exige: “Compare a orientação atual do algoritmo, o status do rascunho e o suporte demonstrado do verificador”. Este artigo compara os dois primeiros a partir de fontes documentais retidas. O suporte demonstrado do verificador permanece ausente, portanto o requisito completo de comissionamento permanece em aberto. Uma lista de verificação de revisão não é uma implementação funcional e um rascunho de exemplo não é evidência de que EmailAuth ou outro produto implemente a proposta. Nenhuma chave secreta, mensagem de usuário, domínio de cliente ou credencial foi usada.
Designe um responsável pelas alterações nos padrões e outro pelas evidências de produtos e laboratórios. Verifique novamente a revisão preliminar, o estado da publicação, as relações de registro e a documentação relevante do fornecedor antes de recomendar ações. Registre qualquer correção de origem ou revisão incompatível como motivo para revisar as suposições. Alterações DNS de produção, operações de credenciais, testes de mensagens e divulgação externa exigem sua própria autorização explícita. Até que essa evidência exista, o resultado defensável é uma lista de observação datada com incertezas nomeadas, e não uma data de atualização prometida.