RSA-SHA256 og Ed25519-SHA256 er forskellige DKIM signatur algoritmer. Vælg mellem eller implementer begge dele ved at bruge de understøttede funktioner fra din underskriver og beviserne fra relevante verifikatorer. Sammenligning af deres rå nøglelængder besvarer ikke interoperabilitetsspørgsmålet.
Adskil specifikationssupport fra implementeret support
RFC 8463 afsnit 3-5 tilføjer Ed25519-SHA256 til DKIM og kræver, at verifikatorer implementerer denne opdatering for at understøtte den. Det anbefaler underskriverimplementering. Disse krav beskriver standarden; de fastslår ikke, at alle installerede mailapparater, gamle biblioteker eller hostede grænseflader implementerer opdateringen i dag.
De Ed25519 nøglepostanvendelser k=ed25519, og dens offentlige nøgle er kodet ind p=. Signaturalgoritmen er identificeret som a=ed25519-sha256. For RSA er den tilsvarende algoritme rsa-sha256; RFC 8301 afsnit 3 leverer de opdaterede RSA-størrelseskrav og forbyder rsa-sha1. Ændr ikke kun algoritmeetiketten, mens inkompatibelt nøglemateriale bevares.
Beslut hvilke beviser migrationen har brug for
Inventar signeringssoftware, version, understøttede algoritmer og udbyderkontroller. Identificer de modtagende systemer, hvis adfærd har betydning for virksomheden. Registrer, om testresultatet afspejler dit eget verifikatorbibliotek, den endelige modtagers betroede godkendelsesresultat eller et tredjepartsanalyseværktøj. Det er forskellige observationer.
Spørg, om platformen kan udsende begge algoritmer og administrere to vælgere sikkert. En udbyder, der ikke tilbyder nogen Ed25519-kontrol, har muligvis stadig en dokumenteret RSA-konfiguration, der passer til opgaven. Opfind ikke en ikke-understøttet procedure, blot fordi den underliggende RFC tillader en konfiguration.
Brug forskellige vælgere til parallelle signaturer
RFC 8463 afsnit 6 beskriver flere signaturer som en overgangsmekanisme. RSA- og Ed25519-nøgler har brug for forskellige vælgere. Placer ikke to algoritmetøgler på én vælger og stol på, at modtageren vælger din foretrukne.
I et illustrativt design, rsa2026._domainkey.example.com indeholder RSA-verifikationsdata og ed2026._domainkey.example.com indeholder Ed25519 data. Begge signaturer bruger d=example.com, men deres s= og a= værdier er forskellige. Disse er eksempelnavne, ikke deployerbare nøgleposter. Generer og udgiv egentligt nøglemateriale gennem det understøttede signeringssystem.
En nyttig test registrerer hver signatur uafhængigt. Modtager A kan verificere begge dele; modtager B bekræfter muligvis kun RSA. Rapporter ikke "dual signing works" uden at bevare, hvilken algoritme der producerede hvert resultat. Under RFC 9989 afsnit 4.4.1, kan en vellykket justeret RSA-signatur give en DMARC godkendelsessti, selv når den anden signatur ikke bekræfter, forudsat at de gældende DMARC evalueringsbetingelser er opfyldt.
Gør skæringen vendbar
Før du ændrer produktion, skal du etablere en understøttet metode til at gendanne den tidligere signeringskonfiguration. Test normale beskeder og de rigtige routingfunktioner, såsom gateways eller postlister. Algoritmeunderstøttelse beskytter ikke en signatur mod vilkårlige indholdsændringer efter signering.
I løbet af observationsperioden skal du holde vælgeropgørelse og modtagerbevis knyttet til tidsstempler. Et vellykket DNS opslag af Ed25519-posten beviser offentliggørelse, ikke at afsenderen udsendte en signatur, eller at en modtager brugte den. Beslut om du vil beholde begge algoritmer eller ændre konfigurationen baseret på målt kompatibilitet og organisatoriske krav, ikke en påstand, som alle modtagere har opgraderet.
Luk sikkerheds- og driftsbeslutningen sammen
Registrer det valgte design, algoritmespecifikke resultater, uløste modtagerbegrænsninger og kriterier for at trække en kompatibilitetssti tilbage. Fortsæt med at beskytte begge private nøgler, mens begge underskrivere forbliver aktive. Dobbelt signering tilføjer endnu en nøglestyringsafhængighed; det fjerner ikke behovet for varetægtsfængsling, rotation eller hændelsesreaktion.
Læs et syntetisk dobbeltsignaturresultat
Antag, at en meddelelse har Author Domain example.com og to signaturer med d=example.com. Den betroede modtager rapporterer rsa-sha256, s=rsa2026, pass for én signatur og ed25519-sha256, s=ed2026, mislykkedes for den anden. RSA-signaturen er et nøjagtigt tilpasset pass, så det kan opfylde DMARC 's DKIM sti. Den mislykkede Ed25519-signatur annullerer den ikke. Dette er et konstrueret eksempel, ikke et bevis på, at en modtager mangler Ed25519-understøttelse: fejl kan i stedet vedrøre dens nøgle, syntaks eller signeret indhold. Bevar per-signatur-årsagen, før du diagnosticerer kompatibilitet.
Før en kompakt undersøgelsesjournal
Brug dette foreslåede arbejdsark til ruten under gennemgang. Det er en planlægningshjælp, ikke bevis på en udført test.
- Underskriver: software eller service, version og understøttede algoritmekontroller.
- Per signatur: a, d, s, resultat og modtager, der har produceret resultatet.
- DMARC : Forfatterdomæne, justering tilstand og den passerende justerede signatur, hvis nogen.
- Beslutning: Behold begge algoritmer, eller træk den ene tilbage, med tilbagerulningstrin og uafklarede modtagerbegrænsninger.
Relateret læsning
DKIM nøglelængde og algoritmer: Tjek den aktuelle modtagerunderstøttelse · Flere DKIM -signaturer: Find den tilpassede passerende signatur.