RSA-SHA256 e Ed25519-SHA256 são distintos Assinatura DKIM algoritmos. Escolha entre, ou implante ambos, usando os recursos suportados do seu signatário e as evidências dos verificadores relevantes. Comparar os comprimentos brutos das chaves não responde à questão da interoperabilidade.
Suporte de especificação separado do suporte implantado
Seções 3–5 RFC 8463 adiciona Ed25519-SHA256 a DKIM e requer verificadores que implementem essa atualização para apoiá-la. Ele recomenda a implementação do signatário. Esses requisitos descrevem o padrão; eles não estabelecem que cada dispositivo de e-mail instalado, biblioteca antiga ou interface hospedada implemente a atualização hoje.
O Ed25519 usos de registro de chave k=ed25519, e sua chave pública é codificada em p=. O algoritmo de assinatura é identificado como a=ed25519-sha256. Para RSA, o algoritmo correspondente é rsa-sha256; RFC 8301 seção 3 fornece os requisitos atualizados de tamanho RSA e proíbe o rsa-sha1. Não altere apenas o rótulo do algoritmo enquanto mantém material de chave incompatível.
Decida quais evidências a migração precisa
Faça um inventário do software de assinatura, versão, algoritmos suportados e controles do provedor. Identifique os sistemas receptores cujo comportamento é importante para o negócio. Registre se o resultado do teste reflete sua própria biblioteca de verificação, o resultado da autenticação confiável do destinatário final ou uma ferramenta de análise de terceiros. Estas são observações diferentes.
Pergunte se a plataforma pode emitir ambos os algoritmos e gerenciar dois seletores com segurança. Um provedor que não oferece controle Ed25519 ainda pode ter uma configuração RSA documentada e adequada para a tarefa. Não invente um procedimento não suportado apenas porque a RFC subjacente permite uma configuração.
Use seletores distintos para assinaturas paralelas
RFC 8463 seção 6 descreve múltiplas assinaturas como um mecanismo de transição. As chaves RSA e Ed25519 precisam de seletores distintos. Não coloque duas chaves de algoritmo em uma seletor e confie no destinatário para escolher o seu preferido.
Em um design ilustrativo, rsa2026._domainkey.example.com contém os dados de verificação RSA e ed2026._domainkey.example.com contém os dados Ed25519. Ambas as assinaturas usam d=example.com, mas seus s= e a= os valores diferem. Estes são nomes de exemplo, não registros de chave implementáveis. Gere e publique material chave real por meio do sistema de assinatura compatível.
Um teste útil registra cada assinatura de forma independente. O receptor A pode verificar ambos; o receptor B pode verificar apenas RSA. Não relate “trabalhos de assinatura dupla” sem preservar qual algoritmo produziu cada resultado. Sob Seção 4.4.1 RFC 9989, uma assinatura RSA alinhada com sucesso pode fornecer um DMARC caminho de autenticação mesmo quando a outra assinatura não é verificada, desde que as condições de avaliação DMARC aplicáveis sejam atendidas.
Torne a transição reversível
Antes de alterar a produção, estabeleça um método compatível para restaurar a configuração de assinatura anterior. Teste mensagens normais e recursos de roteamento reais, como gateways ou listas de discussão. O suporte ao algoritmo não protege uma assinatura contra alterações arbitrárias de conteúdo após a assinatura.
Durante o período de observação, mantenha o inventário do seletor e as evidências do receptor vinculadas aos carimbos de data e hora. Uma pesquisa DNS bem-sucedida do registro Ed25519 prova a publicação, e não que o remetente emitiu uma assinatura ou que um destinatário a utilizou. Decida se deseja manter ambos os algoritmos ou alterar a configuração com base na compatibilidade medida e nos requisitos organizacionais, e não na afirmação de que todos os receptores foram atualizados.
Fechar a decisão de segurança e operações em conjunto
Registre o design selecionado, resultados específicos do algoritmo, limitações de destinatário não resolvidas e critérios para retirar um caminho de compatibilidade. Continue a proteger ambas as chaves privadas enquanto ambos os assinantes permanecem ativos. A assinatura dupla adiciona outra dependência de gerenciamento de chaves; não elimina a necessidade de custódia, rotação ou resposta a incidentes.
Leia um resultado sintético de assinatura dupla
Suponha que uma mensagem tenha o domínio do autor example.com e duas assinaturas com d=example.com. O receptor confiável relata rsa-sha256, s=rsa2026, pass para uma assinatura e ed25519-sha256, s=ed2026, fail para a outra. A assinatura RSA é uma passagem exatamente alinhada, portanto pode satisfazer o caminho DKIM do DMARC . A assinatura Ed25519 com falha não a cancela. Este é um exemplo construído, não uma evidência de que um receptor não tem suporte para Ed25519: a falha pode estar relacionada à sua chave, sintaxe ou conteúdo assinado. Preserve o motivo por assinatura antes de diagnosticar a compatibilidade.
Mantenha um registro de investigação compacto
Use esta planilha sugerida para a rota em análise. É uma ajuda de planejamento, não uma evidência de um teste executado.
- Signatário: software ou serviço, versão e controles de algoritmo suportados.
- Por assinatura: a, d, s, resultado e receptor que produziu o resultado.
- DMARC : Domínio do Autor, alinhamento modo e a assinatura alinhada de passagem, se houver.
- Decisão: manter ambos os algoritmos ou retirar um, com etapas de reversão e limitações de destinatário não resolvidas.
Leitura relacionada
Comprimento da chave DKIM e algoritmos: verifique o suporte atual do receptor · Múltiplas assinaturas DKIM : encontre a assinatura de passagem alinhada.