4. Semantics of Multiple Signatures (複数署名のセマンティクス)

4.1. Example Scenarios (シナリオ例)

メッセージが複数の署名を持つ理由は多数あります。たとえば, SHA-256が将来十分に強力でないことが判明し, DKIMの使用がSHA-1024に移行するとします。Signerは新しいアルゴリズムを使用してすぐに署名することができますが, まだアップグレードしていないVerifierとの相互運用性のために古いアルゴリズムを使用して署名を続けることもできます。Signerは各アルゴリズムを使用して2つのDKIM-Signatureヘッダーフィールドを追加することでこれを行います。SHA-1024を許容可能なアルゴリズムとして認識しない古いVerifierはその署名をスキップして古いアルゴリズムを使用します; 新しいVerifierはオプションでいずれかの署名を使用でき, 他のすべてが等しい場合, 他の署名を検証しようとさえしない可能性があります。

同様に, Signerはすべてのヘッダーフィールドを含み"l="タグのないメッセージに署名し(厳格なVerifierを満たすため), 限定されたヘッダーフィールドのセットと"l="タグで2回目に署名することができます(他のVerifierへの途中で可能なメッセージ変更を予測して)。その後, Verifierは好みの署名を選択できます。

もちろん, メッセージは複数のSignerを通過したために複数の署名を持つ可能性もあります。一般的なケースは, すべてのメッセージに署名するメーリングリストを通過する署名済みメッセージです。これらの署名の両方が検証されると仮定すると, 受信者はこれらの署名のいずれかが信頼できるソースから来ることがわかっている場合, メッセージを受け入れることを選択できます。

特に, 受信者は購読した許容可能な不正使用防止ポリシーを持つメーリングリストをホワイトリストに登録し, 未知の著者からであってもそのリストに送信されたメッセージを受け入れることを選択できます。また, 信頼性の低いメーリングリスト(例えば, 不正使用防止保護のないもの)を購読し, 特定の著者からのすべてのメッセージを受け入れることを望む一方で, 他のメッセージに対しては追加の不正使用スキャンを実行することを主張することもできます。

複数のSignerの別の関連例は, 学術同窓会サイトに一般的に関連する転送サービスなどです。たとえば, 受信者はmembers.example.orgにアドレスを持っている可能性があり, このサイトには受信者が希望するよりもやや効果の低い不正使用防止保護があります。このような受信者は, メッセージが絶対的に信頼される特定の著者を持っている可能性がありますが, 転送者の精査を通過した未知の著者からのメッセージは中程度の信頼しか持たない可能性があります。

4.2. Interpretation (解釈)

メッセージに署名を追加するSignerは, "h="オプションの通常のセマンティクスを使用して新しいDKIM-Signatureヘッダーを作成するだけです。Signerは, Section 5.4で説明されているメソッドを使用して, 以前に存在するDKIM-Signatureヘッダーフィールドに署名することができます。

Signerは, DKIM-Signatureヘッダーフィールドに署名すると, DKIM-Signatureヘッダーフィールドがトレースヘッダーフィールドであることを認識せず, 無意識にそれらを並べ替える仲介者との署名の失敗を引き起こす可能性があることを認識する必要があります。このため, 既存のDKIM-Signatureヘッダーフィールドへの署名は合法ではありますが, 推奨されません。

情報提供のメモ: 複数のインスタンスを持つヘッダーフィールドが署名される場合, それらのヘッダーフィールドは常に下から上に署名されます。したがって, 特定のDKIM-Signatureヘッダーフィールドのみに署名することは不可能です。たとえば, 署名されるメッセージにすでに3つのDKIM-SignatureヘッダーフィールドA, B, Cが含まれている場合, それらすべて, BとCのみ, またはCのみに署名することは可能ですが, Aのみ, Bのみ, AとBのみ, またはAとCのみに署名することはできません。

Signerは異なるパラメータを使用して複数のDKIM-Signatureヘッダーフィールドを追加できます。たとえば, 移行期間中, Signerは2つの異なるハッシュアルゴリズムを使用して署名を生成したい場合があります。

Signerは署名しているメッセージからDKIM-Signatureヘッダーフィールドを削除すべきではありません, たとえ署名が検証できないことを知っていても。

複数の署名を持つメッセージを評価する場合, Verifierは署名を独立して評価し, それ自体のメリットに基づいて評価すべきです。たとえば, ポリシーにより非推奨の暗号化アルゴリズムを使用した署名を受け入れないことを選択したVerifierは, そのような署名を無効と見なします。Verifierは選択した任意の順序で署名を処理できます; たとえば, 一部のVerifierは他の署名の前にメッセージヘッダーのFromフィールドに対応する署名を処理することを選択する場合があります。署名の選択に関する詳細情報については, Section 6.1を参照してください。

情報提供の実装メモ: 署名が失敗した理由を推測しようとして有効な署名と無効な署名を関連付けるVerifierの試みは推奨されません。特に, Verifierが無効な署名がかつて有効であったことを判断する一般的な方法はありません。

VerifierはVerifierの満足のいくように署名が正常に検証されるまで署名のチェックを続けるべきです。潜在的なサービス拒否攻撃を制限するために, Verifierは検証を試みる署名の総数を制限できます。

Verifierモジュールが評価がPERMFAIL結果を生成した署名を報告する場合, Identity Assessorはこれらの署名を無視すべきです(Section 6.1を参照), メッセージに存在しないかのように動作します。