RSA-SHA256 i Ed25519-SHA256 są różne Podpis DKIM algorytmy. Wybieraj pomiędzy lub wdrażaj oba, korzystając z obsługiwanych możliwości osoby podpisującej i dowodów uzyskanych od odpowiednich weryfikatorów. Porównanie ich surowych długości kluczy nie odpowiada na pytanie dotyczące interoperacyjności.
Oddziel wsparcie specyfikacji od wsparcia wdrożonego
RFC 8463 sekcje 3–5 dodaje Ed25519-SHA256 do DKIM i wymaga, aby weryfikatorzy wdrażający tę aktualizację wspierali ją. Zaleca wdrożenie podpisu. Wymagania te opisują standard; nie ustalają, czy każde zainstalowane urządzenie pocztowe, stara biblioteka lub hostowany interfejs wdraża obecnie aktualizację.
The Ed25519 kluczowe zastosowania rekordów k=ed25519, a jego klucz publiczny jest zakodowany w p=. Algorytm podpisu jest identyfikowany jako a=ed25519-sha256. W przypadku RSA odpowiedni algorytm to rsa-sha256; RFC 8301 sekcja 3 dostarcza zaktualizowane wymagania dotyczące rozmiaru RSA i zabrania rsa-sha1. Nie zmieniaj samej etykiety algorytmu, zachowując niezgodny materiał klucza.
Zdecyduj, jakich dowodów potrzebuje migracja
Inwentaryzacja oprogramowania do podpisywania, wersji, obsługiwanych algorytmów i kontroli dostawcy. Zidentyfikuj systemy odbiorcze, których zachowanie ma znaczenie dla firmy. Zapisz, czy wynik testu odzwierciedla Twoją własną bibliotekę weryfikatorów, wynik zaufanego uwierzytelnienia odbiorcy końcowego lub narzędzie analityczne strony trzeciej. To są różne obserwacje.
Zapytaj, czy platforma może emitować oba algorytmy i bezpiecznie zarządzać dwoma selektorami. Dostawca, który nie oferuje kontroli Ed25519, może nadal mieć udokumentowaną konfigurację RSA odpowiednią do tego zadania. Nie twórz nieobsługiwanej procedury tylko dlatego, że podstawowy dokument RFC pozwala na konfigurację.
Użyj odrębnych selektorów dla podpisów równoległych
RFC 8463 sekcja 6 opisuje wiele podpisów jako mechanizm przejściowy. Klucze RSA i Ed25519 wymagają odrębnych selektorów. Nie umieszczaj dwóch kluczy algorytmu w jednym selektor i polegaj na tym, że odbiorca wybierze preferowanego.
W ilustracyjnym projekcie, rsa2026._domainkey.example.com przechowuje dane weryfikacyjne RSA i ed2026._domainkey.example.com przechowuje dane Ed25519. Oba podpisy używają d=example.com, ale ich s= I a= wartości różnią się. Są to przykładowe nazwy, a nie możliwe do wdrożenia rekordy kluczy. Generuj i publikuj aktualne kluczowe materiały za pośrednictwem obsługiwanego systemu podpisywania.
Przydatny test rejestruje każdy podpis niezależnie. Odbiorca A może zweryfikować oba; odbiorca B może zweryfikować tylko RSA. Nie zgłaszaj „podwójnego podpisywania działa” bez zachowania algorytmu, który wygenerował każdy wynik. Pod RFC 9989 sekcja 4.4.1, pomyślnie dopasowany podpis RSA może zapewnić DMARC ścieżkę uwierzytelniania, nawet jeśli drugi podpis nie weryfikuje, pod warunkiem spełnienia odpowiednich warunków oceny DMARC .
Spraw, aby przecięcie było odwracalne
Przed zmianą produkcji ustal obsługiwaną metodę przywracania poprzedniej konfiguracji podpisywania. Przetestuj zwykłe wiadomości i rzeczywiste funkcje routingu, takie jak bramy lub listy mailingowe. Obsługa algorytmów nie chroni podpisu przed samowolnymi zmianami treści po podpisaniu.
W okresie obserwacji przechowuj inwentarz selektora i dowody odbiorcy powiązane ze znacznikami czasu. Pomyślne wyszukiwanie DNS rekordu Ed25519 dowodzi publikacji, a nie tego, że nadawca wyemitował podpis lub że odbiorca go użył. Zdecyduj, czy zachować oba algorytmy, czy zmienić konfigurację w oparciu o zmierzoną kompatybilność i wymagania organizacyjne, a nie twierdzenie, że wszystkie odbiorniki zostały zaktualizowane.
Zamknij razem decyzję dotyczącą bezpieczeństwa i operacji
Zapisz wybrany projekt, wyniki specyficzne dla algorytmu, nierozwiązane ograniczenia odbiorców i kryteria wycofywania ścieżki zgodności. Kontynuuj ochronę obu kluczy prywatnych, dopóki obaj sygnatariusze pozostaną aktywni. Podpisywanie podwójne dodaje kolejną zależność w zarządzaniu kluczami; nie eliminuje to potrzeby opieki, rotacji ani reagowania na incydenty.
Odczytaj syntetyczny wynik podwójnego podpisu
Załóżmy, że wiadomość ma domenę autora example.com i dwa podpisy z d=example.com. Zaufany odbiorca zgłasza rsa-sha256, s=rsa2026, pass dla jednego podpisu i ed25519-sha256, s=ed2026, niepowodzenie dla drugiego. Podpis RSA jest dokładnie dopasowanym przebiegiem, więc może spełniać ścieżkę DKIM DMARC . Nieudany podpis Ed25519 nie anuluje go. To jest skonstruowany przykład, a nie dowód na to, że odbiornikowi brakuje obsługi Ed25519: awaria może zamiast tego dotyczyć jego klucza, składni lub podpisanej treści. Przed zdiagnozowaniem zgodności zachowaj przyczynę związaną z podpisem.
Prowadź zwarty zapis dochodzenia
Skorzystaj z sugerowanego arkusza ćwiczeń dla sprawdzanej trasy. Jest to pomoc w planowaniu, a nie dowód przeprowadzonego testu.
- Osoba podpisująca: oprogramowanie lub usługa, wersja i obsługiwane algorytmy kontroli.
- Na podpis: a, d, s, wynik i odbiorca, który wygenerował wynik.
- DMARC : domena autora, wyrównanie tryb i przechodzący wyrównany podpis, jeśli istnieje.
- Decyzja: zachować oba algorytmy lub wycofać jeden, z etapami wycofywania i nierozwiązanymi ograniczeniami odbiorców.
Powiązane lektury
Długość klucza DKIM i algorytmy: sprawdź aktualną obsługę odbiornika · Wiele podpisów DKIM : znajdź wyrównany podpis przechodzący.