[ DKIM ]

RSA ve Ed25519 DKIM imzaları: dağıtım soruları ve birlikte çalışabilirlik

Farklı seçiciler, imza başına gözlemler ve test edilmiş uyumluluk geri dönüşüyle ​​bir algoritma geçişi planlayın.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • RSA ve Ed25519 genel anahtarları için farklı seçiciler kullanın.
  • Her imza için ayrı bir güvenilir alıcı sonucu tutun.
  • Uyumluluk imzalamayı yalnızca ilgili alıcı yolları kontrol edildikten sonra kullanımdan kaldırın.
Bu sayfada

RSA-SHA256 ve Ed25519-SHA256 farklıdır DKIM imzası algoritmalar. İmzalayanınızın desteklenen yeteneklerini ve ilgili doğrulayıcılardan elde edilen kanıtları kullanarak aralarında seçim yapın veya her ikisini de dağıtın. Ham anahtar uzunluklarını karşılaştırmak, birlikte çalışabilirlik sorusunu yanıtlamaz.

Belirtim desteğini konuşlandırılan destekten ayırın

RFC 8463 bölümleri 3–5 Ed25519-SHA256'yı ekler DKIM ve bunu desteklemek için bu güncellemeyi uygulayan doğrulayıcılara ihtiyaç duyar. İmzalayanın uygulanmasını önerir. Bu gereksinimler standardı açıklamaktadır; yüklü her posta cihazının, eski kitaplığın veya barındırılan arayüzün güncellemeyi bugün uyguladığını tespit etmezler.

The Ed25519 anahtar kayıt kullanımları k=ed25519ve genel anahtarı şu şekilde kodlanmıştır: p=. İmza algoritması şu şekilde tanımlanır: a=ed25519-sha256. RSA için karşılık gelen algoritma şöyledir: RSA-sha256; RFC 8301 bölüm 3 güncellenmiş RSA boyutu gereksinimlerini sağlar ve rsa-sha1'i yasaklar. Uyumsuz anahtar materyali korurken yalnızca algoritma etiketini değiştirmeyin.

Geçişin hangi kanıtlara ihtiyacı olduğuna karar verin

İmzalama yazılımının, sürümünün, desteklenen algoritmaların ve sağlayıcı kontrollerinin envanterini çıkarın. Davranışı işletme için önemli olan alıcı sistemleri belirleyin. Test sonucunun kendi doğrulama kitaplığınızı, son alıcının güvenilir kimlik doğrulama sonucunu veya bir üçüncü taraf analiz aracını yansıtıp yansıtmadığını kaydedin. Bunlar farklı gözlemler.

Platformun her iki algoritmayı da yayınlayıp, iki seçiciyi güvenli bir şekilde yönetip yönetemeyeceğini sorun. Ed25519 kontrolü sunmayan bir sağlayıcı, yine de göreve uygun, belgelenmiş bir RSA yapılandırmasına sahip olabilir. Yalnızca temeldeki RFC bir yapılandırmaya izin veriyor diye desteklenmeyen bir yordam icat etmeyin.

Paralel imzalar için farklı seçiciler kullanın

RFC 8463 bölüm 6 Çoklu imzayı bir geçiş mekanizması olarak tanımlar. RSA ve Ed25519 anahtarlarının farklı seçicilere ihtiyacı vardır. İki algoritma anahtarını bir arada bulundurmayın seçici ve alıcının tercih ettiğinizi seçmesine güvenin.

Açıklayıcı bir tasarımda, rsa2026._domainkey.example.com RSA doğrulama verilerini tutar ve ed2026._domainkey.example.com Ed25519 verilerini tutar. Her iki imza da kullanılır d=example.com, ama onların s= Ve a= değerler farklılık göstermektedir. Bunlar örnek adlardır, konuşlandırılabilir anahtar kayıtları değildir. Desteklenen imzalama sistemi aracılığıyla gerçek anahtar materyali oluşturun ve yayınlayın.

Yararlı bir test, her imzayı bağımsız olarak kaydeder. Alıcı A her ikisini de doğrulayabilir; alıcı B yalnızca RSA'yı doğrulayabilir. Her bir sonucu hangi algoritmanın ürettiğini korumadan “çift imzalama çalışmalarını” raporlamayın. Altında RFC 9989 bölüm 4.4.1başarılı bir şekilde hizalanmış bir RSA imzası şunları sağlayabilir: DMARC Geçerli DMARC değerlendirme koşullarının karşılanması koşuluyla, diğer imza doğrulamasa bile kimlik doğrulama yolunu kullanın.

Kesimi tersine çevrilebilir hale getirin

Üretimi değiştirmeden önce önceki imzalama yapılandırmasını geri yüklemek için desteklenen bir yöntem oluşturun. Normal mesajları ve ağ geçitleri veya posta listeleri gibi gerçek yönlendirme özelliklerini test edin. Algoritma desteği, imzayı, imzalandıktan sonra keyfi içerik değişikliklerinden korumaz.

Gözlem süresi boyunca seçici envanterini ve alıcı kanıtlarını zaman damgalarına bağlı tutun. Ed25519 kaydının başarılı bir DNS araması, gönderenin imza attığını veya alıcının bunu kullandığını değil, yayınlandığını kanıtlar. Tüm alıcıların yükselttiği iddiasına değil, ölçülen uyumluluk ve organizasyonel gereksinimlere dayalı olarak her iki algoritmayı mı koruyacağınıza veya yapılandırmayı mı değiştireceğinize karar verin.

Güvenlik ve operasyon kararını birlikte kapatın

Seçilen tasarımı, algoritmaya özgü sonuçları, çözülmemiş alıcı sınırlamalarını ve uyumluluk yolunun kullanımdan kaldırılmasına ilişkin kriterleri kaydedin. Her iki imzalayan da etkin durumdayken, her iki özel anahtarı da korumaya devam edin. Çift imzalama, başka bir anahtar yönetimi bağımlılığı ekler; velayet, rotasyon veya olaylara müdahale ihtiyacını ortadan kaldırmaz.

Sentetik çift imza sonucunu okuyun

Bir iletinin Yazar Etki Alanı example.com ve d=example.com. Güvenilir alıcı, bir imza için rsa-sha256, s=rsa2026, geçtiğini ve diğer imza için ed25519-sha256, s=ed2026, başarısız olduğunu bildirir. RSA imzası tam olarak hizalanmış bir geçiş olduğundan DMARC DKIM yolunu karşılayabilir. Başarısız olan Ed25519 imzası onu iptal etmez. Bu, bir alıcının Ed25519 desteğinden yoksun olduğunun kanıtı değil, oluşturulmuş bir örnektir: başarısızlık bunun yerine alıcının anahtarı, sözdizimi veya imzalı içeriğiyle ilgili olabilir. Uyumluluğu teşhis etmeden önce imza başına nedeni koruyun.

Kompakt bir araştırma kaydı tutun

İncelenmekte olan rota için önerilen bu çalışma sayfasını kullanın. Bu bir planlama yardımcısıdır, yürütülen bir testin kanıtı değildir.

  • İmzalayan: yazılım veya hizmet, sürüm ve desteklenen algoritma kontrolleri.
  • İmza başına: a, d, s, sonuç ve sonucu üreten alıcı.
  • DMARC : Yazar Etki Alanı, hizalama modu ve varsa geçen hizalanmış imza.
  • Karar: Her iki algoritmayı da koruyun veya geri alma adımlarıyla ve çözülmemiş alıcı sınırlamalarıyla birini kullanımdan kaldırın.

DKIM anahtar uzunluğu ve algoritmalar: mevcut alıcı desteğini kontrol edin · Çoklu DKIM imzaları: hizalanmış geçiş imzasını bulun.

[ Götürmek ]

RSA ve Ed25519 genel anahtarları için farklı seçiciler kullanın. Her imza için ayrı bir güvenilir alıcı sonucu tutun. Uyumluluk imzalamayı yalnızca ilgili alıcı yolları kontrol edildikten sonra kullanımdan kaldırın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

İmzaları ayrı ayrı gözlemleyin.

Tek bir genel durum, hangi algoritmanın çalıştığını gizler.

Sonraki adımlar

  1. Her imza için d, s, a ve sonucu kaydedin.
  2. Geri alma prosedürünü test edin.
  3. Algoritmaya özgü alıcı kanıtlarını saklayın.

CISO / SecOps

Her iki temel yaşam döngüsünü de yönetin.

Paralel imzalama, sahiplik gerektiren gizli dizilerin ve seçicilerin sayısını artırır.

Sonraki adımlar

  1. Algoritma politikasını onaylayın.
  2. Her iki emeklilik yolunu da takip edin.
  3. Her iki anahtar için imzalama hizmeti erişimini inceleyin.

Kurucu / Teknik Olmayan

Test edilmiş bir geçiş seçin.

Uyumluluk çalışması, kriptografik tasarım değişirken iş postalarını korumalıdır.

Sonraki adımlar

  1. Kritik alıcı sistemlerini tanımlayın.
  2. Açık bir emeklilik kararı gerektirir.
  3. Paralel imzalamayı sonlandırmak için kriterleri kaydedin.

[ SSS ]

Sık sorulan sorular

Etiketi düzenleyerek rsa-sha256'yı ed25519-sha256 ile değiştirebilir miyim?

Hayır. Algoritma ve anahtar materyali eşleşmeli ve imzalayan kişi algoritmayı uygulamalıdır.

RFC 8463 §4

RFC desteği her alıcının Ed25519'u desteklediğini kanıtlar mı?

Hayır. Postanızla ilgili sistemler için dağıtım davranışını onaylayın.

RFC 8463 §5

RSA ve Ed25519 aynı seçiciyi kullanabilir mi?

RFC 8463 geçiş için açıkladığı gibi, ayrı ortak anahtar kayıtları için farklı seçiciler kullanın.

RFC 8463 §6

Her iki imza da aynı d alanını kullanabilir mi?

Evet. Geçiş tasarımı, seçicileri ve algoritmaları değiştirirken aynı imzalama alanını koruyabilir.

RFC 8463 §6

Başarısız bir imza, DMARC için geçen başka bir imzayı iptal eder mi?

Tek başına değil. Geçerli politika kapsamında geçen herhangi bir DKIM tanımlayıcısının Yazar Etki Alanı ile uyumlu olup olmadığını değerlendirin.

RFC 9989 §4.4.1

Çift imzalama, altbilgi değişikliğine çare midir?

Hayır. İmzalı içeriği değiştirmek her iki imzayı da bozabilir. İşleme sırasını ayrı ayrı inceleyin.

RFC 6376 §3.7

Barındırılan sağlayıcım yalnızca RSA'yı açığa çıkarırsa ne olur?

Alternatif bir algoritma planlamadan önce desteklenen yapılandırmasını kullanın ve belgelenmiş destek arayın.

Uyumluluk imzasını ne zaman kaldırabilirim?

İlgili alıcı kanıtlarına, hizmet desteğine ve emekliliğin operasyonel etkisine dayanan yetkili bir kararın ardından.

[ Kaynaklar ]

Kaynaklar

  1. RFC 8463

    Bölümler §3 · §4 · §5 · §6

  2. RFC 8301

    Bölümler §3

  3. RFC 9989

    Bölümler §4.4.1

  4. RFC 6376 : Etki Alanı Anahtarlarıyla Tanımlanan Posta İmzaları

    Bölümler §1 · §3.5 · §3.7

[ Sözlük ]

Sözlük

DKIM
Alıcının genel anahtar verileriyle doğruladığı, seçilen mesaj başlıkları ve gövde içeriği üzerinde alanla ilişkili bir imza.

RFC 6376 §1

RSA
Rsa-sha256 DKIM imza yöntemi tarafından kullanılan genel anahtar algoritması.

RFC 8301 §3.1

Ed25519
RFC 8463 tarafından DKIM eklenen ortak anahtar imza algoritması.

RFC 8463 §3

seçici
DKIM doğrulama verilerini bulmak için imzalama alanıyla birlikte kullanılan s değeri.

RFC 6376 §3.5

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası