RSA-SHA256 och Ed25519-SHA256 är distinkta DKIM signatur algoritmer. Välj mellan, eller implementera båda, med hjälp av de funktioner som stöds av din undertecknare och bevis från relevanta verifierare. Att jämföra deras råa nyckellängder svarar inte på interoperabilitetsfrågan.
Separat specifikationsstöd från utplacerat stöd
RFC 8463 avsnitt 3–5 lägger till Ed25519-SHA256 till DKIM och kräver att verifierare implementerar den uppdateringen för att stödja den. Den rekommenderar signerareimplementering. Dessa krav beskriver standarden; de fastställer inte att alla installerade e-postverktyg, gamla bibliotek eller värdgränssnitt implementerar uppdateringen idag.
De Ed25519 nyckelpostanvändningar k=ed25519, och dess publika nyckel är kodad i p=. Signaturalgoritmen identifieras som a=ed25519-sha256. För RSA är motsvarande algoritm rsa-sha256; RFC 8301 avsnitt 3 tillhandahåller de uppdaterade RSA-storlekskraven och förbjuder rsa-sha1. Ändra inte bara algoritmetiketten samtidigt som du behåller inkompatibelt nyckelmaterial.
Bestäm vilka bevis migrationen behöver
Inventera signeringsmjukvaran, versionen, algoritmer som stöds och leverantörskontroller. Identifiera de mottagande systemen vars beteende är viktigt för verksamheten. Registrera om testresultatet återspeglar ditt eget verifieringsbibliotek, den slutliga mottagarens betrodda autentiseringsresultat eller ett analysverktyg från tredje part. Det är olika observationer.
Fråga om plattformen kan avge båda algoritmerna och hantera två väljare säkert. En leverantör som inte erbjuder någon Ed25519-kontroll kan fortfarande ha en dokumenterad RSA-konfiguration som är lämplig för uppgiften. Uppfinn inte en procedur som inte stöds bara för att den underliggande RFC tillåter en konfiguration.
Använd distinkta väljare för parallella signaturer
RFC 8463 avsnitt 6 beskriver flera signaturer som en övergångsmekanism. RSA- och Ed25519-nycklar behöver distinkta väljare. Placera inte två algoritmnycklar samtidigt väljare och lita på att mottagaren väljer din favorit.
I en illustrativ design, rsa2026._domainkey.example.com innehar RSA-verifieringsdata och ed2026._domainkey.example.com innehåller Ed25519-data. Båda signaturerna används d=example.com, men deras s= och a= värden skiljer sig åt. Dessa är exempelnamn, inte distribuerbara nyckelposter. Generera och publicera faktiskt nyckelmaterial genom det signeringssystemet som stöds.
Ett användbart test registrerar varje signatur oberoende. Mottagare A kan verifiera båda; mottagare B kanske endast verifierar RSA. Rapportera inte "dubbel signering fungerar" utan att bevara vilken algoritm som producerade varje resultat. Under RFC 9989 avsnitt 4.4.1, en framgångsrik anpassad RSA-signatur kan ge en DMARC autentiseringssökväg även när den andra signaturen inte verifieras, förutsatt att tillämpliga DMARC utvärderingsvillkor är uppfyllda.
Gör kapningen vändbar
Innan du ändrar produktion, etablera en metod som stöds för att återställa den tidigare signeringskonfigurationen. Testa vanliga meddelanden och de verkliga routingfunktionerna, såsom gateways eller e-postlistor. Algoritmstöd skyddar inte en signatur från godtyckliga innehållsändringar efter signering.
Under observationsperioden, håll väljarinventering och mottagarbevis kopplade till tidsstämplar. En framgångsrik DNS sökning av Ed25519-posten bevisar publicering, inte att avsändaren sänt ut en signatur eller att en mottagare använde den. Bestäm om du vill behålla båda algoritmerna eller ändra konfigurationen baserat på uppmätt kompatibilitet och organisatoriska krav, inte ett påstående som alla mottagare har uppgraderat.
Stäng säkerhets- och verksamhetsbeslutet tillsammans
Registrera den valda designen, algoritmspecifika resultat, olösta mottagarbegränsningar och kriterier för att ta bort en kompatibilitetsväg. Fortsätt att skydda båda privata nycklarna medan båda undertecknarna förblir aktiva. Dubbel signering lägger till ytterligare ett beroende av nyckelhantering; det tar inte bort behovet av vårdnad, rotation eller incidentrespons.
Läs ett syntetiskt resultat med dubbla signaturer
Anta att ett meddelande har Author Domain example.com och två signaturer med d=example.com. Den betrodda mottagaren rapporterar rsa-sha256, s=rsa2026, godkänd för en signatur och ed25519-sha256, s=ed2026, misslyckad för den andra. RSA-signaturen är ett exakt anpassat pass, så den kan uppfylla DMARC :s DKIM sökväg. Den misslyckade Ed25519-signaturen avbryter den inte. Detta är ett konstruerat exempel, inte bevis på att en mottagare saknar Ed25519-stöd: fel kan istället handla om dess nyckel, syntax eller signerade innehåll. Bevara orsaken per signatur innan du diagnostiserar kompatibilitet.
Håll en kompakt utredningsjournal
Använd detta föreslagna arbetsblad för rutten som granskas. Det är ett planeringshjälp, inte bevis på ett utfört test.
- Signerare: programvara eller tjänst, version och algoritmkontroller som stöds.
- Per signatur: a, d, s, resultat och mottagare som producerade resultatet.
- DMARC : Author Domain, inriktning läge och den passande justerade signaturen, om någon.
- Beslut: behåll båda algoritmerna eller ta bort en, med återställningssteg och olösta mottagarbegränsningar.
Relaterad läsning
DKIM nyckellängd och algoritmer: kontrollera det aktuella mottagarstödet · Flera DKIM signaturer: hitta den justerade passerande signaturen.