移行の約束ではなく監視リストを作成する
ポスト量子 DKIM 議論では、個別に回答する必要があるいくつかの質問が組み合わされます。暗号プリミティブは標準化されていますか?特定のメールプロトコルでの使用は承認された文書で指定されていますか?デプロイされた検証ツールはその形式を理解しますか?関連するルートはテストされていますか?最初の質問に対する肯定的な答えは、残りの 3 つの質問を解決するものではありません。有用な標準ウォッチリストはそれぞれを個別に記録し、サポートされていない回答は明示的に不明のままにします。
このガイドでは、2026 年 11 月 8 日に公開された一次情報源をレビューしました。 DKIM2仕様記録 は、アクティブなワーキンググループのインターネットドラフトとして、11 月 1 日に更新されたリビジョン 09 を示しました。の DKIMレコードのポスト量子暗号 は、アクティブな個別のインターネット ドラフトとして、11 月 2 日に更新されたリビジョン 00 を示しました。後者の記録は、個人の提出とIETF承認を明確に区別します。どちらの記録も、承認された運用移行を確立するものではありません。
確立されたDKIMガイダンスを提案されたフォーマットから分離する
RFC 8301 rsa-sha1 の署名と検証を禁止します。 RSA ガイダンスでは、少なくとも 1024 ビットの署名キーが必要であり、少なくとも 2048 ビットが推奨されています。 1024 ビットより短い RSA 署名は有効であるとみなされません。 RFC 8463 Ed25519-SHA256 を追加し、検証者のサポートを指定します。これらの公開された要件は、インストールされている特定の製品が実際に要件に準拠しているかどうかを確認するものとは異なります。
PQ-DKIM1 ドラフトでは、既存のDKIMバージョンの耐量子署名オプションについて説明しています。 DKIM2は、独自に提案された署名付きマテリアルと構文を備えた別個のプロトコル開発作業です。リビジョン 09 では、その暗号化セクションに ML-DSA-44 が含まれており、その用途に純粋な ML-DSA が指定されています。 DKIM1提案のアルゴリズム ラベルや例をDKIM2ドラフトと単に同じような数学的族について議論しているという理由だけで交換しないでください。提案されたキーをDNSにコピーしても、これらの違いは解決されません。
メール展開を要求せずにプリミティブをチェックする
NIST FIPS 204 2024 年 8 月 13 日に公開され、ML-DSA が指定されています。出版物のページには、2026 年 7 月 31 日の更新の可能性に関する通知も掲載されています。これにより、暗号化標準とメンテナンスに関する考慮事項が確立されます。特定のDKIMバインディング、実装、またはホストされた電子メール サービスが承認またはテストされたことを証明するものではありません。このガイドでは、実装の正確性や正誤表スプレッドシートの内容についてはレビューしません。
脅威に関する議論は署名偽造に関するものであり、 DKIMを暗号化するものではありません。 DKIMの公開モデル 署名ドメインを、選択されたメッセージ素材の署名に関連付けます。新しい署名アルゴリズム自体は、メッセージを隠蔽したり、ビジネス要求を承認したり、人間の特派員の身元を確立したりするものではありません。機密保持、認証、 ドメインの調整 将来のアルゴリズムが重要になる可能性がある理由を説明する場合、コンテンツの安全性とコンテンツの安全性は分けて説明します。
サイズと輸送に関する質問を測定可能にする
キーが大きくなると、操作上の複数の疑問が生じます。公開キーのバイト、エンコードされたTXTコンテンツ、完全なDNS応答、署名バイト、および結果として生じるメッセージ ヘッダーのサイズを区別します。 TXT文字列の制限は、レコード全体またはDNSメッセージの最大サイズではありません。逆に、複数の文字列のサポートは、すべてのDNSパス、プロビジョニング インターフェイス、またはメール パーサーが意図した応答を処理できることを証明するものではありません。 DNSのレコード形式 それはその調査の一部にすぎません。
ベンチマークの結論を組織の環境に持ち込むのではなく、測定値を提案します。リゾルバーと権限のあるソフトウェア、トランスポート動作、メッセージ サイズの制約、署名ワークロード、検証ワークロードを記録します。便利な有効な例だけでなく、不正な入力やサポートされていない入力も含めます。スループットやレイテンシーに関するステートメントには、再現可能なテスト設定と実際の結果が必要です。ここでは、数値的なパフォーマンス結果、キーの発行、メッセージの生成、またはベリファイアの実行については主張しません。
実証されたサポートが何を意味するかを定義する
架空のラボマトリックスの場合、各署名者/検証者のバージョンのペアと各中間変換に行を割り当てます。この行には、正確な草案リビジョン、アルゴリズムの表現、予想される動作、およびまだ必要な証拠を指定する必要があります。計画されているケースには、無傷の署名、変更された署名コンテンツ、不明なアルゴリズム、および使用できないキーが含まれる可能性があります。認可されたテストによって検査可能な記録が生成されるまで、実行されなかったすべての結果にラベルを付けます。量子後の対応に関するベンダーの一般的な声明の未知のセルに入力しないでください。
互換性にもポリシーに関する質問が必要です。複数の署名が存在する場合、提案されたプロトコルにはどのような組み合わせが必要ですか?また、古い受信機は実際に何を評価するのでしょうか?有効な従来の署名は、PQ 署名がチェックされたことを証明しません。新しいヘッダーが無視された場合、新しいプロトコルの検証は成功しません。将来の移行計画では、二重公開が自動的に安全であると仮定するのではなく、ダウングレードと混合サポートの動作を明示的にテストしながら、承認された認証パスを維持する必要があります。
コミッショニングと変更の承認をオープンにしておく
カタログでは、「現在のアルゴリズム ガイダンス、ドラフト ステータス、実証済みの検証者サポートを比較する」ことが求められています。この記事では、保存されている文書ソースから最初の 2 つを比較します。実証済みの検証者のサポートは依然として存在しないため、完全な試運転要件は未解決のままです。レビュー チェックリストは実用的な実装ではなく、ドラフトの例はEmailAuthまたは別の製品が提案を実装していることを示す証拠ではありません。秘密キー、ユーザー メッセージ、顧客ドメイン、資格情報は使用されませんでした。
1 人の所有者を規格の変更に割り当て、もう 1 人を製品および実験室の証拠に割り当てます。アクションを推奨する前に、ドラフト リビジョン、公開状態、レジストリ関係、および関連するプロバイダーのドキュメントを再確認してください。ソースの修正や互換性のないリビジョンを、仮定を再検討する理由として記録します。実稼働DNS変更、資格情報の操作、メッセージ テスト、および外部開示には、独自の明示的な承認が必要です。その証拠が存在するまで、防御可能な出力は、約束されたアップグレード日ではなく、名前付きの不確実性を含む日付付きのウォッチリストです。