退職する DKIMセレクター 送信者は新しいメッセージに秘密キーの使用を停止でき、もう 1 つはDNS公開検証キーを利用できるようにすることを停止できます。これらのアクションは同時に発生する必要はありません。通常の計画ローテーション中に、これらを分離すると、署名済みでまだ転送中のメールの検証を保持できます。
例外はセキュリティインシデントです。古い秘密キーが侵害される可能性がある場合、その公開キーを利用可能な状態にしておくことで、対応する検証パスも使用可能な状態に保ちます。ルーチンのローテーションの重複を自動的に適用するのではなく、封じ込めと遅延メールの互換性の間のバランスを明示的に決定します。
古いセレクターがまだサポートしているものを記録します
署名ドメイン、セレクター、キー管理者、送信システム、および最後に知られている用途をインベントリします。キューに入れられたアプリケーション メール、バッチ ジョブ、プロバイダーのフォールバック ルートが含まれます。新しい署名者からの 1 つの成功メッセージは、すべての古い署名者が停止したことを証明するものではありません。
公開キーが直接公開されているか、プロバイダーが管理するキーを介して到達されているかを判断します。 CNAME。アカウントの閉鎖時にターゲットが削除された場合、顧客のDNSにエイリアスを残すだけでは検証を維持するのに十分ではありません。アカウントの閉鎖をコミットする前に、実際の保持動作を尋ね、関連する依存関係を確認してください。
別の名前でカットオーバーを計画する
RFC 6376 §3.1 セレクターの設計により、1 つの署名ドメインで複数の公開キーを同時に実行できます。サポートされているローテーションでは、新しいセレクターを公開し、そのキーが取得可能であることを確認し、新しい署名を切り替えて、承認されたオーバーラップの古い検証マテリアルを保持できます。同じルックアップ名の下にある古いキーマテリアルを置き換えず、以前に署名されたメールが新しいキーに従うと想定してください。
新しいキーには現在のアルゴリズムとキーサイズのガイダンスを使用します。 RFC 8301 §3.1 rsa-sha1 の署名と検証を禁止します。 RFC 8301 §3.2 署名者は少なくとも 1024 ビットの RSA キーを使用する必要があり、少なくとも 2048 ビットが推奨されます。プロバイダーのサポートと現在のセキュリティ要件はまだ検討する必要があります。セレクターのラベルを変更するだけではキーは強化されません。
メッセージ遅延のケースに対処する
シーケンス例: メッセージ A はカットオーバー前に old1 で署名され、キューで待機します。メッセージ B はカットオーバー後に new2 で署名され、すぐに到着します。対象となるコンテンツとその他すべての該当する検証チェックに合格すると仮定すると、両方とも、対応する公開キーが利用可能な状態のまま検証できます。 A の評価時に使用可能な old1 キーを取得できない場合、A はキーがない状態で失敗する可能性があります。 RFC 6376 §6.1.2 Bが合格しても。
既知のキューの動作、署名の有効期限（存在する場合）、ビジネス要件およびリスクを使用して重複を選択します。アーカイブされたメールの将来の再チェックの検証を保証する単一の保存期間はありません。履歴証拠が重要な場合は、元の信頼できる認証結果を保存します。このシナリオは、観察されたサービス キューではなく、予想されるプロトコルの動作について説明します。
退職準備の確認
各アクティブなルートが意図した新しいセレクターで署名し、受信メッセージが必要な形式で渡されることを確認します。 アライメント。短い観察期間だけに依存するのではなく、頻度の低いジョブを確認します。実行できないルートを記録し、その所有者の構成証拠または特定のフォローアップ計画を取得します。
DNSキャッシュの前提条件を確認してください。下 RFC 1034 §3.6、以前にキャッシュされた回答は、以前の TTL の間保持されます。リタイア時に TTL を下げても、それらのキャッシュは消去されません。 RFC 8767 §4 また、権限のあるリフレッシュが失敗した場合に古いレコードの使用が許可されるため、TTL 有効期限は保証されたグローバル失効期限ではありません。権限のあるNXDOMAINを含む権限のあるリフレッシュの成功は、リフレッシュの失敗とは異なります。逆に、公開キーを保持しても、署名の有効期限が延長されたり、受信者ポリシーが無効になったりすることはありません。退職計画ではこれらのメカニズムを区別してください。
意図的に権限を削除する
承認された互換性期間が経過したら、サポートされている設計に従ってパブリック レコードまたは委任を廃止します。空の p 値は、以下の条件で取り消しを意味します。 RFC 6376 §3.6.1;キーを削除すると、関連するキャッシュされた回答からキーが提供されなくなると、そのキーを取得できなくなります。選択した方法とその理由を記録します。秘密キーの安全な廃棄とプロバイダー アクセスの削除は別のタスクです。
侵害されたキーについては、即時の取り消しまたはより短い重複が必要な理由と、どの正規のメッセージが影響を受ける可能性があるかを文書化します。ダッシュボードのスコアを改善するためだけに、侵害された検証資料を復元しないでください。完了した変更には、古い鍵による署名がいつ停止されたか、古い鍵検証サポートがいつ終了したか、および両方の決定を正当化する証拠が示されるはずです。
次の決定を記録する
仮説的なリタイアメント記録は、最後の古い鍵の署名、新しいルートの検証、未処理のキューまたは低頻度ジョブの証拠、プロバイダーのターゲット保持、キャッシュの仮定、および承認されたリタイアメントの決定を分離する必要があります。スケジュールされた請求ジョブがチェックされていない場合は、最近の従業員のメールから退職の準備を推測するのではなく、その依存関係を未解決としてマークします。侵害の疑いがある場合は、日常的な重複チェックリストではなく、インシデントの決定を使用してください。ローテーションやDNS削除は実行されませんでした。