メインコンテンツまでスキップ

5. Signer Actions (署名者のアクション)

5. Signer Actions (署名者のアクション)​

Signerは以下の手順を順番に実行します。

5.1. Determine Whether the Email Should Be Signed and by Whom (メールが署名されるべきか、誰によって署名されるべきかを決定する)​

Signerは明らかに、秘密鍵と対応する公開鍵およびセレクタ情報の必要な知識を持っているドメインのメールのみに署名できます。ただし、秘密鍵の欠如以外にも、Signerがメールに署名しないことを選択する理由は数多くあります。

情報提供のメモ: Signerは、MUA、SUBMISSIONサーバー、またはMTAを含む、適切と見なされるメールシステムの任意の部分の一部として実装できます。どこに実装されても、Signerは問題がある可能性のあるメッセージに署名する（それによって責任を主張する）ことに注意する必要があります。特に、信頼されたエンクレーブ内では、署名ドメインはローカルポリシーに従ってヘッダーから派生する可能性があります。SUBMISSIONサーバーは、適切に認証および承認されたユーザーからのメッセージのみに署名する可能性があります。

情報提供の実装者アドバイス: 発信ゲートウェイMTAがReceivedヘッダーフィールドを難読化する場合（たとえば、内部トポロジの詳細を隠すため）、SUBMISSIONサーバーはReceivedヘッダーフィールドに署名すべきではありません。

何らかの理由でメールに署名できない場合、そのメールをどうするかはローカルポリシーの決定です。

5.2. Select a Private Key and Corresponding Selector Information (秘密鍵と対応するセレクタ情報を選択する)​

この仕様は、Signerが使用する秘密鍵とセレクタ情報を選択する際の基準を定義していません。現在、この仕様に関する限り、すべてのセレクタは等しいため、決定は主に管理上の便宜の問題であるべきです。秘密鍵の配布と管理もこのドキュメントの範囲外です。

情報提供の運用アドバイス: 対応する公開鍵を含むセレクタがVerifierが署名を検証する機会を得る前に取り消されたり削除されたりすることが予想される場合、Signerは秘密鍵で署名すべきではありません。Signerは、Verifierが検証を延期することを選択できることを予測する必要があります。おそらくメッセージが最終受信者によって実際に読まれるまで。特に、新しいキーペアにローテーションする場合、新しい秘密鍵で即座に署名を開始し、古い公開鍵はキーサーバーから削除される前に妥当な検証間隔の間保持する必要があります。

5.3. Normalize the Message to Prevent Transport Conversions (転送変換を防ぐためにメッセージを正規化する)​

一部のメッセージ、特に8ビット文字を使用するメッセージは、転送中に変更される可能性があり、特に7ビット形式への変換が行われます。このような変換はDKIM署名を壊します。このような破損の可能性を最小限に抑えるために、Signerは署名する前に、[RFC2045]で説明されているquoted-printableまたはbase64などの適切なMIMEコンテンツ転送エンコーディングにメッセージを変換する必要があります。このような変換はDKIMの範囲外です。実際のメッセージは、DKIMアルゴリズムに提示される前に、MUAまたはMSAによって7ビットMIMEに変換される必要があります。

転送前に変更されるローカルエンコーディングでメッセージがSignerに送信される場合、正規[RFC5322]形式への変更は署名前に行わなければなりません。特に、裸のCRまたはLF文字（一部のシステムでローカル行区切り規則として使用される）は、メッセージが署名される前にSMTP標準のCRLFシーケンスに変換する必要があります。この種の変換は、署名アルゴリズムに提示されるバージョンだけでなく、受信者に実際に送信されるメッセージに適用する必要があります。

より一般的には、Signerは、ローカルまたは内部形式ではなく、Verifierによって受信されることが予想される形式でメッセージに署名する必要があります。

5.3.1. Body Length Limits (本文長の制限)​

本文長カウントを指定して、署名計算を本文テキストの最初のプレフィックスに制限できます（オクテット単位で測定）。本文長カウントが指定されていない場合、メッセージ本文全体が署名されます。

情報提供の根拠: この機能が提供されるのは、メーリングリストがメッセージにトレーラーを追加すること（たとえば、リストから抜ける方法の指示）が非常に一般的だからです。これらのメッセージも署名されるまで、本文長カウントはVerifierにとって有用なツールです。なぜなら、ポリシーの問題として、有効な署名と無関係なデータを持つメッセージを受け入れることができるからです。

実際にハッシュされた長さは、DKIM-Signatureヘッダーフィールドの"l="タグに挿入する必要があります。（Section 3.5を参照。）

本文長カウントにより、メッセージのSignerは署名されたメッセージの本文の末尾にデータを追加することを許可できます。本文長カウントは正規化アルゴリズムに従って計算する必要があります。たとえば、正規化アルゴリズムによって無視される空白は本文長カウントの一部として含まれません。

本文長カウントがゼロの場合、本文が完全に署名されていないことを意味します。

いかなる種類の変更も発生しないようにしたいSignerは、ヘッダーと本文の両方に"simple"正規化アルゴリズムを指定し、本文長カウントを省略する必要があります。

詳細については、Section 8.2を参照してください。

5.4. Determine the Header Fields to Sign (署名するヘッダーフィールドを決定する)​

Fromヘッダーフィールドは署名する必要があります（つまり、結果のDKIM-Signatureヘッダーフィールドの"h="タグに含める必要があります）。Signerは、転送中に正当に変更または削除される可能性のある既存のヘッダーフィールドに署名すべきではありません。特に、[RFC5321]は転送中にReturn-Pathヘッダーフィールドの変更または削除を明示的に許可しています。Signerは、Signerの裁量により、署名時に存在する他のヘッダーフィールドを含めることができます。

情報提供の運用メモ: 署名するヘッダーフィールドの選択は明白ではありません。1つの戦略は、既存のすべての反復不可能なヘッダーフィールドに署名することです。別の戦略は、受信者に表示される可能性が高い、または受信者でのメッセージの処理に影響を与える可能性が高いヘッダーフィールドのみに署名することです。第3の戦略は、"よく知られた"ヘッダーのみに署名することです。Verifierは署名されていないヘッダーフィールドを非常に懐疑的に扱う可能性があることに注意してください。これには、エンドユーザーへの表示を拒否したり、特定のヘッダーフィールドをカバーしていない場合は署名を無視したりすることが含まれます。このため、Date、Subject、Reply-To、Sender、およびすべてのMIMEヘッダーフィールドなど、メッセージに存在するフィールドに署名することを強くお勧めします。

DKIM-Signatureヘッダーフィールドは常に暗黙的に署名されており、他の既存の署名も署名されていることを示す場合を除き、"h="タグに含めてはなりません。

Signerは存在しないヘッダーフィールドに署名したと主張できます（つまり、そのヘッダーフィールドがメッセージに存在しない場合でも、Signerは"h="タグにヘッダーフィールド名を含めることができます）。署名を計算する際、存在しないヘッダーフィールドはnull文字列として扱う必要があります（ヘッダーフィールド名、ヘッダーフィールド値、すべての句読点、および末尾のCRLFを含む）。

情報提供の根拠: これにより、Signerはヘッダーフィールドの不在を明示的に主張できます。そのヘッダーフィールドが後で追加された場合、署名は失敗します。

情報提供のメモ: ヘッダーフィールド名は、署名時にメッセージ内のそのヘッダーフィールドの実際の数よりも1回多くリストするだけで、それ以上の追加を防ぐことができます。たとえば、署名時にCommentsヘッダーフィールドが1つある場合、"h="タグにCommentsを2回リストすれば、任意の数のCommentsヘッダーフィールドが追加されるのを防ぐのに十分です。"h="タグにCommentsを3回以上リストする必要はありません（ただし合法です）。

特定のヘッダーフィールド名の複数のインスタンスを持つヘッダーを正規化する際に従うべき手順については、Section 5.4.2を参照してください。

Signerは、配信プロセスで後に追加のインスタンスが追加される可能性のあるヘッダーフィールドに署名する際には注意が必要です。このようなヘッダーフィールドは、署名されたインスタンスの後に挿入されたり、他の方法で並べ替えられたりする可能性があるためです。トレースヘッダーフィールド（Receivedなど）とResent-*ブロックは、[RFC5322]によって並べ替えが禁止されている唯一のフィールドです。特に、DKIM-Signatureヘッダーフィールドは一部の中間MTAによって並べ替えられる可能性があるため、既存のDKIM-Signatureヘッダーフィールドへの署名はエラーが発生しやすくなります。

情報提供の警告: [RFC5322]はヘッダーフィールドの並べ替えを禁止していませんが、中間MTAによる複数のインスタンスを持つ署名されたヘッダーフィールドの並べ替えはDKIM署名を壊します。このような反社会的行動は避けるべきです。

情報提供の実装者のメモ: この仕様では必須ではありませんが、可能な"間接スパム"を避けるために、すべてのエンドユーザーに表示されるヘッダーフィールドに署名する必要があります。たとえば、Subjectヘッダーフィールドが署名されていない場合、スパマーは以前に署名されたメールを再送信し、正当な件名を1行のスパムに置き換えることができます。

5.4.1. Recommended Signature Content (推奨される署名コンテンツ)​

DKIM暗号化アルゴリズムの目的は、通常の転送関連の変更に対して堅牢であり、さまざまな種類のリプレイ攻撃に耐性がある方法で、メッセージに識別子を付加することです。これらの要件を満たすための重要な側面は、ハッシュに含めるヘッダーフィールドと除外するフィールドを選択することです。

含めるフィールドを選択する基本的なルールは、メッセージコンテンツの"コア"を構成するフィールドを選択することです。したがって、リプレイ攻撃は署名を成功させるためにこれらを含める必要があります。ただし、これらが含まれている場合、メッセージのコアは新しい受信者に送信された場合でも有効です。

アドレスを含むフィールドと本文に関連するテキストコンテンツを含むフィールドの一般的な例は次のとおりです。

  • From（必須。Section 5.4を参照）
  • Reply-To
  • Subject
  • Date
  • To、Cc
  • Resent-Date、Resent-From、Resent-To、Resent-Cc
  • In-Reply-To、References
  • List-Id、List-Help、List-Unsubscribe、List-Subscribe、List-Post、List-Owner、List-Archive

"l="署名タグが使用されている場合（Section 3.5を参照）、Content-Typeフィールドも含めることの候補です。これは、受信ユーザーに完全に異なるコンテンツがレンダリングされる方法で置き換えられる可能性があるためです。

メッセージの"コア"を構成するものの決定には トレードオフがあります。一部のフィールドにとっては主観的な概念です。たとえば、"Message-ID"などのフィールドを含めることは、同じメッセージの個別のインスタンスを区別できるメカニズムがコアコンテンツであると考える場合に有用です。同様に、"In-Reply-To"と"References"は、メッセージスレッドがメッセージのコア部分であると考える場合に含めることが望ましい場合があります。

関心のある別のクラスのフィールドは、Authentication-Results [RFC5451]など、メッセージに関するセキュリティ関連情報を伝えるフィールドです。

除外するフィールドを選択する基本的なルールは、同じ名前の複数のフィールドがあるフィールドと転送中に変更されるフィールドを選択することです。これらの例は次のとおりです。

  • Return-Path
  • Received
  • Comments、Keywords

DKIM-Signatureフィールドは、その処理が個別に指定されているため、ヘッダーハッシュからも除外されることに注意してください。

通常、検証前に同じ名前の追加フィールドが正当に追加または並べ替えられる可能性があるため、他のオプションフィールドを除外する方が良いです。メッセージに適用される可能性のあるアプリケーション固有のヘッダーフィールドの多様性があるため、このルールの正当な例外がある可能性があります。その一部は複製、変更、または並べ替えが行われる可能性が低いです。

Signerは、処理するメッセージのタイプとリスクへの嫌悪に基づいて正規化アルゴリズムを選択する必要があります。たとえば、主に購入レシートを送信する電子商取引サイトは、メーリングリストやメッセージを変更する可能性のある他のソフトウェアによって処理されることが予想されないため、一般的に"simple"正規化を好みます。

主に個人間の電子メールを送信するサイトは、"relaxed"正規化を使用することで、転送中の変更に対してより回復力を持つことを好む可能性があります。

メールがメッセージ本文の下部に"購読解除"指示を追加する可能性のあるメーリングリストなどの仲介を通じて処理されない限り、"l="タグは、メッセージへの不正なテキストの追加の道を提供しながら、追加の利益を伝える可能性は低いです。"l=0"の使用はこれを極端にし、署名を無効にすることなくメッセージのテキストを完全に変更できます。さらに、Verifierは部分的に署名されたメッセージ本文を受け入れられないと見なす権利があります。慎重な使用をお勧めします。

5.4.2. Signatures Involving Multiple Instances of a Field (フィールドの複数のインスタンスを含む署名)​

メッセージ内に複数回出現する既存のヘッダーフィールド（Receivedなど）に署名することを選択したSignerは、ヘッダーブロック内のそのヘッダーフィールドの物理的に最後のインスタンスに署名する必要があります。そのようなヘッダーフィールドの複数のインスタンスに署名したいSignerは、DKIM-Signatureヘッダーフィールドの"h="タグにヘッダーフィールド名を複数回含め、ヘッダーフィールドブロックの下から上の順序でそのようなヘッダーフィールドに署名する必要があります。Signerは、その名前の追加のヘッダーフィールドが追加された場合に署名が検証されないように、実際の対応するヘッダーフィールドよりも多くのヘッダーフィールド名のインスタンスを"h="に含めることができます。

情報提供の例:

Signerが2つの既存のReceivedヘッダーフィールドに署名したい場合、既存のヘッダーに次が含まれているとします。

Received: <A>
Received: <B>
Received: <C>

結果のDKIM-Signatureヘッダーフィールドは次のようになります。

DKIM-Signature: ... h=Received : Received :...

そして、Receivedヘッダーフィールド<C>と<B>がその順序で署名されます。

5.5. Compute the Message Hash and Signature (メッセージハッシュと署名を計算する)​

SignerはSection 3.7で説明されているようにメッセージハッシュを計算し、選択された公開鍵アルゴリズムを使用して署名する必要があります。これにより、本文ハッシュとヘッダーハッシュの署名を含むDKIM-Signatureヘッダーフィールドが生成されます。そのヘッダーにはDKIM-Signatureヘッダーフィールド自体が含まれます。

DKIMを実装し、メッセージを再送信する前にメッセージまたはヘッダーフィールド（たとえば、購読解除情報の挿入）を変更するメーリングリストマネージャーなどのエンティティは、入力の既存の署名をチェックする必要があり、メッセージに再署名する前にそのような変更を行う必要があります。

5.6. Insert the DKIM-Signature Header Field (DKIM-Signatureヘッダーフィールドを挿入する)​

最後に、Signerは電子メールを送信する前に、前のステップで作成したDKIM-Signatureヘッダーフィールドを挿入する必要があります。DKIM-Signatureヘッダーフィールドは、上記でハッシュを計算するために使用したものと同じである必要がありますが、"b="タグの値は、前のステップで計算された適切に署名されたハッシュである必要があります。これは、DKIM-Signatureヘッダーフィールドの"a="タグで指定されたアルゴリズムを使用して署名され、Section 5.2で上記で選択されたように、DKIM-Signatureヘッダーフィールドの"s="タグで指定されたセレクタに対応する秘密鍵を使用します。

DKIM-Signatureヘッダーフィールドは、ヘッダーブロック内の他のDKIM-Signatureフィールドの前に挿入する必要があります。

情報提供の実装メモ: これを達成する最も簡単な方法は、ヘッダーブロックの先頭にDKIM-Signatureヘッダーフィールドを挿入することです。特に、既存のReceivedヘッダーフィールドの前に配置できます。これは、DKIM-Signatureをトレースヘッダーフィールドとして扱うことと一致しています。

に最終更新