本文書は Japan DKIM Working Group (dkim.jp) の作業チームにより翻訳されました。詳細はこちら
DKIMD. Crocker, 編者
Internet-DraftBrandenburg InternetWorking
Obsoletes: 4871 (未承認)T. Hansen, 編者
Intended status: Standards TrackAT&T Laboratories
Expires: April 13, 2011M. Kucherawy, 編者
Cloudmark
October 10, 2010

DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-02

要約

DKIM (DomainKeys Identified Mail) は署名元のドメインの所有者である個人、役職、組織などが、電子メールメッセージにそのドメイン情報を加えることにより、その電子メールメッセージに一定の責任を宣言することを可能にする。これは(その電子メールの)作成者組織の場合もあれば、動作上の中継者、またはそれらの代理でも構わない。DKIMではメッセージの署名者が誰かということと、メッセージの見かけ上の作成者とは分けて扱われる。責任の宣言は暗号化された署名と、それを解除する公開鍵を署名元のドメインへ直接問い合わせ、それを取りに行くことで確認される。電子メールメッセージの作成者から受信者への送信の特徴として、実質的にメッセージ本文への変更は加えられないため、DKIM署名は保たれる。

本文書の位置づけ

このインターネットドラフトは、BCP 78とBCP 79の条項に完全に適合した形で提案されている。

インターネットドラフトはIETF (Internet Engineering Task Force)の作成中の文書である。他のグループもまた、別の文書をインターネットドラフトとして配布する可能性があることに留意すること。最新のインターネットドラフトのリストは http://datatracker.ietf.org/drafts/current/ を参照のこと。

インターネットドラフトは最大6ヶ月有効の草案文書であり、その間いつでも更新または上書き、あるいは他の新しい文書の作成によって廃止になる可能性がある。したがって、インターネットドラフトを参照文書として使ったり、「現在作成中」のもの以外として引用するのは適切ではない。

このインターネットドラフトは、2011年4月13日で期限が切れ、無効化する。

著作権表記

本文書の著作権は、IETF委員会と文書作成者として明記された個人に属する。全ての著作権は保護の対象とする。

本文書は、その公開日をもって、BCP 78とIETF委員会のIETF文書に関する規則条項 (http://trustee.ietf.org/license-info) の対象とする。本文書に関する権利と制限を規定してあるので、これらの条項を注意深く確認するように。本文書から抜き出したいかなるプログラムコード部品は委員会規則条項 4.e にある通り、簡易 BSD ライセンスに関する表示を入れなければならず、簡易 BSD ライセンス表示にある通り、無保証で配布されるものとする。


目次

1. はじめに

DKIM (DomainKeys Identified Mail) は署名元のドメインの所有者である個人、役職、組織などが、電子メールメッセージにそのドメイン情報を加えることにより、その電子メールメッセージに一定の責任を宣言することを可能にする。これは(その電子メールの)作成者組織の場合もあれば、動作上の中継者、またはそれらの代理でも構わない。責任の宣言は暗号化された署名と、それを解除する公開鍵を署名元のドメインへ直接問い合わせ、それを取りに行くことで確認される。電子メールメッセージの作成者から受信者への送信の特徴として、実質的にメッセージ本文への変更は加えられないため、DKIM署名は保たれる。メッセージには、同じ組織またはそのメッセージに関与した別の組織による複数署名を含むことができる。

DKIMで取られているアプローチは、以前からある電子メール署名技術(例えばS/MIME(RFC1847)やOpenPGP (RFC2440)とは以下の点で異なる。

DKIMは:

1.1 署名の身元

DKIMではメッセージの署名者が誰かということと、メッセージの見かけ上の作成者とは分けて扱われる。特に署名に含まれるのは、署名者が誰かという情報である。検証者は、署名から得られる情報を元にメッセージをどう処理するかを決めることができる。署名者の身元情報は、署名のヘッダーフィールドの一部に含まれる。

1.2 スケーラビリティ

DKIMは、電子メールのなりすまし問題を難しくする、大規模なスケーラビリティの要求にも対応できるように設計されている。現在、7000万以上のドメインとそれを遥かに越える数のメールアドレスが存在する。DKIMは、例えば誰とでも紹介なしにすぐに通信できるという、現状の電子メールインフラの良い側面をそのまま残すことを目的とする。

1.3 簡単な鍵管理

DKIMは権威ある認証局を必要とするような従来の階層的な公開鍵システムとは違い、検証者は公開鍵を第三者からではなく、その署名元と宣言されたドメインのデータソースに直接要求する。

当初はDNSが公開鍵システムとして提唱されている。従って現状では、DKIMはDNS管理システムとその安全性に依存している。DKIMは他の公開鍵取得サービスが普及すれば、そちらも拡張的に利用できるよう設計されている。

2. 用語と定義

このセクションでは、ドキュメントの残りの部分で使用される用語を定義する。

DKIM は、[RFC5598] で定義されているように、インターネットメールで動作するよう設計されている。 基本的な電子メールの用語はこれに倣うものとする。

構文の記述には、拡張バッカス・ナウア記法 (ABNF) [RFC4234] を使用する。

このドキュメントにおけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"は、[RFC2119] で記載されている通り解釈する。

2.1 署名者(Signer)

メールシステムにおいて、あるドメインを代表してメッセージに署名する要素を、署名者(signer)と呼ぶ。署名者になることができるのは、MUA(メールユーザーエージェント)、MSA(メール投稿エージェント)、MTA(メール転送エージェント)、あるいはメーリングリストエクスプローダーのようなその他のエージェントである。一般的には、いずれの署名者も何らかの方法でメッセージシステムへメッセージを送り込むことに関与することになる。重要な点は、メッセージは、署名者が管理するドメインから離れる前に署名されなければならないということである。

2.2 検証者(Verifier)

メールシステムにおいて、署名を検証する要素を検証者(verifier)と呼ぶ。検証者は、MTA、MDA(メール配送エージェント)、あるいはMUAなどの場合がある。いずれの場合も、検証者はメッセージのエンドユーザー(読者)かメーリングリスト配送者などのエンドユーザーよりのエージェントに近いことが望ましい。

2.3 アイデンティティ(身元主体)

個人、役割、または組織。DKIMにおいては、作成者、作成者の組織、経路処理上のISP、独立した信用評価サービス、メーリングリストの管理者が例に含まれる。

2.4 識別子

アイデンティティを示すラベル。

2.5 署名ドメイン識別子 (Signing Domain Identifier: SDID)

DKIMの必須のペイロード出力であり、メール経路へのメッセージの発送について責任があることを宣言するアイデンティティ(身元主体)を示す、単一のドメイン名。DKIMの処理上、SDID名は基本的には単なるドメイン名以外の意味を持たない。所有者に固有な意味があったとしても、それはDKIMの範囲外である。セクション3.5 で詳述する。

2.6 エージェントまたはユーザー識別子 (Agent or User Identifier: AUID)

署名ドメイン識別子(SDID)が責任を負うエージェントまたはユーザの代わりとなる、単一の識別子。AUIDはドメイン名とオプションのローカルパートから構成される。ドメイン名はSDIDで使用されたものと同じか、またはそのサブドメインである。DKIMの処理上、AUIDのドメイン名部分は基本的なドメイン名以外の意味を持たない。所有者に固有な意味があったとしても、それはDKIMの範囲外である。セクション3.5で詳述する 。

2.7 アイデンティティ(身元主体)評価モジュール

DKIMの必須ペイロード出力、つまり責任の所在を示す署名ドメイン識別子SDIDを処理するモジュール。このモジュールは送られて来た識別子で相手を評価するためのもの。他のDKIM(またはDKIM以外)の値も、他のもっと一般的なメッセージ評価フィルタリングエンジンへ渡されると同様に、このモジュールに渡すことができる。しかし、このような追加的な使用はDKIM署名の仕様の範囲外である。

2.8 ホワイトスペース

ホワイトスペースには3つの形式が存在する:

正式な ABNF では以下の通り(WSP と LWSP は参考までに):

WSP =   SP / HTAB
LWSP =  *(WSP / CRLF WSP)
FWS =   [*WSP CRLF] 1*WSP

FWS の定義は、obs-FWS を除外すること以外は [RFC5322] で定義されているものと同様である。

2.9 共通の ABNF トークン

以下のABNFトークンは、このドキュメントの他の場所で使用されている:

hyphenated-word =  ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS =     (ALPHA / DIGIT / "+" / "/")
base64string =     ALPHADIGITPS *([FWS] ALPHADIGITPS)
                   [ [FWS] "=" [ [FWS] "=" ] ] 

2.10 インポートされた ABNF のトークン

ここにある通り、以下のトークンは他のRFCを準用する。定義はそれぞれのRFCに準ずる。

以下のトークンは [RFC5321] を準用する:

以下のトークンは [RFC5322] を準用する:

以下のトークンは [RFC2045] を準用する:

他のトークンで、ここで定義していないものは、[RFC4234] を準用する。それらは SP、HTAB、WSP、ALPHA、DIGIT、CRLF などのような、直感的に理解できるものである。

2.11 DKIM-Quoted-Printable

DKIM-Quoted-Printable エンコーディングの構文は、[RFC2045]のセクション6.7で記載されている、Quoted-Printable と類似している:一つの"="に続けて、0123456789ABCDEF(小文字不可)のアルファベットを使った二桁の16進数字で、その文字の16進エンコーディングされた整数値を表す限り、どのような文字をエンコードしてもよい(MAY)。すべての制御文字(%x20より小さい値)、8ビット文字(%x7Fより大きい値)、DEL(%x7F)、スペース(%x20)それからセミコロン(;,%x3B)はエンコードしなければならない(MUST)。スペース(SPACE)、キャリッジリターン(CR)とラインフィード(LF)を含む全てのホワイトスペースはエンコードしなければならない(MUST)ことに注意。エンコード後、過度に長い行を避けるために、任意の位置に FWS を追加してもよい(MAY)。このように追加されたホワイトスペースは値の一部ではなく、デコードする前に取り除かなければならない(MUST)。

3. プロトコル構成要素

プロトコル構成要素は、署名者および検証者に共通なプロトコルを概念的に構成する要素である。署名者および検証者に特有のプロトコルの詳細については、後述の章(署名者アクション( 5節 )と検証者アクション( 6節 ))で説明する。注意:この章で説明する内容はそれらの章の文脈で読み取る必要がある。

3.1 セレクター

署名ドメイン毎に複数の公開鍵を同時にサポートするため、鍵の名前空間を "セレクター" によって分割する。例えば、セレクターとしては、オフィスの所在地("sanfrancisco"、"coolumbeach"、"reykjavik" など)や署名日("january2005"、"february2005" など)を示すものでもよいし、個々のユーザー名を示すものでもよい。

セレクターは、重要な利用事例をサポートするために必要となることがある。例えば:

セレクターにピリオド(".")を含めてもよいが、ピリオドは要素の区切り文字でもある。DNS から鍵を取得するとき、セレクター内のピリオドは DNS ラベルの境界としての役割りを担う。これは、ドメイン名におけるピリオドの伝統的な用法と同じである。セレクター要素には日付と場所を組み合わせて使用してもよい。例えば、"march2005.reykjavik" のように。DNS を構成する際、これを利用してセレクター名前空間の一部を委譲することができる。

個々のドメインの公開鍵とそれに対応するセレクターの数は、ドメインの所有者が決定する。大抵のドメインではセレクター 1つだけでも十分であるが、分散管理されている組織では、地域やメールサーバ毎に異なるセレクターと鍵ペアを管理することにしてもよい。

管理上の利便性のみならず、セレクターを利用することによって、公開鍵の定期的な交換を円滑に行なうこともできる。セレクター "january2005" に関連付けられた公開鍵を使用しているドメインが、セレクター"february2005" に関連付けられた公開鍵に変更したい場合、移行期間中に両方の公開鍵を同時に公開鍵リポジトリで公開しさえすればよい。この移行期間とは古い鍵で署名された未検証のメールが配送されている期間である。移行期間の開始時に、"february2005" の秘密鍵で署名するように送信メールサーバを設定する。移行期間の終了時に、"january2005" の公開鍵を公開鍵リポジトリから削除する。

セレクターにセットした値を周知したいドメインもあれば、外部者に何らかのデータが漏れないようなセレクター名を割り当てようと注意するドメインもあるだろう。 たとえば、ユーザー毎に鍵を発行する場合、ドメイン所有者は、セレクターをそのユーザーの名前と直接関連付けるのか、それとも、ユーザー名を連想させないランダム値(公開鍵のフィンガープリントなど)にするのかどうかを決める必要がある。

3.2 タグ=値 リスト

DKIMでは、電子メール本体とドメイン署名に関するレコードを含むいくつかの場所で、単純な "タグ=値" の構文を使用する。

値は、プレーンテキスト、"base64" でエンコードされたテキスト( [RFC2045] 6.8節で定義)、"qp-section"(同、6.7節)、または "dkim-quoted-printable"(2.6節で定義)の一連の文字列からなる。タグの名前によってそれぞれの値の符号化は決まる。符号化されていないセミコロン (";") 文字は、tag-specs の区切り子であるので、タグの値に使用してはならない (MUST NOT)。

空白文字は、タグのどの場所に置いてもよいことに注意。特に、"=" の後の空白文字と終端の ";" の前の空白文字は値の一部ではない。しかし、値の中に埋め込まれた空白文字には意味がある。

タグは、大文字と小文字を区別して解釈しなければならない (MUST)。特定のタグ記述によって意味的に大文字と小文字を区別しないことを明示しない限り、値は大文字と小文字を区別するものとして処理されなければならない (MUST)。

重複した名前を持つタグが単一の tag-list 内に存在してはならない (MUST NOT); 同じタグ名が複数回出現した場合は、tag-list 全体が無効となる。

特定のタグ記述によって明示的に除外されない限り、値の中の空白は保持されなければならない (MUST)。

読み易さのために、デフォルト値を示す タグ=値 ペア を含めてもよい (MAY)。

不明なタグは無視しなければならない (MUST)。

空の値を持つタグは省略されたタグと同じではない。省略されたタグはデフォルト値を持つものとして扱われ、空の値を持つタグは値として空の文字列を明示的に指定したことになる。例えば、デフォルトが "g=*" であったとしても、"g=" は "g=*" を意味しない。

3.3 署名と検証アルゴリズム

DKIMは、複数のデジタル署名アルゴリズムをサポートしている。現時点ではこの仕様書で 2つのアルゴリズムについて明示する。それらは rsa-sha1 と rsa-sha256 である。署名者は rsa-sha256 を必ず実装し(MUST)、署名には rsa-sha256 を用いるべきである(SHOULD)。

3.3.1 rsa-sha1 署名アルゴリズム

rsa-sha1 署名アルゴリズムは、SHA-1 [FIPS-180-2-2002] をハッシュアルゴリズムとして使用し、3.7節 で説明するようにしてメッセージのハッシュを計算する。そして、そのハッシュは、RSA アルゴリズム(PKCS#1 バージョン 1.5 [RFC3447] で定義されている)を暗号化アルゴリズムとして、署名者の秘密鍵で署名される。ハッシュは署名に先立って、切り詰めたり、ネイティブバイナリ形式以外のいかなる形式にも変換したりしてはならない (MUST NOT)。署名アルゴリズムでは公開指数として 65537 を使用すべきである (SHOULD)。

3.3.2 rsa-sha256 署名アルゴリズム

rsa-sha256 署名アルゴリズムは、SHA-256 [FIPS-180-2-2002] をハッシュアルゴリズムとして使用し、3.7節 で説明するようにしてメッセージのハッシュを計算する。そして、そのハッシュは、RSA アルゴリズム(PKCS#1 バージョン 1.5 [RFC3447])を暗号化アルゴリズムとして、署名者の秘密鍵で署名される。ハッシュは署名に先立って、切り詰めたり、ネイティブバイナリ形式以外のいかなる形式にも変換したりしてはならない (MUST NOT)。

3.3.3 鍵長

適切な鍵長は コスト・性能・リスク のバランスによって決まる。短い RSA 鍵はオフライン攻撃で破られやすいため、長期利用する場合には署名者は 少なくとも 1024 ビットの RSA 鍵を使用しなければならない (MUST)。検証者は 512ビットから 2048ビットまでの範囲の鍵による署名を検証できなければならない(MUST)。さらに、より大きな鍵による署名を検証できてもよい (MAY)。検証者側ポリシーでは、ある署名を受け入れることができるかどうか決定するための指標として署名鍵の長さを使用することができる。

鍵長の選択に影響を及ぼすであろう要因は次のとおりである:

鍵長の選択に関するこれ以上の議論については [RFC3766の] を参照のこと。

3.3.4 その他のアルゴリズム

将来的には他のアルゴリズムが定められるかもしれない (MAY)。検証者は、検証者側で未実装のアルゴリズムによるいかなる署名も無視しなければならない (MUST)。

3.4 正規化 (Canonicalization)

メールシステムによっては配送中の電子メールに変更を加え、署名を無効にする可能性がある。ほとんどの署名者にとって、電子メールの多少の変更はDKIMのドメイン名使用の正当性には関係のないことである。このような署名者には、配送中の多少の変更が影響しない正規化アルゴリズムが適している。

一方、いかなる些細な変更に対しても検証失敗の結果を求める署名者もいる。そのような署名者は配送中の変更を許容しない正規化アルゴリズムが適している。

あるいは、[RFC5322]のような電子メール標準の範囲内であればヘッダーフィールドの変更を受け入れるが、メッセージ本文のいかなる変更も受け入れない署名者もいるかもしれない。

すべての要求を満たすために、2つの正規化アルゴリズムがヘッダーと本文のそれぞれについて定義される。1つは "simple" アルゴリズムである。これはほとんどすべての変更を許さない。もう1つは "relaxed" アルゴリズムである。これは空白文字の置き換えやヘッダーフィールドの改行位置の変更などのよく行われる変更を許す。署名者は、電子メールを署名する際にヘッダーと本文それぞれにどちらかのアルゴリズムを指定することができる (MAY)。もし正規化アルゴリズムが署名者によって指定されていなければ、ヘッダーと本文のどちらに対しても "simple" アルゴリズムがデフォルトとして使用される。検証者は両方の正規化アルゴリズムを実装しなくてはならない (MUST)。ヘッダーと本文が別々の正規化アルゴリズムを使用するかもしれないことに注意すること。将来、さらに正規化アルゴリズムが定義されるかもしれない (MAY)。このため署名者は認識できない正規化アルゴリズムが使われた署名を無視しなくてはならない (MUST)。

正規化とは、署名または検証アルゴリズムに渡すために、単に電子メールデータの下準備をするものである。配送するデータはどんな形であれ変更してはならない (MUST NOT)。ヘッダーフィールドと本文の正規化の方法は後述する。

注:このセクションでは、メッセージが「ネットワーク標準」形式(テキストは ASCII エンコード済、行末文字は CRLF など)になっていることを前提としている。メッセージの標準化についての情報は、5.3節も参照のこと。

3.4.1 "simple" ヘッダー正規化アルゴリズム

"simple" ヘッダー正規化アルゴリズムは、ヘッダーフィールドにいかなる変更も加えない。ヘッダーフィールドは、署名もしくは検証されるメッセージ中にあるものがそのまま署名または検証アルゴリズムに渡されなくてはならない (MUST)。特に、ヘッダーフィールド名の大文字小文字を変更したり、ホワイトスペースを変更してはならない (MUST NOT)。

3.4.2 "relaxed" ヘッダー正規化アルゴリズム

"relaxed" ヘッダー正規化アルゴリズムは以下の手順を順に適用しなくてはならない (MUST):

3.4.3 "simple" 本文正規化アルゴリズム

"simple" 本文正規化アルゴリズムは、メッセージ本文の末尾にあるすべての空行を無視する。空行とは、改行文字を除けば長さが0になる行のことである。本文がないか、またはメッセージ本文の末尾に CRLF がなければ、CRLF が追加される。この他のメッセージ本文の変更は行なわれない。形式的に言えば、"simple" 本文正規化アルゴリズムは本文末の "0*CRLF"を1つの "CRLF" に変換する。

本文が完全に空だったり本文がない場合、本文は1つの "CRLF" に正規化される、つまり正規化された本文の長さは2オクテットになることに注意すること。

空の本文(これは "CRLF" に正規化される)に対する SHA1 の値は(base64 で)以下の通り:

uoq1oCgLlTqpdDX/iUbLy7J1Wic=

SHA256の結果は以下の通り:

frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=

3.4.4 "relaxed" 本文正規化アルゴリズム

"relaxed" 本文正規化アルゴリズムは以下の手順(a)と(b)を順に適用しなくてはならない:

  1. ホワイトスペースの削減:
  2. メッセージ本文の末尾にあるすべての空行を無視する。「空行」は3.4.3節で定義されている。本文が空ではないが CRLF で終了していない場合、CRLF が追加される。(電子メールの場合、SMTP を拡張したものを使っているか、またはSMTP 以外の転送メカニズムを使用している時に限りこのような状況が起こりえる。)

空の本文(これは入力値nullに正規化される)に対する SHA1 の値は(base64 で)以下の通り:

2jmj7l5rSw0yVb/vlWAYkK/YBwk=

SHA256の値は以下の通り:

47DEQpj8HBSa+/TImW5JCeuQeRkm5NMpJWZG3hSuFU=

3.4.5 本文長の制限

署名の計算対象を本文テキストの先頭からの一部に制限するために、本文長カウントをオクテット単位で指定することができる (MAY)。 本文長カウントが指定されない場合は、メッセージ本文全体が署名される。

本文長カウントによって、メッセージの署名者は、署名されたメッセージの本文末尾へのデータ追加を許可できる。本文長カウントは使用する正規化アルゴリズムに従って計算しなくてはならない (MUST)。例えば、正規化アルゴリズムによって無視されるホワイトスペースは本文長カウントに含まれない。本文長カウントを持つ MIME メッセージの署名者は、長さが MIME パートを閉じる境界文字列まで達していることを確認するべきである (SHOULD)。

本文長が0とは本文が全く署名されていないことを意味する。

いかなる種類の変更も許さない署名者は、"simple" 正規化アルゴリズムをヘッダーと本文の両方に使用すべきであり、本文長カウントを省略すべきだ。

3.4.6 正規化の例(参考)

以下の例では、実際のホワイトスペースは見やすくするためだけに使用される。実際の入出力テキストは、カッコで囲まれた記述子を用いて指定される:"<SP>"は空白文字を、"<HTAB>" はタブ文字を、"<CRLF>" CRとLFの組み合わせを意味する。例えば、"X <SP> Y" と "X<SP>Y" は同じ3文字を表現する。

例1:以下のメッセージを用いる:

A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
                <HTAB> Z <SP><SP><CRLF>
<CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<CRLF>
<CRLF>

ヘッダーと本文共に "relaxed" アルゴリズムを用いて正規化する。このときヘッダーは以下のように正規化される:

a:X <CRLF>
b:Y <SP> Z <CRLF>

本文は以下のように正規化される:

<SP> C <CRLF>
D <SP> E <CRLF>

例2:同じメッセージをヘッダーと本文共に "simple" アルゴリズムを用いて正規化する。ヘッダーは以下のように正規化される:

A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
       <HTAB> Z <SP><SP><CRLF>

本文は以下のように正規化される:

<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>

例3:ヘッダーには "relaxed" アルゴリズムを、本文には "simple" アルゴリズムを使用する。正規化されたヘッダは以下の通り:

a:X <CRLF>
b:Y <SP> Z <CRLF>

本文は以下のように正規化される:

<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>

3.5 DKIM-Signature ヘッダーフィールド

電子メールの署名は DKIM-Signature ヘッダーフィールドに格納される。このヘッダーフィールドには、署名と鍵を取得するためのすべてのデータが含まれている。DKIM-Signature の値は 3.2節 で述べたタグリストである。

DKIM-Signature ヘッダーフィールドは、[RFC5322] の 3.6節で定義されているトレースヘッダーフィールドと同等に扱うべきである (SHOULD)。したがってこれを並べ替えるべきではない(SHOULD NOT) し、メッセージの先頭に付加するべきである (SHOULD)。

DKIM-Signatureヘッダーフィールドはその作成または検証の際、他のフィールドが署名された後にそれ自身も必ず署名計算の対象となる。しかし計算または検証の際、DKIM-Signatureの"b="タグの値(署名の値)は空の文字として扱わなければならない(MUST)。 DKIM-Signature ヘッダーフィールド中の未知のタグも署名の計算に含めなければならない(MUST)が、検証者はそれ以外では無視しなくてはいけない (MUST)。 署名に含まれている他の DKIM-Signature ヘッダーフィールドは通常のヘッダーフィールドとして扱うべきである。特に "b=" タグを特別扱いしないこと。

各フィールド型のエンコーディングは以下の通り。qp-sectionと書かれてあるタグはMIME Part One [RFC2045] の 6.7節 に説明されている通りにエンコードされるのに加え、セミコロンを"=3B"に変換する。感覚的にこれはquoted-printableにエンコードされた1行のテキストである。dkim-quoted-printable の構文は 2.11節で定義されている。

DKIM-Signature ヘッダーフィールドで使われるタグのタイプと省略の可否は以下の通り認識できないタグは無視しなくてはならない (MUST)。

v=
バージョン(含まなくてはならない (MUST))。このタグは、この署名レコードに適用する仕様のバージョンを定義する。値は "1" でなくてはなりません (MUST)。検証者はこの値を文字列として比較しなければならないことに注意。例えば、"1" は "1.0" と同じではない。
a=
署名の生成に使用されたアルゴリズム(平文; 必須)。検証者は "rsa-sha1" と "rsa-sha256" をサポートしなくてはならない (MUST)。署名者は "rsa-sha256" を用いて署名すべきである (SHOULD)。アルゴリズムの説明は 3.3節を参照のこと。
b=
署名データ(base64; 必須)。この値ではホワイトスペースは無視されている。そして元の署名を再構築する際も ホワイトスペースを無視しなくてはならない(MUST)。特に署名プロセスにおいて、行の長さ制限を満たすために任意の場所に安全にFWSを挿入することがある。署名の計算方法については5章 署名者アクションを参照のこと。
bh=
"l="タグで制限された長さの正規化されたメッセージ本文のハッシュ値(base64; 必須)。この値ではホワイトスペースは無視されている。そして元の署名を再構築する際も ホワイトスペースを無視しなくてはならない(MUST)。特に署名プロセスにおいて、行の長さ制限を満たすために任意の場所に安全にFWSを挿入することがある。本文ハッシュ値の計算方法については3.7節 を参照のこと。
c=
メッセージの正規化アルゴリズム(平文; 記述は任意、デフォルトは "simple/simple")。このタグによって、メッセージの署名のために使用された正規化アルゴリズムを検証者に知らせる。 このタグは「スラッシュ」(%d47)文字で区切られた2つの名前で構成される。それぞれは、ヘッダーと本文の正規化アルゴリズムを順に示している。これらのアルゴリズムは3.4節で記述されている。1つのアルゴリズムだけが指定されている場合、そのアルゴリズムはヘッダーに対して使用され、本文に対しては "simple" アルゴリズムが使用される。例えば、"c=relaxed" は "c=relaxed/simple" と同じものとして扱われる。
d=
メッセージのメール配送経路への発信に責任を持つSDIDを特定。(平文; 必須)。 したがって、SDID の値は公開鍵の問い合わせを行うために使用される。SDIDはDKIMの鍵レコードが公開されている有効なDNS名に対応していなければならない(MUST)。署名者が特定のSDIDの作成、使用の根拠とするいかなる取り決めや意味も、またそれらを何かの根拠とすることも、DKIM署名仕様の範囲外である。これらの要件を満たしていない署名が提示された際、検証者は署名が不正であるとみなさなくてはならない (MUST)。
国際化ドメイン名は [RFC3490] で述べられているようにエンコードされなければならない (MUST)。
h=
署名されたヘッダフィールド(平文、ただし説明を参照のこと; 必須)。署名アルゴリズムに渡されたヘッダーフィールドを示す、コロンで区切られたヘッダーフィールド名のリスト。このフィールドには署名アルゴリズムに渡された順番の完全なヘッダーフィールドのリストがなくてならない (MUST)。このフィールドは署名時に存在しないヘッダーフィールド名を含んでいてもよい (MAY)。存在しないヘッダーフィールドは署名の計算には影響を与えない(つまり、それらは、ヘッダーフィールド名、区切りのコロン、ヘッダーフィールドの値、行末の CRLF を含むすべてがNull入力値として扱われる)。フィールドには作成中もしくは検証中の DKIM-Signature ヘッダーフィールドを含めてはならない (MUST NOT)が、他の DKIM-Signature ヘッダーは含んでもよい。 折りたたみ空白(FWS)はコロン区切りの左右どちらに含まれてもよい (MAY)。ヘッダーフィールド名を比較する際は、大文字と小文字を区別せずに実際のヘッダーフィールドと比較しなくてはならない(MUST)。このリストは空であってはならない (MUST NOT)。署名するヘッダーの選択に関する議論については、5.4節を参照のこと。
i=
SDID が責任を負っているエージェントまたはユーザ識別子(AUID)(dkim-quoted-printable; 記述は任意、デフォルトは空のローカルパートに「@」と"d="タグで指定されたドメインをつけたもの("@domain")。
構文は標準の電子メールアドレス形式で、ローカルパートは省略してもよい(MAY)。アドレスのドメインパートは、"d=" タグの値と同じかそのサブドメインでなくてはならない (MUST)。
国際化ドメイン名は "ToASCII" 関数を用いて[RFC3490]の4節に記載の手順により変換されなければならない。
AUIDは、電子メールアドレスと同じ構文を持つ仕様であるが、同じ意味合いを持つ必要はない。特に、ここで使われるドメイン名は DNS に登録されている必要はない、したがって、 DNS で名前解決できないかもしれない。またローカルパートはどのメールボックスにも関連しない名前空間のもので構わない (MAY)。名前空間の構造と意味づけの詳細は、署名者によって決定される。検証者や評価者がこれらの詳細について何を知っているか、またそれをどう使うかは DKIM 署名仕様の範囲外である。 署名者は AUID にそのユーザーの電子メールアドレスと同じ名前空間を使用してもよいし(MAY)、そのユーザーを表す別の方法を選んでもよい (MAY)。しかし、もし受信者がAUIDを、SDIDよりきめ細かく、信頼のおける識別子として使う選択肢として受信者に提供したいなら、署名者は同一の責任範囲内にあると評価させたい全てのメッセージに同じAUIDを使用すべきである(SHOULD)。
l=
本文長のカウント(符号なし10進整数の平文; 記述は任意、デフォルトはメッセージ全体)。このタグは、暗号化ハッシュに含まれている正規化後の電子メール本文のオクテット数を、本文直前のCRLFに続く0オクテットから数えた長さで検証者に伝える。この値は、正規化されたメッセージ本文の実際のオクテット数より大きくてはならない (MUST NOT)。
q=
コロンで区切られた、公開鍵取得のクエリー方法のリスト(平文; 使用は任意、デフォルトは "dns/txt")。各クエリー方法は、"type[/options]" の形式で記述され、options の構文と意味は type と指定されたその options による。複数のクエリーメカニズムがリストされている場合、クエリーメカニズムの選択によって署名の解釈を変更してはならない (MUST NOT)。実装は、認識されたクエリーメカニズムを示された順に使用しなくてはならない (MUST)。認識できないクエリーメカニズムは無視しなくてはならない (MUST)。
今のところ、唯一の有効な値は"dns/txt" である。これは本文書の他の場所で記述されている DNS TXT レコード検索アルゴリズムを意味する。 "dns" クエリータイプに対して定義された唯一のオプションは "txt" である。これは必ず含まれなくてはならない (MUST)。検証者と署名者は "dns/txt" をサポートしなくてはならない (MUST)。
s=
"d=" (ドメイン)タグの名前空間をさらに分けるセレクター(平文;必須)。
t=
署名のタイムスタンプ(符号なし10進整数の平文;推奨、デフォルトは未知の作成時間)。この署名が作成された時刻。書式は UTC タイムゾーンでの 1970年1月1日 00:00:00 からの経過秒数である。値は 10進 ASCII文字で符号なし整数として表現される。この値は31ビットまたは32ビット整数に収まるように制約されてはいない。実装は、少なくとも 10^12 (おおよそ AD 200,000年まで; これは40ビットに収まる)までの値を扱う用意をするべきである (SHOULD)。 サービス拒否攻撃を回避するため、実装は12桁以上の任意の値は無限であるとみなしてもよい (MAY)。うるう秒はカウントされない。実装は、未来の時刻をタイムスタンプにもつ署名を無視してもよい (MAY)。
x=
署名の有効期限(符号なし10進整数の平文; 推奨、デフォルトは有効期限なし)。書式は "t=" タグと同様に絶対時間として表現される。署名のタイムスタンプからの経過時間ではない。値は 10進 ASCII文字で符号なし整数として表現される。"t=" タグの値と同じ制約を持つ。検証者側での検証時刻が有効期限を過ぎている場合、署名を無効と見なしてもよい (MAY)。信頼できる時刻が得られるのであれば、検証時刻は検証者の管理ドメインでメッセージが最初に受信された時刻であるべきである。そうでなければ、現在時刻を用いるべきである。"x=" タグも "t=" タグもある場合、"x=" タグの値は "t=" タグの値より大きくなくてはならない (MUST)。
z=
コピーされたヘッダーフィールド(dkim-quoted-printable, ただし説明を参照のこと; 使用は任意、デフォルトは空)。メッセージ署名時に存在した、選択されたヘッダーフィールドの縦線(|)区切りのリスト。ヘッダーフィールドにはフィールド名と値の両方を含む。署名時に存在したすべてのヘッダーフィールドを含める必要はない。 このフィールドに "h=" タグに記載されているのと同じヘッダーフィールドを含んでいる必要はない。ヘッダーフィールドのテキスト自体は縦線 ("|", %x7C)文字をエンコードしなくてはならい(つまり、"z=" テキスト中の縦線はメタキャラクターであり、コピーされたヘッダーフィールド中の実際の縦線文字はエンコードされなければならない)。すべての空白は、コロンとヘッダーフィールド値の間の空白を含め、エンコードされなくてはならないことに注意。エンコード後、過度に長い行を避けるため、任意の場所に FWS を追加してもよい (MAY)。このようなホワイトスペースはヘッダーの値の一部ではなく、デコードの前に削除されなくてはならない (MUST)。
"h=" タグで参照されるヘッダーフィールドは、[RFC5322] メッセージヘッダーにあるフィールドを参照するのであって、"z=" タグにコピーされたフィールドを参照するものではない。コピーされたヘッダーフィールドの値は診断用である。
変換が必要な文字を含むヘッダーフィールド(おそらく [RFC5322] に準拠していない古い MTA からのもの)は MIME Part Three [RFC2047] に説明されているように変換されるべきである (SHOULD)。

3.6 鍵管理と表記

署名アプリケーションは、検証用公開鍵が申告された署名者のものであることを裏付ける一定の保証を必要とする。多くのアプリケーションでは、信頼できる第三者機関によって発行された公開鍵証明書を使用してこれを実現している。しかしDKIMでは、単に検証者が示された署名ドメインのDNS情報(または同程度のセキュリティのシステム)に公開鍵の取得を問い合わせるだけで、十分なレベルのセキュリティと大幅に強化されたスケーラビリティを達成することができる。

DKIMの公開鍵は、可能性として複数のタイプの公開鍵サーバーで複数の形式で保存することができる。鍵の保存方法と形式は、DKIMアルゴリズムの他の部分とは無関係である。

鍵を参照するアルゴリズムのパラメーターは、参照のタイプ("q="タグ)、署名者のドメイン(DKIM-Signatureヘッダーフィールドの"d="タグ)、そしてセレクター("s="タグ)である。

public_key = dkim_find_key(q_val, d_val, s_val)

この文書では、DNSのTXTレコードを使って鍵を配布するという一連の方法を定義する。他の方法は将来的に別途定義されるかもしれない。

3.6.1 テキスト表記

多くの公開鍵サーバーが、どんな形にせよ非定形のテキスト形式で鍵を渡そうとするだろう(たとえば、XMLフォームは、その意味では非定形テキストの形式ではない)。非定形のテキスト形式においても、DKIMの公開鍵には以下の定義は必ず適用されなければならない(MUST)。

全体的な構文は3.2節 のタグリストにある通り。現在有効なタグは以下に記述する。他のタグも提供されるかもしれないが(MAY)、その意味を理解できない実装においては無視されなければならない(MUST)。

v=
DKIMの鍵データのバージョン(平文;記述を推奨;デフォルトは"DKIM1")。明示的に記述する場合は"DKIM1"(クォーテーションマークを除く)でなければならない(MUST)。このタグは鍵データの最初のタグでなければならない(MUST)。これ以外の"v ="タグの値で始まるレコードは全て廃棄されなければならない(MUST)。検証者は、この値に文字列比較を行わなければならないことに注意。例えば、"DKIM1"は"DKIM1.0"と同じではない。
g=
鍵の粒度(平文;記述は任意、デフォルトは"*")。この値はDKIM-Signatiureの"i="タグのローカルパートと一致しなければならない(MUST)。(もし"i="タグが指定されていなければ、そのデフォルト値)一致のルールは、任意の一つの"*"が0文字かそれ以上の任意の文字列に相当するものとする(ワイルドカード)。このタグの値と一致しない署名アドレスを持つ電子メールは検証に失敗する。このタグの目的は、どの署名アドレスがこのセレクターを正規に使ってよいのかを制限することにある。例えば、第三者が代理で鍵を公開している時など、それは特殊な目的にのみ使われるべきである。ワイルドカードは、"user+*"と、"*-offer"または"foo*bar"のようなアドレスの一致に使われる。"g="のような空の値はいかなるアドレスとも一致しない。
h=
使用可能なハッシュアルゴリズム(平文;記述は任意、デフォルトはすべてのアルゴリズムが使用可能)。使われる可能性のあるハッシュアルゴリズムをコロンで区切ったリストにする。署名者と検証者は共に"SHA256"のハッシュアルゴリズムに対応しなければならない(MUST)。検証側は"sha1の"ハッシュアルゴリズムにも対応しなければならない(MUST)。不明なハッシュアルゴリズムは無視しなければならない(MUST)。
k=
鍵タイプ(平文;記述は任意、デフォルトは"RSA")。署名者、検証者共に"RSAの"鍵タイプをサポートしなければならない(MUST)。"RSA"の鍵タイプであれば、"p="タグでASN.1 DER [ITU-X660-1997] でエンコードされたRSAPublicKey [RFC3447]セクション3.1 と A.1.1を参照のこと)が使われている。(注:"p ="タグは更にBase64アルゴリズムを使用して値をエンコードしている)不明な鍵タイプは無視しなければならない(MUST)。
n=
人間に読ませる注意書き(quoted-printable;記述は任意、デフォルトは空)。いかなるプログラムもこれを解釈しない。このタグは、容量に制限のある、あらゆる鍵サーバーシステム(特にDNS)においても、控えめに使用されるべきである。これはエンドユーザーではなく、管理者による使用を意図している。
p=
公開鍵データ(base64;必須)。値が空であれば、この公開鍵は廃止済である。base64でエンコードされる前のこのタグの値の書式と意味は、"k ="タグにおいて定義される。
s=
サービスタイプ(平文;記述は任意、デフォルトは"*")。この鍵レコードが適用される、コロンで区切られたサービスタイプのリスト。あるサービスタイプの検証者が、その該当するタイプがここにリストされていない場合、この鍵レコードを無視しなければならない(MUST)。不明なサービスタイプは無視しなければならない(MUST)。現在定義されているサービスタイプは以下の通り:
*
すべてのサービスタイプに一致
email
電子メール(必ずしもSMTPに限定されない)
このタグは将来的に他のサービスによるDKIMの利用が定義された場合、指定されたサービスタイプ以外での使用を制限するためのものである。
t=
フラグ。コロンで区切った名称のリストで表記される(平文、記述は任意、デフォルトでフラグの設定はなし)。不明なフラグは無視しなければならない(MUST)。定義済のフラグは以下の通り:
y
このドメインは、DKIMをテスト中である。仮に署名が検証に失敗したとしても、テストモードの署名者からの電子メールを、署名なしの電子メールと区別して扱ってはならない(MUST NOT)。検証者は署名者に協力するために、テストモードの結果を調査しようとする可能性がある(MAY)。
s
DKIM-Signatureヘッダーフィールドに"i ="タグを使っている場合は必ず、その"i="タグの"@"の右側にあるドメインと同じドメインを"d="タグに持たなければならない(MUST)。つまり、"i="にあるドメインは"d="のサブドメインであってはならない(MUST NOT)。サブドメインの必要性がなければ、このフラグの使用を推奨する(RECOMMENDED)。
不明なフラグは無視しなければならない(MUST)。

3.6.1.1 DomainKeysとの互換性について

もしDKIMの鍵レコードの最初に"v="タグが見つからなければ、それはDomainKeys [RFC4870] の鍵と解釈されるかもしれない(MAY)。ここで定義されることは、"g="タグを除き、DomainKeysで使用されているものと上位互換性がある。DomainKeysの鍵レコードにおける空の"g="タグは、DKIMの"g=*"と同じと解釈される。

3.6.2 DNSの利用

鍵サービスとしてDNS TXTレコードを使う仕様は、ここに定義されている。あらゆる実装において、これらの対応は必須である(MUST)。

3.6.2.1 名前空間

全てのDKIM公開鍵は"_domainkey"という名前のサブドメインに格納される。DKIM-Signatureフィールドの"d="タグが"example.com"で、"s="タグが"foo.bar"の場合、DNSクエリーは"foo.bar._domainkey.example.com"になる。

3.6.2.2 鍵を格納するリソースレコードタイプ

使用するDNSリソースレコードタイプは、クエリタイプオプション("q=")タグで指定される。この基本仕様で定義されるオプションは、TXTリソースレコード(RR)の使用を示す"txt"のみである。この標準における後の拡張で、別のRRタイプを定義する可能性がある。

TXT RRの文字列は、使用の前に空白文字が間に入らないよう連結されていなければならない(MUST)。TXT RRはセレクター名毎にユニークでなければならず(MUST)、複数のレコードがRRセットの中にあった場合の結果は定義されていない。

TXT RRはセクション3.6.1の記述の通り、エンコードされている。

3.7 メッセージハッシュの計算

署名も検証も共に、メッセージから二つの暗号化ハッシュを計算するところからスタートする。署名者は、5章署名動作に記述されたように署名のパラメーターを選択する。また、検証者は DKIM-Signature で指定されたパラメーターを使い、どのヘッダーフィールドを検証するかを決める。以下の議論では、DKIM-Signature の中に(検証時に)存在するか、(署名時に)作成されるタグの名前が使われている。なお、正規化(3.4節)は電子メールを署名または検証する準備としてのみ行われ、いかなる場合にも電子メールの配送に影響を与えない。

署名者/検証者は、電子メールメッセージ本文に対して一つ、選ばれたヘッダーフィールドに対して一つ、合計二つのハッシュを作成しなければならない(MUST)。

署名者は以下に示される順番でそれらを計算しなければならない(MUST)。検証者は、この順番で計算した結果と同じ意味を持つのであれば、都合の良い順番で計算してもよい(MAY)。

ハッシュ作成のステップ1では、署名者/検証者は"c="タグで指定された正規化アルゴリズムで正規化され、"l="タグで指定された長さに切られた電子メールメッセージ本文をハッシュしなければならない(MUST)。そのハッシュ値は、base64形式に変換され、DKIM-Signatureの"bh="タグに挿入されるか(署名者の場合)、それと比較される(検証者の場合)。

ハッシュ作成のステップ2では、署名者/検証者は以下に示す順番で、ハッシュアルゴリズムに以下の値を渡さなければならない(MUST)。

  1. "h="タグに指定されたヘッダーフィールドの値を、そのタグに指定された順で、"c="タグに指定されたヘッダー正規化アルゴリズムを使って正規化された形で。各ヘッダーフィールドは単一のCRLFで区切らなければならない(MUST)。
  2. 電子メールの中に存在する(検証者の場合)、または挿入される(署名者の場合)DKIM-Signatureヘッダーフィールドから"b="タグの値(及びその前後の全ての空白文字)を削除し(つまり、空の値として扱い)、"c="タグで指定された正規化アルゴリズムで正規化し、末尾のCRLFを除いた値。

DKIM-Signatureヘッダーフィールドにある全てのタグとその値は、"b="(署名)タグの値の部分を唯一の例外として、全て暗号化ハッシュの中に含められる。"b="タグの値はnullとして扱われなければならない(MUST)。仮に検証者に理解されない可能性があっても、全てのタグは含まれなければならない(MUST)。(DKIM-Signature)ヘッダフィールドは、他のヘッダーフィールドと一緒ではなく、電子メール本文の後に、"c="(正規化)タグで指定された通りに正規化してハッシュアルゴリズムに渡さなければならない(MUST)。他の DKIM-Signature ヘッダーフィールドを署名してもよいが (MAY)、DKIM-Signature ヘッダーフィールドをそれ自身の h= タグの中に含めてはならない (MUST NOT)。(4章を参照)。

base64またはquoted-printableでエンコードされて配送される電子メールのハッシュ値を計算する場合は、署名者はエンコードの後にハッシュを作成しなければならない(MUST)。同様に、検証者はbase64またはquoted-printableのテキストをデコードする前の値をハッシュに組み込まなければならない(MUST)。しかしハッシュ値は、SMTPの"dot-stuffing"("."で始まる行が[RFC5321]に定義されたSMTPの"end-of-message"の印と混同しないために行われる修正)のような配送レベルのエンコードの前に作成されなければならない(MUST)。

3.4節に記述された正規化の手続きを除いて 、DKIMの署名プロセスは電子メール本文を単純なオクテット文字列として扱います。DKIMメッセージは、プレーンテキストでもMIMEフォーマットでもよい(MAY)。もし中身がMIMEでも特別な扱いはしない。MIMEフォーマットの添付ファイルも署名される本文に含まれなければならない(MUST)。

より正式には、署名のためのアルゴリズムは以下の通り:

body-hash = hash-alg(canon_body)
header-hash = hash-alg(canon_header || DKIM-SIG)
signature = sig-alg(header-hash, key)

ここで"sig-alg"とある部分は"a="タグに指定された署名アルゴリズム、"hash-alg"は"a="タグで指定されたハッシュアルゴリズム、"canon_header"と"canon_body"は3.4節に定義されているように(DKIM-Signatureヘッダーフィールドは除いて)、それぞれ正規化されたメッセージヘッダーと本文、"DKIM-SIG"はDKIM-Signatureから署名そのものを抜き、"body-hash"を"bh="タグに含め、正規化したものである。

3.8 親ドメインによる署名

いくつかの状況では、あるドメインがそのサブドメイン毎に別々のセレクター(鍵レコード)を保有する必要がなく、代表して全てのサブドメインに対して署名を適用するのが望ましい場合がある。 デフォルトでは、鍵レコードに対応する秘密鍵は、そのドメイン内に属するいかなるサブドメインの電子メールに対しても使うことができる。;例えば、"example.com"の鍵レコードは、AUID(署名の"i="タグの値)が"sub.example.com"や"sub1.sub2.example.com"の電子メールを検証する場合にも使うことができる。 これが望ましくない時にその鍵の機能を制限するには、AUIDのドメインの有効範囲を制限するために"t="タグに"s"フラグを立てることができる(MAY)。もし参照した鍵レコードの"t="タグに"s"フラグが含まれていたら、そのAUID("i="タグの値)はSDID("d="タグの値)と同じドメインでなければならない(MUST)。もしこのフラグが存在しなければ、AUIDのドメインはSDIDまたはそのサブドメインと同じでなければならない(MUST)。

3.9 SDID と AUID の関係

DKIMの主な役割は、署名者から受信側の身元評価モジュールに対して、責任の所在を示す署名者ドメイン識別子(SDID)を通知することにある。または、DKIMは責任を負うべき単一のエージェントまたはユーザー識別子(AUID)を任意に提供することもできる(MAY)。

したがって、受信側の身元評価モジュールへのDKIMの必須出力は、単一のドメイン名である。DKIMの出力として使われる限り、ドメイン名は単なるドメイン名として以外の意味はない。つまり所有者固有にあり得るいかなる意味も、DKIMの範囲外である。それは、DKIMの身元識別の役割において、身元評価モジュールはそれ以上の意味の推察はできない。

受信側のDKIM検証者は署名ドメイン識別子(d=)を、それを処理する身元評価モジュールに対して通知しなければならない(MUST)。そして、もしエージェントまたはユーザー識別子(i=)がある場合は、それも通知することができる(MAY)。

受信者が、そのいずれかの識別子に、体系的に構築されたいかなる意味をさらに見いだそうとしても、これは経験則上の機能であって、DKIMの仕様と意味の範囲外である。したがって、それはもっと高次のサービス、例えば様々な入力とヒューリスティック分析を組み込んだ配送処理フィルターのようなサービスに属する。

4. 複数の署名の意味

4.1シナリオ例

メッセージが複数の署名を持っているかもしれない理由は多くある。例えば、ある署名者が、移行期間中などの理由で異なるハッシュや署名アルゴリズムで複数回署名を行うかもしれない。

同じように、署名者によっては(厳格な検証者に対応するため)、全てのヘッダーを含んだ"l="タグなしで一度署名した後、(他の検証者へ達する過程でメッセージが変更される可能性を考え)限られたヘッダーと"l="タグでもう一度署名するかもしれない。 検証者は都合の良い方の署名を選ぶことができる。

もちろん、メッセージが、複数の署名者を経由している為に、複数の署名を所持している可能性もある。よくあるケースとして、署名されたメッセージが、さらに全てのメッセージに署名を行うメーリングリストを通る場合が考えられる。両方の署名の検証に成功したとして、受信者はどちらかの署名が信頼できる送信者からのものであることがわかれば、受け取る選択をするかもしれない。

複数の署名者がいる同じような例として、学校などの同窓会サイトによくあるような転送サービスが考えられる。

4.2 解釈

署名をメッセージに付加する署名者は、"h="オプションが通常意味するところを使い、単に新しいDKIM-Signatureというヘッダーを作成しているに過ぎない。 署名者は5.4節に記述されたトレースヘッダーに署名する手法を使い、先につけられていたDKIM-Signatureヘッダーをさらに署名してもよい(MAY)。

署名者は違うパラメータを含んだ、複数のDKIM-Signatureヘッダフィールドを追加することができる(MAY)。 例えば、署名者は、移行期間中に2つの異なるハッシュアルゴリズムを使用して署名を生成するかもしれない。

署名者は仮に検証に失敗するとわかっていても、署名しているメッセージからいかなるDKIM-Signatureヘッダーフィールドも削除するべきではない(SHOUL NOT)。

複数の署名を持つメッセージを評価する際、検証者は署名を自主的かつ自己の要件に合うように評価するべきである(SHOULD)。例えば、ある検証者が、将来サポートされなくなる可能性のある暗号化アルゴリズムによる署名を受け入れないポリシーを選択していれば、そのような署名を無効とするだろう。 検証者は任意にどんな順番で署名を処理してもよい(MAY);例えば、検証者によっては他の署名よりも先に、メッセージヘッダーのFromフィールドに対応する署名から処理するかもしれない。署名の選択についての詳細は6.1節を参照すること。

検証者は、検証に失敗した署名については、それが最初からメッセージ中になかったかのように無視すべきである(SHOULD)。 検証者は、その要件を満たす正当な署名を確認するまで、署名の検証を続けるべきである(SHOULD)。DOSアタックの可能性を制限するため、検証者は、検証しようとする署名の総数を制限してもよい(MAY)。

5. 署名者アクション

次の手順は以下の順番で署名者によって実行される。

5.1 電子メールが署名されるべきか、また誰によって署名されるべきかを決定する

署名者は明示的に、秘密鍵とそれに対応する公開鍵とセレクター情報に関する必要情報を持つドメインの電子メールのみに署名することができる。しかしながら、秘密鍵の欠如の他に、署名者が電子メールに署名しないことを選択することができる理由が他にもいくつかある。

電子メールが何らかの理由で署名できない場合、その電子メールをどう処理するかはローカルポリシーによって決定される。

5.2 秘密鍵と対応するセレクター情報を選択する

この仕様は、署名者がどの秘密鍵とセレクター情報を選択し、使用すべきかという基準を定義するものではない。現在、すべてのセレクターはこの仕様の範囲内において等しいので、決定は主に管理上の便宜の問題である。秘密鍵の配布と管理もまたこの文書の範囲外である。

5.3 転送変換を防ぐためにメッセージを正規化する

一部のメッセージ、特に8ビット文字を使ったものは、7ビット形式への変換という形で配送中に変更されることがよくある。 このような変換はDKIM署名を壊す。そのような破壊の可能性を最小化するために、署名者は署名する前に [RFC2045] に記述された quoted-printable や base64 などの適切な MIME content transfer endoding にメッセージを変換すべきである (SHOULD)。このような変換は DKIM の範囲外であり、実際のメッセージは DKIM のアルゴリズムに渡される前に MUA や MSA で 7ビット MIME に変換すべきである (SHOULD)。

同様に、RFC5322 や RFC2045 に準拠していないメッセージは、その内容を訂正したり解釈したりする。一般的な変更例については [RFC4409] の 8項を参照のこと。このような"修正"は DKIM 署名を壊したり、望ましくない影響を与えたりするかもしれない。したがって、検証者は準拠していないメッセージを検証すべきではない (SHOULD NOT)。

任意のローカルエンコーディングでメッセージが署名者に渡されると、送信前に変更されることになるが、標準的な [RFC5322] 形式へのその変更は署名する前に行わねばならない (MUST)。特に、(いくつかのシステムで行区切りとして使用される)むき出しの CR や LF 文字はメッセージが署名される前に SMTP 標準の CRLF シーケンスに変換されなければならない (MUST)。この種の変換は、署名アルゴリズムに提示されたバージョンだけではなく、実際に受信者に送信されるメッセージにも適用されるべきである(SHOULD)。

もっとわかりやすく言えば、署名者はローカルや内部形式ではなく、検証者が本来受け取るべき状態のまま署名しなければならない(MUST)。

5.4 署名するヘッダーフィールドを決定する

From ヘッダーフィールドは署名されなければならない (つまり、署名した結果生成される DKIM-Signature ヘッダーフィールドの h= タグに必ず含まれる) (MUST) 。署名者は、配信中に正規の方法で修正または削除されそうな既存のヘッダフィールドに署名するべきではない。 (SHOULD NOT) 特に、[RFC5321] は配信中における Return-Path ヘッダーフィールドの修正および削除をはっきりと許可している。署名者は、署名者の裁量で署名時に存在するその他どのようなヘッダフィールドを含めてもかまわない (MAY)。

DKIM-Signature header field は常に暗黙のうちに署名されるが、"h=" タグに含めてはならない (MUST NOT)。ただし、元のメッセージにある署名を含めて署名する場合は除く。

署名者は、存在しないヘッダーフィールドに署名したことを主張してもよい (MAY) (すなわち署名者は、そのヘッダーフィールドがメッセージに存在しない場合においても、ヘッダーフィールド名を "h=" タグ に含めてもよい(MAY))。 署名を計算する際、(ヘッダーフィールド名、ヘッダーフィールド値、すべての句読点、末尾の CRLF なども含め)存在しないヘッダーフィールドはNull文字列として扱わなければならない。

署名者が、(Received のように) メッセージ中に複数回出現する既存のヘッダーフィールドに署名することを選んだ場合、署名者は、ヘッダーブロックにあるそのヘッダーフィールドのうち物理的に最後のインスタンスに署名しなければならない (MUST)。署名者がこのようなヘッダーフィールドの複数のインスタンスに署名しようとするとき、DKIM-Signature ヘッダーフィールドの "h=" タグ にはこのヘッダーフィールド名を複数回含まなければならない (MUST)。さらに、このようなヘッダーフィールドは、ヘッダーフィールドブロックの下から上の順に署名しなければならない (MUST)。 署名者は、実際に対応するヘッダーフィールドより多くのヘッダーフィールド名のインスタンスを "h=" タグ に含むことができる (MAY)。これは、その名前のヘッダーフィールドが追加されるべきではない (SHOULD NOT) ことを示すためである。

署名者は、配送途中に後からインスタンスが追加される可能性のあるヘッダーフィールドへの署名には注意すべきである。なぜなら、追加されるヘッダーフィールドは署名済みのヘッダーフィールドの後ろに挿入されたり、並べ替えられたりするかもしれないからである。(Received のような)トレースヘッダーフィールドおよび Resent-* ブロックのみが [RFC5322] で並べ替えを禁止されている。特に、DKIM-Signature ヘッダーフィールドは、配信経路途中の MTA によって並べ替えられることもあるため、DKIM-Signature ヘッダーフィールドへの署名はエラーが発生しやすい。

5.5 推奨される署名の内容

様々な検証者との互換性を最大にするために、署名者はメッセージを署名する際、このセクションに示された手順を実践することを推奨する。 しかし、これらは一般的なケースに適用される一般的な推奨事項であり、特定の送信者が独自の状況で必要に応じて、これらのガイドラインを変更したい場合がある。1つかそれ以上の推奨されるヘッダーフィールドが署名されていない(常に署名されなければならない From は除く)場合や、1つ以上の推奨されないヘッダーフィールドが署名されている場合でも、検証者は署名を検証できなければならない (MUST)。 検証者は、ヘッダーまたは本文の十分な部分をカバーしていない署名を無視するという選択肢を持っており、それと同様に信頼していない身元からの署名を無視する可能性があることに注意すること。

署名対象のメッセージに次のヘッダーフィールドがある場合、そのヘッダーフィールドは署名に含めるべきである (SHOULD):

次のヘッダーフィールドは署名に含めるべきではない (SHOULD NOT):

(上に記されていない)任意のヘッダーフィールドは、通常は署名に含めるべきではない (SHOULD NOT)。なぜなら、検証前に同じ名前の追加のヘッダーフィールドが、仕様上の問題なく追加されたり、並べ替えられたりする可能性があるためである。このルールには、正当な例外もありうる。なぜなら、メッセージに適用されるかもしれない多種多様なアプリケーション固有のヘッダーフィールドのいくつかは、複製されたり、修正されたり、並べ替えられたりする可能性が低いからである。

署名者は、処理するメッセージの種類やリスクの回避の観点に基づいて正規化アルゴリズムを選択すべきである (SHOULD)。たとえば、主に領収書を送信している電子商取引サイトでは、一般的には "simple" 正規化が選ばれるだろう。(そのようなサイトにおいては)メーリングリストやメッセージを変更する可能性のあるソフトウェアによって処理される可能性は低い。主に人から人へ電子メールを送信するサイトでは、"relaxed" 正規化を使用して、 配送中の変更に強くすることが選ばれるだろう。

署名者は、メッセージにテキストを追加する中間メールプロセッサに対応しようとする場合を除いて "l=" を使用すべきではない (SHOULD NOT)。たとえば、多くのメーリングリストのプロセッサは、メッセージ本文に "退会" 情報を追加する。署名者が "l=" を使用する場合は、カウントを計算する際に、署名時点でのメッセージ本文全体を含めるべきである (SHOULD)。特に、検証者によっては無意味な署名として解釈されるかもしれないため、署名者は本文の長さとして 0 を指定すべきではない (SHOULD NOT)。

5.6 メッセージハッシュと署名を計算する

署名者は3.7節に記載されているようにメッセージハッシュを計算し、そして選択された公開鍵アルゴリズムを使って署名しなければならない (MUST)。これは、本文のハッシュとそのヘッダーハッシュの署名を含む DKIM-Signature ヘッダーフィールドとなり、そのヘッダーは DKIM-Signature ヘッダーフィールド自体を含む。

DKIM を実装し、メッセージ再送前にメッセージやヘッダーフィールドを変更する (たとえば登録解除情報を挿入するなど) メーリングリストマネージャーのような存在は、受信したメッセージに署名があるかどうかをチェックすべきであり (SHOULD)、そのような変更はメッセージに再署名する前にされなければならない (MUST)。

署名者は、ハッシュに含む本文のバイト長を制限した上で署名しても良い(MAY)。実際にハッシュ化された長さは DKIM-Signature ヘッダーフィールドの "l=" タグに挿入すべきである。

5.7 DKIM-Signature ヘッダーフィールドを挿入する

最後に、署名者は前の段階で作成した DKIM-Signature ヘッダーフィールドを、電子メールを送信する前に挿入しなければならない (MUST)。DKIM-Signature ヘッダーフィールドは、上記のようなハッシュの計算に使われたものと同じでなければならない (MUST)。ただし、"b=" タグ の値は例外で、前の段階で適切に計算され署名されたハッシュでなければならない (MUST)。適切な署名とは、DKIM-Signature ヘッダーフィールドの "a=" タグで指定されたアルゴリズムと、5-2節にある方法で選択されたDKIM-Signature ヘッダーフィールドの "s=" タグ のセレクターが示す秘密鍵を使用して署名することである。

DKIM-Signature ヘッダーフィールドは、ヘッダーブロック中の他の DKIM-Signature フィールドの前に挿入しなければならない (MUST)。

6. 検証者アクション

署名者はいつでも公開鍵を削除したり、無効にすることができる(MAY)ため、検証は適切なタイミングで行うことを推奨する。 多くの構成では、検証を行うタイミングにもっとも適した場所は、外部との境界にある MTA での受信時か、その直後である。特に、エンドユーザーがメッセージを受け取るまで検証を先延ばしすることは避けた方がよい。

外部との境界、あるいは中間に位置する MTA はメッセージの署名を検証してよい(MAY)。検証を行った MTA は、受信したメッセージに検証ヘッダーフィールドを追加することで検証結果を通知してもよい (MAY)。これにより、既存の MUA を使い続けられるので、ユーザーにとっては物事がかなりシンプルになる。ほとんどの MUA は、メッセージヘッダーフィールドまたはコンテンツによってメッセージをフィルターする機能を持っている。これらのフィルターを使い、ユーザーは署名されていないメールに対して、好きなポリシーを適用できる。

検証を行う MTA は、署名されたメッセージに検証ヘッダフィールドを適用するかどうかに関わらず、検証不能なメールについては独自のポリシーを適用してよい(MAY)。

検証者は、下記の手順を順に実施したものと意味的に等しい結果となるよう検証しなければならない (MUST)。 実際には、これらの手順のいくつかは性能を向上させるために並列に実行することができる。

6.1 メッセージからの署名抽出

(複数ある)DKIM-Signatureヘッダーフィールドのうち、どれから検証者が検証するか、その順番は定義されていない。検証者は好きな順番で検証してよい(MAY)。 例えば、ある実装では署名を記述順で検証するかもしれないし、別の場合はFrom:ヘッダーフィールドの中身に対応した署名を、他の署名より先に検証するかもしれない。検証者は、複数の DKIM-Signature ヘッダーフィールドの順番に何ら根源的な意味を見いだしてはならない (MUST NOT)。 特に、リレー中にヘッダーフィールドの順序がランダムに置き換わる可能性が、十分考えられるからである。

検証者は、1つかそれ以上の不正な署名があり、なおかつ正しい署名のないメッセージを、全く署名がないメッセージと区別して扱うべきではない(SHOULD NOT)。そのような使いは、ローカルポリシーの問題であり、この文書の範囲外である。

署名の検証が成功すると、検証者は、実装上の判断により、処理を終了するか、他の署名の検証をしようと試みることになる。 検証者は、DoS 攻撃を避けるために検証しようとする署名の数を制限してもよい(MAY)。

以下の記述で、”ステータス(説明)を返す” (ここで、”ステータス” には “PERMFAIL” または “TEMPFAIL” が入る)と書いてあると、検証者は署名の処理をただちに中止しなければならない(MUST) ことを意味する。 もし他にも署名があるならば、検証者は次の署名に進むべきであり(SHOULD)、不正な署名は完全に無視すべきである (SHOULD)。 もしステータスが"PERMFAIL"の場合は、署名の検証は失敗し、二度と試されるべきではない。もしステータスが "TEMPFAIL" の場合、その署名は現時点においては検証できなかったものだが、後でもう一度試してもよい。 検証者は、ローカルのキューに溜めたり、451/4.7.5 SMTP 応答を返すことで、後で処理をするためにメッセージを遅延させるか、他の署名を検証してもよい。もし正しい署名が見つからず、どれか一つでも TEMPFAIL ステータスになった場合は、検証者はそのメッセージを後で処理するために保存してもよい (MAY)。 “(説明)” の部分は決められた表記法ではなく、単にわかりやすくするためのものである。

検証者は、どんな DKIM-Signature ヘッダーフィールドであれ、認証できなかった署名を持つものは無視すべきである (SHOULD)。 複数の署名の有効性を確認しようとする検証者は、もしあれば、次の署名に進むべきである(SHOULD)。その際、検証者は後の処理の参考に、無効な署名が存在したという事実を記録してもよい(MAY)。

有効性を確認するそれぞれの署名に対し、以下に示す手順は、その順番で処理するのと同じ意味の結果が出るやり方で処理すべきである。

6.1.1 署署名ヘッダーフィールドの有効性チェック

実装において、DKIM-Signature ヘッダーフィールドの書式と値の有効性は厳しくチェックされなければならない。つまり、矛盾する値や不正な値があれば、検証者はヘッダーフィールドを完全に無視し、PERMFAIL (署名構文エラー) を返さなければならない (MUST)。 「何を受け入れるかは自由」という考えは、この場合、セキュリティ的に非常に悪い戦略である。 ただし、これには DKIM-Signature ヘッダーフィールドの中に未知のタグがあることは含まないことに注意すること。未知のタグは明示的に許されている。検証者は、本文書の仕様に矛盾した "v=" タグを持つ DKIM-Signature ヘッダーフィールドを無視して、 PERMFAIL (互換性のないバージョン)を返さなければならない (MUST)。

もし、3.5 節で「必須」と記載されているタグのいずれかが、DKIM-Signature ヘッダーフィールドから抜けている場合、検証者は DKIM-Signature ヘッダーフィールドを無視し、PERMFAIL (必須タグのない署名)を返さなければならない。

もし、DKIM-Signature ヘッダーフィールドに "i=" タグが含まれていなければ、検証者は "i=" タグの値が "@d" であるかのように振る舞わなくてはならない (MUST)。ここで "d" は "d=" タグの値である。

検証者は、 "d=" タグで指定されたドメインが "i=" タグのドメイン部分と同じか、もしくはその親ドメインであることを確認しなければならない (MUST)。 もし確認できなければ、そのDKIM-Signature ヘッダーフィールドを無視しなければならず (MUST)、検証者はPERMFAIL (ドメイン不一致)を返すべきである。

"h=" タグに From ヘッダーフィールドが含まれていない場合、検証者は、 DKIM-Signature ヘッダーフィールドを無視し、PERMFAIL(From ヘッダが未署名)を返さなければならない (MUST)。

もし署名に"x=" タグが含まれ、その有効期限が切れている場合、検証者は DKIM-Signature ヘッダーフィールドを無視し、PERMFAIL (署名の有効期限切れ)を返してもよい (MAY)。

もし署名者が“d=” タグに使ったドメインが、その有効な署名主体として考えにくい場合、検証者はDKIM-Signature ヘッダーフィールドを無視してもよい (MAY)。 例えば、"d=" の値が "com" となっている "co.uk" の署名は無視される可能性がある。受け入れられないドメインのリストは、設定で変更可能であるべきである (SHOULD)。

検証者は他のなんらかの理由で DKIM-Signature ヘッダーフィールドを無視し、PERMFAIL (受け入れ不能な署名ヘッダー)を返してもよい (MAY)。例えば、検証者にとっては不可欠なヘッダーフィールドが署名されていない場合が挙げられる。 典型的な例として、例えばMIME ヘッダーフィールドに署名がない場合、検証者が避けたいと思ういくつかの攻撃が可能かもしれない。

6.1.2 公開鍵の取得

検証プロセスを完了するためには、署名の公開鍵が必要となる。公開鍵を取得するプロセスは、DKIM-Signature ヘッダーフィールドの "q=" タグ で定義されたクエリータイプに依存する。 当然、署名情報の抽出プロセスが完全に成功した場合にのみ、公開鍵が必要である。鍵の管理と表記の詳細は3.6節に記されている。 検証者は、公開鍵レコードが有効であることを確認しなければならず(MUST)、不正な形式の公開鍵レコードはすべて無視しなければならない (MUST)。

メッセージの有効性を確認する際、検証者は以下に示す手順の順に処理した場合と同じ意味の結果が得られるよう、以下を行わなければならない(MUST)。(実装によっては、結果の意味が変わらない限り、これらの手順を並列に処理したり、順番を入れ替えることもできる。)

  1. 3.6節で示したように、"q=" タグ内のアルゴリズム、"d=" タグのドメイン、 "s=" タグのセレクターを用いて公開鍵を取得する。
  2. 公開鍵取得クエリーに応答がない場合、検証者はこのメールの受け入れを延期し、TEMPFAIL(鍵が取得できない)を返してもよい (MAY)。 受信 SMTP セッション中に検証が行われている場合、これを 451/4.7.5 SMTP 応答コードによって通知してもよい (MAY)。 別の方法として、検証者は署名を後で再処理するためにメッセージをローカルのキューに保存したり、署名を無視してもよい (MAY)。 ローカルのキューにメッセージを保存する場合、DoS攻撃の対象となることに注意すること。
  3. 対応する鍵レコードが存在しないために公開鍵のクエリーが失敗した場合、検証者はすぐにPERMFAIL(署名に対応する鍵がない)を返さなければならない(MUST)。
  4. 公開鍵のクエリーに複数の鍵レコードが返された場合、検証者は1つの鍵レコードを選択してもよいし、それぞれの鍵レコードに対する残りの手順の実行をすべてのレコードに対して繰り返してもよい。どちらにするかは実装者の裁量となる。鍵レコードの順番は規定されていない。検証者が鍵レコードの繰り返し実行を選ぶのであれば、以降この節において「...を返す」という言葉は、「次の鍵レコードがあればそれを実行。もしなければ、通例の手順にて次の署名の検証を行う」 という意味となる。
  5. クエリーに対して返ってきた結果がこの仕様で定義されたフォーマットを守っていない場合、検証者はその鍵レコードを無視し、PERMFAIL(鍵の構文エラー)を返さなければならない (MUST)。 攻撃を未然に防ぐため、検証者は、鍵レコードの構文が有効か注意深く確認することを強く勧める。 特に、検証者は実装されていないバージョンコード ("v=" タグ) を持つ鍵を無視しなければならない (MUST)。
  6. もし、公開鍵の "g=" タグとメッセージの署名ヘッダーフィールドの "i=" タグのローカルパートが一致しない場合、検証者は鍵レコードを無視し、PERMFAIL(不適当な鍵)を返さなければならない(MUST)。メッセージの署名の中に "i=" タグのローカルパートがない場合、"g=" タグが "*" (ドメインのすべてのアドレスが有効) であるか、"g=" タグ全体が省略されていなければならない("g=" タグのデフォルトは "g=*")。そうでない場合、検証者は鍵レコードを無視し、PERMFAIL(鍵が適用不能)を返さねばならない (MUST)。この確認以外で、検証者は "g=" タグを持つ鍵で署名されたメッセージと、持たない鍵で署名されたものとで少しでも違う扱いをすべきではない(SHOULD NOT)。特に検証者は、"g=" タグを用いて個別署名を持つように見えるメッセージを、ドメイン署名のメッセージより優位に扱うべきではない(SHOULD NOT)。
  7. もし"h=" タグが公開鍵レコードにあり、DKIM-Signature ヘッダーフィールドの "a=" タグで示されたハッシュアルゴリズムが "h=" タグに含まれない場合、検証者は鍵レコードを無視し PERMFAIL (不適切なハッシュアルゴリズム) を返さなければならない (MUST)。
  8. 公開鍵のデータ("p="タグ)が空である場合、この鍵は失効しているので、検証者は、署名のチェックに失敗したとして扱い、PERMFAIL(鍵が失効)を返さなければならない(MUST)。失効した鍵と削除された鍵レコードには意味的な違いは定義されていない。
  9. 公開鍵のデータが DKIM-Signature ヘッダーフィールドの "a=" タグ や "k=" タグ によって定義されるアルゴリズムや鍵タイプに適していない場合、検証者は速やかにPERMFAIL (不適切な鍵アルゴリズム) を返さねばならない (MUST)。

6.1.3 検証の計算

署名者と公開鍵が確定したら、以下の手順と意味的に同等の処理により署名の検証を行う。

  1. "c=" タグで定義されたアルゴリズム、"l=" タグで指定された本文長、 "h=" タグ内のヘッダーフィールド名に基づき、3.7節に記載されているように正規化されたメッセージを用意する(この正規化されたメッセージは実際にインスタンスを作成する必要がないことに注意)。実際のメッセージのヘッダーフィールドに対し "h=" タグ内のヘッダーフィールド名を照合するときは、大文字小文字を区別せず比較しなければならない (MUST)。
  2. "a="タグで指定されるアルゴリズムに基づいて、3.7節に記載の通り正規化したコピーからメッセージのハッシュ値を計算する。
  3. 前の手順で計算した、正規化されたメッセージ本文のハッシュと、 "bh=" タグ 内のハッシュ値が一致するかを検証する。ハッシュが一致しない場合、検証者は署名を無視し、PERMFAIL(本文ハッシュの検証に失敗)を返すべきである (SHOULD)。
  4. ""a="タグで指定された公開鍵アルゴリズムに適した仕組みを使い、b="タグにある署名をヘッダーのハッシュ値に対して検証する。 署名が有効でない場合、検証者は署名を無視し、PERMFAIL (署名の検証に失敗)を返すべきである (SHOULD)。
  5. それ以外の場合、署名は正しく検証されている。

署名の "l=" タグ に指定されている本文長が、検証アルゴリズムに渡される本文のバイト数を制限する。 その制限を超えるすべてのデータは、DKIMにおいては無効である。したがって、検証者は指定された本文長を超えたメッセージを疑わしいものとして扱うかもしれない。たとえば、メッセージを指定された本文長に切り詰め短縮する、署名が無効であると宣言する(PERMFAIL (署名されていない本文)を返す、など)、ポリシーモジュールに部分的な検証であることを伝える、といった扱いが考えられる。

6.2 検証結果の通知

検証者がメールシステムの他の部分に検証結果を通知したければ、どんな方法であれ自分たちが適当だと思う方法で通知してよい。たとえば、(エンドユーザーに)渡す前のメッセージに電子メールのヘッダーフィールドを追加するという実装も可能である。 このようなヘッダーフィールドはすべて、ヘッダーフィールドブロック内で、既存のどの DKIM-Signature ヘッダーフィールドよりも、また以前から存在するどの認証結果ヘッダーフィールドよりも前に挿入するべきである (SHOULD)。Authentication-Results ヘッダーフィールド ([RFC5451])はこの目的に使用してよい (MAY)。

6.3 結果の解釈/ローカルポリシーの適用

身元評価モジュールがとりうるアクションについて記述することはこの仕様の範囲外だが、有効な SDID を持つメールは身元評価モジュールに対し、検証されないメールでは得られない情報の機会を提供できる。 具体的には、検証に成功した電子メールからは想定内の識別子が得られ、これを使って信頼やレピュテーションなど、他の決断の確実な根拠となり得る。 逆に、検証に成功しない電子メールは、信頼や評価を下すための信頼できる識別子を持たない。 検証に成功しない電子メールは信頼を欠き、良いレピュテーションもないものとして扱うのが妥当である。

大体において、検証者は、署名がないことや署名が検証できないことだけを根拠に、メッセージを拒否するべきではない (SHOULD NOT)。そのような拒否は、重大な相互運用性の問題を引き起こすだろう。しかし、もし検証者がこのようなメッセージを拒否することを敢えて選択するなら (たとえば、事前の合意に基づき、署名されたメッセージのみを送信することになっている相手からの通信の場合)、そして検証処理が SMTPセッションと同時進行で行われ、かつ署名がなかったりた検証が成功しない場合、 MTA は 550/5.7.x 応答コードを返すべきである (SHOULD)。

恐らく鍵サーバが利用できないことによるものだろうが、もし公開鍵が取得不可能な場合、以下のような 451/4.7.5 応答コードの一時的エラーメッセージを生成してもよい (MAY)。

451 4.7.5 Unable to verify signature - key server unavailable

鍵サーバや他の外部のサービスに接続不能といった一時的な障害こそが、 4xx SMTP 応答コードを使用すべき (SHOULD) 唯一の状況である。特に、署名検証の暗号部分での失敗では、4xx SMP 応答を返してはいけない (MUST NOT)。

一度署名の検証が成功したら、、その情報は、身元評価モジュール(明示的な許可/ホワイトリストまたはレピュテーションシステム)とエンドユーザのいずれかまたは両方に伝達されなければならない(MUST)。SDID が From: ヘッダーフィールド内のアドレスと同じでない場合、メールシステムは実際の SDID が読み手に明確に伝わるように、最大限の努力をするべきである (SHOULD)。

検証者は、署名されていないヘッダーフィールドを、極度な疑念をもって扱ってもよい (MAY)。それは、信用しないと印をつけたり、エンドユーザに表示する前に削除することさえも含む。

検証が失敗した際の症状は明白(つまり署名が検証されない)だが、正確な原因の特定は恐らくもっと難しい。セレクタ―が見つからなかった場合、セレクタ―が削除されていたのか?それとも転送中に何らかの形で値が変更されたのか?もし署名の行が欠落している場合、元からなかったからなのか? それとも、やり過ぎのフィルターが削除したのか? 診断目的のため、なぜ検証が失敗したかの正確な理由はポリシーモジュールから分かるようにすべきであり、できる限りシステムログに記録されるべきである (SHOULD)。 電子メールが検証できなかった場合、署名されているように見えるかどうかに関係なく、すべての検証されていない電子メールと同様に表示させるべきである (SHOULD)。

 IANAの考察

DKIMはIANAに新しい名前空間を登録している。 いかなる場合でも、新しい値はITEFの合意により公開されたRFC[RFC5226]で記載された値のみに割り当てられる。

7.1 DKIM-Signatureに関するタグ仕様

DKIM-Signatureはタグ仕様一覧を定めている。IANAはDKIM-Signatureフィールドで利用できるタグ仕様のためのタグ仕様レジストリを規定した。

レジストリの初期登録は以下から構成される。

表1:DKIM-Signatureのタグ仕様レジストリ初期値
TYPEREFERENCE
v(本文書)
a(本文書)
b(本文書)
bh(本文書)
c(本文書)
d(本文書)
h(本文書)
i(本文書)
l(本文書)
q(本文書)
s(本文書)
t(本文書)
x(本文書)
z(本文書)

7.2 DKIM-Signatureクエリー方式に関するレジストリー

"q="タグ仕様(3.5節参照)はクエリー方式一覧を定めている。

IANAは、DKIMを用いて署名されたメッセージの有効性確認処理をするキーを読み出す仕組みについての、DKIM-Signatureクエリー方式に関するレジストリを規定した。

レジストリの初期登録は以下から構成される。

表2:DKIM-Signatureクエリー方式に関するレジストリ初期値
TYPEOPTIONREFERENCE
dnstxt(本文書)

7.3 DKIM-Signature正規化に関するレジストリー

"c ="タグ仕様(3.5節参照)は、メッセージのヘッダーと本文の正規化アルゴリズムの指定方式を定めている。

IANAは、DKIMを用いて署名または検証する前にメッセージを正規化形式に変換する、DKIM-Signature正規化アルゴリズムに関するレジストリを規定した。

本文レジストリの初期登録は以下から構成される。

表3:DKIM-Signature本文正規化アルゴリズムに関するレジストリ初期値
TYPEREFERENCE
simple(本文書)
relaxed(本文書)

7.4 _domainkey DNS TXTレコードに関するタグ仕様

_domainkey DNS TXTレコードはタグ仕様一覧を定めている。IANAはDNS TXTレコードで利用可能なタグ仕様として、DKIM _domainkey DNS TXTタグ仕様レジストリを規定した。

レジストリの初期登録は以下から構成される。

表4:DKIM _domainkey DNS TXTレコードタグ仕様のレジストリ初期値
TYPEREFERENCE
v(本文書)
g(本文書)
h(本文書)
k(本文書)
n(本文書)
p(本文書)
s(本文書)
t(本文書)

本文レジストリの初期登録は以下から構成される。

表5:DKIM-Signatureボディ正規化アルゴリズムに関するレジストリ初期値
TYPEREFERENCE
simple(本文書)
relaxed(本文書)

7.5 DKIM鍵タイプに関するレジストリー

"k=" <key-k-tag> (3.6.1節参照) と "a=" <sig- a-tag-k> (3.5節参照) タグはDKIM署名復号に利用可能な機構一覧を定めている。

IANAはそのような機構のためのDKIM鍵タイプに関するレジストリを規定した。

レジストリの初期登録は以下から構成される。

表6:DKIM鍵タイプの初期値
TYPEREFERENCE
rsa[RFC3447]

7.6 DKIMハッシュアルゴリズムに関するレジストリー

"h=" <key-h-tag> (3.6.1節参照) と "a=" <sig-a-tag-h> (3.5節参照) タグはメッセージデータの要約生成に利用可能な機構一覧を定めている。

IANAはそのような機構のためのDKIMハッシュアルゴリズムに関するレジストリを規定した。

レジストリの初期登録は以下から構成される。

表7:DKIMハッシュアルゴリズムの初期値
TYPEREFERENCE
sha1[FIPS-180-2-2002]
sha256[FIPS-180-2-2002]

7.7 DKIMサービスタイプに関するレジストリー

"s=" <key-s-tag> (3.6.1節参照) タグはセレクターが適用してもよいサービスタイプの一覧を定めている。

IANAはサービスタイプのためにDKIMサービスタイプに関するレジストリを規定した。

レジストリの初期登録は以下から構成される。

表8:DKIMサービスタイプのレジストリ初期値
TYPEREFERENCE
email(本文書)
*(本文書)

7.8 DKIMセレクターフラグに関するレジストリー

"t=" <key-t-tag> (3.6.1節参照) タグはセレクターの解釈を変更するフラグの一覧を定めている。

IANAは追加フラグ用にDKIMセレクターフラグに関するレジストリを規定した。

レジストリの初期登録は以下から構成される。

表9:DKIMセレクターフラグに関するレジストリの初期値
TYPEreference
y(本文書)
s(本文書)

7.9 DKIM-Signatureヘッダーフィールド

IANAは参照として本文書が使われる"mail"プロトコルのための"Permanent Message Header Fields"レジストリ([RFC3864]参照)にDKIM-Signatureを追加した。

8. セキュリティに関する考察

今まで、スパムを根絶しようとするいかなる仕組みも、集中攻撃の対象となってきた。DKIMは、潜在的な攻撃の方向性とそれぞれに対する脆弱性を特定するために、慎重に吟味される必要がある。[RFC 4686]も参照のこと。

8.1 ボディ長制限の誤用("l ="タグ)

本文長制限("l="タグの形式による)は、潜在的にいくつかの攻撃の対象になる可能性がある。

8.1.1 マルチパートメッセージへの新しいMIMEパートの追加

もし、MIMEマルチパート部分全て(末尾を表す"--CRLF"を含む)が本文長制限に収まらない場合、攻撃者は適切に署名されたメッセージを奪い、新しい本文パートを挿入できてしまう。これにより、MIMEタイプの詳細、検証MTAや受信側のMUAの実装次第では、攻撃者はエンドユーザーに表示される情報を改ざんし、それを明らかに信頼できる送信元として見せることが可能となる。

例えば、もし攻撃者が"text/html"の本文部分に情報を追加できれば、"</html>"マーカーの後のデータを読み続けるといういくつかのMUAのバグを利用して、既存のテキストの上にHTMLテキストを表示させられるかもしれない。また、もしメッセージに"multipart/alternative"の本文パートがあれば、彼らは表示するMUAに合わせ、新しい本文パートを追加できるかもしれない。

8.1.2 既存コンテンツへの新しいHTMLコンテンツの追加

いくつかの受信側MUAの実装では、"</html>"タグでデータの表示を止めない場合がある。特に、これは既存テキストの上に画像を表示させるような攻撃を可能にする。

8.2 秘密鍵の漏洩

もしあるユーザーの秘密鍵がPC上にあって、適切なセキュリティシステムで守られていない場合、マルウェアによってそのユーザーまたは同じ秘密鍵を共有する他の誰かを詐称してメールを送ることが可能である。しかしそのマルウェアは、実際には他の署名者のアドレスで署名を詐称できるわけではないので、感染したユーザーの特定は容易であり、メールを使ったソーシャルエンジニアリングのような攻撃に使われる可能性も限られている。 この脅威は、主に MUA 実装に対するものであり; サーバに秘密鍵を置く場合には、専用の暗号化ハードウェアを使うことによって容易に保護できる。

もし、多くのユーザーのPCに感染したマルウェアが、そこで秘密鍵を集め、秘かに誰でもアクセスできるサイトに転送すれば、もっと大きな問題が発生する。 被害にあったユーザーは、送ったとされる先からバウンスメールが返って来るまで、鍵の漏洩に気づかない可能性が高い。多くのユーザーはバウンスメッセージの重大性を理解しないかもしれず、その場合は何の対策も取らないだろう。

一つの対策としては、ユーザー入力のパスワードにより、秘密鍵を暗号化することである。ユーザーは弱いパスワードを使ったり、しばしば同じパスワードを他の目的に使い回したりするので、DKIMへの攻撃を他のドメインへも波及させることになりかねないとしてもだ。それでも、復号された秘密鍵は入力時にわずかな時間、マルウェアの盗み見に晒されるかもしれないし、キーストロークのログを追えばわかってしまうかもしれない。メッセージを送信する度にパスワードを入力するという煩雑さが加わると、安全なパスワードを使う気をなくさせる傾向にある。

もう少し効果的な対策としては(例えばSMTP-Authのような)既存の技術を使い、送信者を認証する送信側MTAを使うことだ。それは(例えばヘッダーの有効性をチェックし、コンテンツフィルターでスパムチェックをするような)メッセージ認証も行った上で、その送信者用の鍵を使って署名をするという方法だ。そのようなMTAはまた、各ユーザー毎に送り出せる送信メールの量をコントロールすることにより、さらにマルウェアが大量に送る電子メールを制限できる。

8.3 鍵サーバへのDoS攻撃

鍵サーバーは(潜在的に各ドメイン毎に)分散しているので、このインターネット全体に及ぶ仕組みを破壊するためには、膨大な数のサーバーを攻撃しなければならない。 それでも、個々のドメインの鍵サーバーが攻撃の対象となり、そのドメインからのメッセージの検証が妨害される可能性がある。これは、攻撃者が、特定のドメインのメールサーバーへDoS攻撃を仕掛けられる、という状況とあまり変わらない。ただ、そちらは受信メールではなく、送信メールに影響するというだけだ。

もう一つの攻撃方法として、もしあるドメインの詐称アドレスを使い、大量のメールが送られれば、そのドメインの鍵サーバーはリクエストの嵐に見舞われ可能性がある。 しかし、電子メールメッセージ本体の処理に比べれば、検証の負荷は低く、そのような攻撃を仕掛けるのは難しいだろう。

8.4 DNSへの攻撃

DNSが鍵取得のサービスには必須のものなので、敢えてDNSを狙った攻撃について考えておく必要がある。

現状のDNSが安全ではない([RFC3833])ため、これらのセキュリティ上の問題がDNSセキュリティ(DNSSEC[RFC4033])を進める原動力となっている。そして、全てのDNSユーザーがその努力の恩恵を受けるだろう。

DKIMは、メールの真正性を証明するに必要十分な仕組みを意図しているに過ぎない。メール作成者の本人性やメールの中身そのものに関して、強力な暗号的保護をかけることは意図していない。 OpenPGP [RFC4880] や S/MIME [RFC5751] など、他の技術がそれらの要件を満たす。

DNSに関する2番目のセキュリティ問題は、署名ドメインポリシーの取得だけではなく、セレクターベースのデータ取得の増加に伴うDNSトラフィックの増加に関するものだ。 DKIMが広く普及すれば、署名を行ったとするドメインへのDNSクエリーが大幅に増加する。もし大規模な詐称が行われれば、DNSサーバへのクエリーは大量に発生するだろう。

DKIMの検証者が考慮すべきDNS特有のセキュリティ問題に、[RFC3833]の2.3節に記述されている名前連鎖攻撃がある。DKIM-Signature ヘッダーフィールドを検証する際、DKIMの署名検証は、攻撃者の指定する鍵レコードを取得させられる可能性がある。この脅威を最小化するには、再帰的な問い合わせをするネームサーバを含め、検証者が利用するネームサーバが、DNS応答に含まれるグルーレコード他の付加情報を厳しくチェックすることにより、この攻撃への脆弱性を克服することである。

8.5 リプレイ攻撃

この攻撃では、スパマーは送りたいスパムをまず自分の協力者に送り、その結果メッセージには送信元MTAの署名がつく。協力者はそのオリジナルの署名を含めたメッセージを、恐らくMTAとして機能する多くの踏み台マシンを使って大量の受信者に再送信する。 そのメッセージは、協力者によって変更されていないので、有効な署名を持つことになる。

この問題を部分的にでも解決するには、レピュテーションサービスを利用し、特定の電子メールアドレスがスパムに使われ、その署名者からのメッセージはスパムの可能性が高いという事実を通知することである。 これには、十分なスピードで対応するためのリアルタイム検出の仕組みが必要である。しかし、もし例えば、攻撃者が犠牲者からのメールを大量に再送信し、その犠牲者がスパマーかのように見せかけたとしたら、このような対策は返って悪用されるだけかもしれない。

大規模な検証者は、短時間に不自然に大量発生した同じ署名のメールを検出できるかもしれない小規模な検証者は、既存の協力システムを通じ、実質的に同じ量の情報を得ることができる

8.6 鍵失効の制限

大規模なドメインで、一部のユーザーの好ましくない振る舞いを検出した時、まだ検証されていないか、リプレイ攻撃の対象になったそのユーザーのメッセージへの責任を否定するために、そのユーザーのメッセージの署名に使った鍵を失効させたくなるかもしれない。しかし、もしスケーラビリティーなどの理由から、同じ鍵が他の多くのユーザーのメッセージを署名するのに使われていれば、そのドメインがそうできる余地は限られる可能性がある。明示的にアドレス単位で鍵を失効させる仕組みが提案されているが、その利便性とそれによって増すDNS負荷について、さらなる検討が必要である。

8.7 意図的に不正な形式の鍵レコード

攻撃者が堅牢でない検証者の実装にDoS攻撃をかけるため、意図的に不正なDNSの鍵レコードを発行する可能性がある。攻撃者は不正な鍵レコードを参照する(必ずしも有効でない)署名を含むメッセージを検証者のユーザーに送りつけることにより、検証者が不正な鍵レコードを読むよう仕向けることができる。検証者はDNSから取得した全ての鍵レコードを完全に検証しなければならず、意図的かそうでないかに関わらず、不正な鍵レコードに対する堅牢性を確保しなければならない(MUST)。

8.8 意図的に不正な形式の DKIM-Signature ヘッダーフィールド

検証者は不正な形式のDKIM-Signatureヘッダーフィールドを受け取ることにも備えなければならず、そのいかなる内容も、それを信頼する前に徹底的に検証しなければならない(MUST)。

8.9 情報漏洩

攻撃者は、メッセージごとのセレクターを使い、鍵参照のためのDNSトラフィックをモニターすることによって、特定の署名がいつ検証されたのかを特定することができる。 これはメッセージが読まれた時ではなく、検証された時を知らせる「Webビーコン」と同等の役割を果たす。

8.10 リモートタイミング攻撃

いくつかのケースで、リモートタイミング攻撃によって秘密鍵を抽出できる可能性が指摘されている[BONEH03] 。実装においては、このような攻撃を防ぐため、特定処理のタイミングをわかりにくくする措置を検討すべきである。

8.11 並べ替えられたヘッダーフィールド

RFCでは中継するMTAにヘッダーフィールドの並べ替えを許している。もし署名者が同じ名前を持つ二つ以上のヘッダーフィールドに署名している場合、本来は正当なメールが擬似的な検証エラーを起こす可能性がある。 特に、元々あったDKIM-Signatureヘッダーフィールドも含めて署名する署名者は、誤って検証に失敗するリスクを取ることになる。

8.12 RSA攻撃

攻撃者は、小さな指数で大きなRSA署名キーを生成することによって、検証キーが大きな指数を必要とするように仕向けることができる。これにより、検証者は、検証にかなりの計算リソースを使うことを強いられる。検証者は、理不尽な指数を持つ公開鍵のセレクターを参照していれば、その署名の検証を拒否することにより、この攻撃を避けることができるかもしれない。

一般的に、攻撃者は検証を要求するメッセージを大量に送りつけることで、処理を溢れさせようとするかもしれない。これはMTAに対するDoS攻撃に似ているので、それと同様に対処すべきである。

8.13 親ドメインによる不適切な署名

3.8節で説明した信頼関係を使えば、理論上、親ドメインがそのサブドメインに属する、管理上全く関係のない身元に対して署名することもできる。 例えば、".com"のレジストリは、"i="の値を使った署名により、example.comドメインのメッセージを作成することができる管理範囲の境界は、ドメイン上のどのレベルでも発生しうるので、この問題に対する一般的な解決策はない。例えば、"example.podunk.ca.us"ドメインには、3つの管理範囲の境界(podunk.ca.us、ca.us、us)があり、そのどれもがそのドメインを持つ身元のメッセージを作成できる。

8.14 追加ヘッダーフィールドを使った攻撃

多くの電子メール処理の実装では、[RFC5322]を厳密に実施していない。5.3 節で説明したように、DKIMの処理は、その対象が有効なメッセージであることを前提としている。 しかし、DKIMの実装者は、DKIMのモジュールとやりとりする電子メール処理部分の実装の甘さが及ぼす影響について理解すべきである。

例えば、複数のFrom:ヘッダーを持ったメッセージは、[RFC5322]の3.6節に違反している。ユーザーの満足度のために、多くのMTAはこれらの違反を容認し、とりあえずメッセージを配送している。そしてMUAは、最後または一番上にあるFrom:フィールドの値のユーザーに表示するかもしれない。これは、単にそれが一つしかないという前提の元でも行われる。そこでは「先に見つかったものを認識する」アルゴリズムが同じ結果をもたらしただろう。 そのようなMUAのコードは、別のFrom:フィールドが受信時のフィルターでチェックされたものであることが知れると、ユーザーを騙すことに悪用される可能性がある。同じことはDKIMでも起こり得る。From:フィールドは署名されなければならないが、不正な形式のメッセージに複数のFrom:フィールドがあり、最初の(一番下の)ものだけが署名されているかもしれない。その場合、"DKIM検証成功"をつけたメッセージを表示しようとする際、署名されていない方のFrom:フィールドが表示される可能性がある。 (このことがDKIMが作成者の本人確認のために設計されていないことを実証している。)

特にこの種類の攻撃に対抗しようとする署名者は、署名したフィールドのリストに、署名時にすでに存在する各フィールドの名前を加えることができる。例えば、From:フィールドが一つしかない正当なメッセージは"h=From:From:..."を使って署名することができる。ヘッダーフィールドがハッシュ関数へ渡される際の正規化の方法により、もし追加のヘッダーフィールドを署名後に加えれば、署名は無効と表示されるので、それを防ぐことができる。

9. 参考文献

9.1 引用規格 (Normative References)

[FIPS-180-2-2002]U.S. Department of Commerce, , “Secure Hash Standard”, FIPS PUB 180-2, August 2002.
[ITU-X660-1997]“Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”, 1997.
[RFC2045]Freed, N. and N.S. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.
[RFC2047]Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text”, RFC 2047, November 1996
[RFC2049]Freed, N. and N.S. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples”, RFC 2049, November 1996.
[RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC3447]Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1”, RFC 3447, February 2003.
[RFC3490]Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA)”, RFC 3490, March 2003.
[RFC4234]Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 4234, October 2005.
[RFC5321]Klensin, J., “Simple Mail Transfer Protocol”, RFC 5321, October 2008.
[RFC5322]Resnick, P., “Internet Message Format”, RFC 5322, October 2008.
[RFC5598]Crocker, D., “Internet Mail Architecture”, RFC 5598, July 2009.

9.2 その他参考文献 (Informative References)

[BONEH03]“Remote Timing Attacks are Practical”, Proceedings 12th USENIX Security Symposium, 2003.
[RFC1847]Galvin, J., Murphy, S., Crocker, S., and N. Freed, “Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted”, RFC 1847, October 1995.
[RFC3766]Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3833]Atkins, D. and R. Austein, “Threat Analysis of the Domain Name System (DNS)”, RFC 3833, August 2004.
[RFC3864]Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.
[RFC4033]Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, March 2005.
[RFC4409]Gellens, R. and J. Klensin, “Message Submission for Mail”, RFC 4409, April 2006.
[RFC4686]Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)”, RFC 4686, September 2006.
[RFC4870]Delany, M., “Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)”, RFC 4870, May 2007.
[RFC4871]Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures”, RFC 4871, May 2007.
[RFC4880]Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, “OpenPGP Message Format”, RFC 4880, November 2007.
[RFC5226]Narten, T. and H.T. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
[RFC5451]Kucherawy, M., “Message Header Field for Indicating Message Authentication Status”, RFC 5451, April 2009
[RFC5751]Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification”, RFC 5751, January 2010.

著者連絡先

D. Crocker (編者) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, USA 電話番号: +1.408.246.8253 メール: URI: http://bbiw.net
Tony Hansen (編者) AT&T Laboratories 200 Laurel Ave. South Middletown , NJ 07748 USA メール:
M. Kucherawy((編者) Cloudmark メール:

A. 使用例(参考)

この節では、どのように各構成要素が連携しているかを示しながら、電子メールの投稿から最終的な配送までの完全な流れを説明します。 この例で使用する鍵は付録Cで示します。

A.1 ユーザーによる電子メールの作成

From: Joe SixPack <joe@football.example.com>
To: Suzie Q<suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <;20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game.Are you hungry yet?

Joe.

図1: ユーザによる電子メールの作成

A.2 電子メールへの署名

このメールは、example.com ドメインの送信メールサーバーによって署名されます。 このとき、このメールは次のようになります。

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
     c=simple/simple; q=dns/txt; i=joe@football.example.com;
     h=Received : From : To : Subject : Date : Message-ID;
     bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
     b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
     4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
     KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 
     4bmp/YzhwvcubU4=; 
Received: from client1.football.example.com [192.0.2.1]
     by submitserver.example.com with SUBMISSION;
     Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 
From: Joe SixPack <joe@football.example.com> 
To: Suzie Q <suzie@shopping.example.net> 
Subject: Is dinner ready? 
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

図2:電子メールへの署名

署名する電子メールサーバーは、この署名を生成するための"brisbane"セレクターに関連付けられている秘密鍵にアクセスする必要があります。

A.3 電子メール署名の検証

署名は通常の場合、受信 SMTP サーバーまたは最終的な配送エージェントによって検証されます。しかし、配送を介する MTA でも、そうすることを選択すれば、この検証を行うことができます。検証プロセスは DKIM-Signature ヘッダーフィールドの d= タグから取り出したドメイン "example.com" と s= タグから取り出したセレクター "brisbane" を使って DNS の DKIM クエリーを組み立てます。このクエリーは brisbane._domainkey.example.com となります。

署名の検証は、"h=" タグに記載された順番に、物理的に最後の Received ヘッダーフィールドや From ヘッダーフィールドなどから始まります。検証はメッセージ本文("Hi." で始まる部分)に続く単一の CRLF まで続きます。 電子メールは "simple" メソッドで検証するために前もって正規化されます。DNS クエリーとそれに続く署名検証の結果は、(この例では)X-Authentication-Results ヘッダーフィールド行に保存されます。検証が成功した後、電子メールは次のようになります。

X-Authentication-Results: shopping.example.net
 header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1)
  by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
  c=simple/simple; q=dns/txt; i=joe@football.example.com;
  h=Received : From : To : Subject : Date : Message-ID;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
    4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
    KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
    4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
  by submitserver.example.com with SUBMISSION;
  Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.
We lost the game. Are you hungry yet?
Joe.

図3:成功した検証

B. 使用例(参考)

DKIM の署名と検証は、運用するシナリオにより別々の方法で利用する事ができます。この付録では、いくつかの一般的な例について議論します。

B.1 代替投稿シナリオ

最も単純なシナリオでは、あるユーザの MUA や MSA、インターネットの(境界)MTA は、同じドメイン名を利用しており、すべて同一の管理者が管理しています。 このため、投稿と最初の転送に関与するすべてのコンポーネントは関連しています。 しかしながら、2つ以上のコンポーネントが異なる管理者の下で管理されているのが一般的です。この場合、署名に使用するドメイン名と、一般的な電子メールのアイデンティティヘッダーフィールドとの関連付けに使用するドメイン名の選択と管理に対する課題が発生します。

B.1.1 委譲された業務機能

いくつかの組織では特定の業務機能を組織内または組織外の別々のグループに割り当てています。 しががって、そのグループにいくつかのメールに署名する権限を与えるますが、彼らが生成できる署名の種類に制約をつけることをゴールとします。 DKIM のセレクター("s=" 署名タグ)と粒度("g=" 鍵タグ)は、こういった制限を容易にします。これらのアウトソーシングビジネスの例は、合法的なメールマーケティングプロバイダーやコーポレートベネフィットプロバイダーが当てはまります。

ここでは、委譲されたグループが、クライアント企業のメールのドメインを使って、署名されたメッセージを送信できるようにする必要があります。 しかし、同時に、クライアント企業は自社のドメイン名を使ったメールを勝手に送信されることを心配し、プロバイダのために鍵を登録することに消極的であることもよくあります。

これらのシナリオを管理するには、いくつかの方法があります。 あるケースでは、クライアント組織が(DNSのような)公開されたクエリーサービスの管理をすべて行っています。別のケースでは、クライアント組織が DNS の権限委譲をして、権限委譲したグループによる DKIM の鍵レコードの管理すべてをできるようにしています。

もしクライアントの組織が DNS 管理の全ての責任を保持するなら、アウトソーシング企業は鍵ペアを作成して公開鍵をクライアント企業へ提供することができます。このときクライアント企業は特定の From ヘッダーフィールドのローカルパートを認証する一意のセレクターを使用して、この公開鍵をクエリーサービスへ登録します。 例えば、"example.com" ドメインを持つクライアントは、From アドレスが "winter-promotions@example.com" となっていた場合にのみ利用できる "g=winter-promotions" というセレクターレコードを使えます。 これにより、プロバイダーがある特定のアドレスを利用したメールメッセージを送信できるようになり、それらのメッセージは適切に検証されます。 クライアント企業は、鍵をいつでも破棄する事ができるため、メールアドレスについての管理権限を保持し続けることができます。

もし、クライアントが DNS 管理を委譲したければ、セレクターを指定されたドメイン名がプロバイダーの DNS サーバを指すようにします。 そして、プロバイダーはこのセレクターに対する DKIM 署名情報すべてを作成しメンテナンスします。 したがって、クライアントは署名されるメールアドレスのローカルパートに制約をつけることができません。しかし、DNS の委譲レコードを削除することにより、プロバイダーの署名権限を無効にすることができます。

B.1.2 PDA および類似のデバイス

PDA はドメインごとに複数の鍵を使う必要性を示しています。John Doe は jdoe@example.com という会社のメールアドレスを使ってメッセージを送れるようにしたいとします。また、デバイスの制限やインターネットアクセスプロバイダの強制的な制限により、彼のメール用デバイスは 仮想プライベートネットワーク (VPN) で会社のネットワークに接続する機能はありません。デバイスが example.com の管理者により jdoe@example.com を登録された秘密鍵とメッセージに署名するのに適切なソフトウェアを備えていれば、John はアクセスサービスプロバイダの外向きネットワークを通して送信する前に、デバイス上でメッセージに署名することができます。

B.1.3 ローミングユーザー

ローミングユーザーはよくホームサーバ以外の SMTP サーバーを使用するのが便利であったり、必要な状況になります。 例えば、カンファレンスや多くのホテルなどです。このような状況では、送信サービスにより付加される署名はユーザーのホームシステムで使われる識別情報とは異なります。

理想的には、ローミングユーザーは VPN や ポート 587 での SMTP 認証を用いた SUBMISSION サーバーを使用してホームサーバーに接続するでしょう。ローミングユーザーのラップトップで署名が実行できれば、さらなる変更のリスクは高いものの、送信前に署名することができます。どちらも不可能な場合、ローミングユーザーは自身のドメインの鍵を使用して署名されたメールを送ることはできないでしょう。

B.1.4 単独でのメッセージ送信

外にあるキオスクやウェブベースの情報サービスのようなスタンドアローンサービスは、ユーザーと継続的な 電子メールサービスの関係はないですが、ユーザーは時折、彼らに代わってメールを送るよう要求します。例えば、ニュースサイトではよく、読者が記事のコピーを友人に転送する事ができます。これは誰が送信者であるかを示すために、読者が自身の電子メールアドレスを使う典型的な例です。これは時々「Evite 問題」と呼ばれます。ユーザーが友人を招待を送信する事ができる同名のウェブサイトの名前にちなんでつけられました。

この問題を処理する一般的な方法は、メッセージの From ヘッダーフィールドに読者の 電子メールアドレスを入れるものの、Sender ヘッダーフィールドに 電子メールを送るサイト自身のアドレスを入れるままにするものです。電子メールを送信するサイトは Sender ヘッダーフィールドのドメインを使用して、メッセージに署名することができます。これにより、電子メールを受信するサイトに有用な情報が提供されます。この情報で署名するドメインと電子メールを最初に送信する役割を相互に関連づけることができます。

受信サイトは、多くの場合、この方法を介したメールに関する情報をエンドユーザーに提供したいと望みます。異なるアプローチの実際の効果は人間工学におけるユーザビリティ研究のテーマですが、使用された1つのテクニックは、アドレスが検証されたことを示すために、検証システムが From ヘッダーフィールドを書き換えるものです。 例: From: John Doe via news@news-site.com <jdoe@example.com>(このような書き換えは検証パスが完了した後に行われるのでない限り、署名を破壊することに注意)

B.2 代替配信シナリオ

電子メールはよく、最初の送信中で使われたものと異なるアドレスのメールボックスに届くことがあります。これらのケースでは、元々使用されているアドレスの箇所で中継メカニズムが動作し、最終的な宛先にメッセージを渡します。この中継プロセスには DKIM 署名に関する課題がいくつかあります。

B.2.1 アフィニティアドレス

「アフィニティアドレス」は、ユーザーが別の電子メールプロバイダに移ったとしても安定的に利用しつづけられる電子メールアドレスです。それらは通常、長期的に関係を持つことを期待している、大学の同窓会や専門機関、レクリエーション組織に結びついています。それらの組織は通常、受信メールの転送機能を提供し、また多くはユーザーを認証し、転送先アドレスを変更することができるWebアプリケーションを用意しています。しかし、これらのサービスは、通常、各々のサービスプロバイダーのMTAを介してメッセージを送信するユーザーに依存しています。したがって、アフィニティアドレスのドメインで署名されているメールは、そのドメインを所有している組織によって管理される要素によって署名されていません。

DKIMでは、そのような組織が Web アプリケーションを使用して、アフィニティアドレスの代わりにメッセージに署名するために使用するユーザー毎の鍵をユーザーに登録させることができます。 ユーザは署名のための秘密鍵を保持し、その組織は検証者のアクセスのために公開鍵をDNSで公開することになります。

これはユーザーレベルの鍵を駆使する別の応用です。アフィニティアドレスに使われるドメインは、通常は非常に大量のユーザレベルの鍵を持つでしょう。 別の方法として、そのような組織はメッセージに署名する前にユーザを認証するメール送信エージェントを動作させることでも発信メールを処理できます。 当然ながらこれは、ユーザーのサービスプロバイダが、メール送信に関連するTCPポートをブロックしていないことに依存しています。

B.2.2 単純なアドレスのエイリアス(.forward)

いくつかのケースでは、Unix の .forward ファイルを使用する等で、元の電子メールアドレスから別の電子メールアドレスへ自動的に転送させる設定が許されている場合があります。この場合、Receivedヘッダーフィールドのメッセージへの追加とエンベロープ受信者アドレスの変更をのぞいて、メッセージは通常は変更なしに受信者のドメインのメール処理サービスによって転送されます。 この場合においては、署名されたコンテンツが変更されていないので、最終的なアドレスのメールボックスの受信者が元の署名を確認することができ、DKIMはメッセージの署名を検証することができます。

B.2.3 メーリングリストと再送信

メッセージを受け取り、再送信するサービスにはさまざまな振る舞いが存在します。主な例としては、メーリングリスト(以下「フォワーダー」と総称する)があります。その振る舞いには Received ヘッダーフィールドの追加とエンベロープ情報の変更以外にメッセージ自体に何も変更しないものから、ヘッダーフィールドを追加したり、 Subject ヘッダーフィールドを変更したり、本文に内容を(典型的には末尾に)追加したり、何らかの方法で本文を書式を変更するものまで、多岐にわたります。単純なものは非常に自動化された別名サービスに類似しているメッセージを生成します。より複雑なシステムは本質的に新しいメッセージを作成します。

メッセージの本文や署名されたヘッダーフィールドを変更しないフォワーダーは、既存の署名の正当性を保つことができそうです。また、メッセージに独自の署名を付与することもできます。

既存の署名が無効になるようなメッセージの変更を行うフォワーダーには、独自の署名(例えば、mailing-list-name@example.net)を追加するのは特によい方法です。 (再)署名することはメッセージの内容に責任を持つことになるため、このような署名するフォワーダーは選択的になることが多く、受信したメッセージに有効な署名があるか、メッセージが偽造されてないとわかる他のなんらかの根拠がある場合にのみメッセージを転送もしくは再署名します。

主にメールの再配信に利用されるシステムにおいて一般的には、メッセージの署名に使用されているアドレスを識別するために、メッセージに Sender ヘッダーフィールドを追加します。この方法では、既存の Sender ヘッダーフィールドを削除することが[RFC5322]で要求されています。フォワーダーは、署名・公開鍵・およびフォワーダーの関連情報を含む新しい DKIM-Signature ヘッダフィールドを適用します。

C. 公開鍵の生成(参考)

デフォルトの署名は、電子メール全体の SHA256 ダイジェストに RSA 署名したものです。説明を簡単にするために、openssl コマンドを使用して、鍵と署名が管理されるメカニズムを解説します。 DKIM に適した、暗号化されていない 1024 ビットの秘密鍵を生成する方法の 1つとして、以下のような openssl コマンドを使用します:

$ openssl genrsa -out rsa.private 1024

セキュリティ強化のため、 "-passin" パラメータを追加して秘密鍵を暗号化することもできます。このパラメータを使う場合は、以下のステップの何箇所かでパスワードを入力する必要があります。サーバーよっては、ハードウェアの暗号化サポート機能を使用しているかもしれません。

"genrsa" ステップは次のような鍵情報を含む rsa.private ファイルを生成します:

-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb 
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB 
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX 
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ 
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO 
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ 
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA 
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf 
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX 
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= 
-----END RSA PRIVATE KEY-----

秘密鍵から公開鍵部分を抽出するには、次のように openssl コマンドを使用します:

$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

次のような鍵情報を含む rsa.public ファイルを生成します:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R 
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI 
MmPSPDdQPNUYckcQ2QIDAQAB 
-----END PUBLIC KEY-----

この公開鍵データ(BEGIN と END タグなし)を DNS に配置します:

brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" 
       "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" 
       "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" 
       "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" 
       "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB

D. MUA に関する考察

DKIM 署名が検証される場合、検証システムは受信者の MUA が利用できる結果を提供することがあります。どのようにしてこの情報をユーザー自身に役立つ形で提示するかは、人間工学におけるユーザビリティ研究の課題です。傾向としては、そのメッセージに対する責任を主張するアイデンティティ(身元主体)をユーザに示そうとして MUA に SDID を強調表示させることが多いです。 MUA は画像などの視覚的な合図でこれを実現するかもしれませんし、代替のビューにそのアドレスを含めるかもしれません。また、元の From アドレスを検証された情報で書換えることさえするかもしれません。 いくつかの MUA では、どのヘッダーフィールドが正当な DKIM 署名で保護されているかを示すかもしれません。 これは、署名されたヘッダーフィールドを肯定的に示したり、署名されてないヘッダーフィールドを否定的に示したり、署名されていないヘッダーを見えないよう隠したり、またこれらのいくつかを組み合わせることで、実現することもできます。MUA が署名されたヘッダーフィールドに対するビジュアルな表示を使用する場合、 MUA はエンドユーザーによって署名されたと解釈されるかもしれない方法で署名されていないヘッダーフィールドを表示しないように注意を払う必要がたぶんあるでしょう。メッセージに l= タグがあり、その値がメッセージの末尾に達しない場合、MUA は本文のうち署名されていない部分を隠すかマークするかもしれません。

上記の情報は網羅しようとしたものではありません。 MUA は反転表示や強調表示、非表示を選ぶかもしれませんし、さもなければ MUA の作者の意見ではエンドユーザーにとって重要であるとみなされる他の情報を表示するかもしれません。

E. 謝辞

以前の IETF 版の DKIM [RFC4871] は以下の人々によって書かれた:Eric Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton および Michael Thomas。

この仕様書は広範な共同努力の成果である。参加者は以下の通り:Russ Allbery, Edwin Aoki, Claus Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, および Dan Wing。

以前の DomainKeys は、DKIM が生まれる主な母体となった。DomainKeys に関する詳細な情報は [RFC4870] を参照のこと。

F. RFC4871bis の変更内容

F.1 作業予定

F.2 作業完了