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

3. Protocol Elements (プロトコル要素)

3. Protocol Elements (プロトコル要素)​

DKIM の操作には Signer (署名者) と Verifier (検証者) の 2 つの役割が関与します。Signer はメッセージが ADMD を離れるときに DKIM-Signature ヘッダーフィールドを作成し, Verifier はメッセージが到着したときにそれを検証します。Signer と Verifier は MTA, MSA, または MUA である可能性がありますが, それらのいずれかによって呼び出されるモジュールである可能性が高いです。

3.1. Selectors (セレクタ)​

1 つの SDID の下で複数の同時公開鍵をサポートし, 鍵管理の利便性を高めるために, DKIM は "selector" メカニズムを使用します。DNS ドメイン名でラベルが使用されるのと同様に, selector はクエリ文字列に挿入されます。

例えば, example.com の管理者が 2 つの並行 DKIM システムをインストールしたとします。彼らは 2 つのシステムのドメイン名として "marketing.example.com" と "engineering.example.com" を使用することを選択するかもしれません。しかし, このようなスキームには深刻な運用上の問題があります: 2 つのシステムのドメイン名とその名前で使用されるドメイン名との間で技術的な関連付けを確立および維持する必要があります。対照的に, より単純なスキームは, 主張されたアイデンティティのソースとして単一のドメイン名 "example.com" を使用し, 2 つのシステムからの公開鍵を区別することです。

この目的のために, selector メカニズムが導入されました。最も単純な使用法は, それぞれ異なる selector を使用する異なる鍵レコードを持つことです。2 つの異なるドメイン名を持つ代わりに, 部門を区別するために 2 つの異なる selector "nyc" と "sf" を使用します。この場合, 2 つの鍵レコードはそれぞれ "nyc._domainkey.example.com" と "sf._domainkey.example.com" で参照されます。

複数の selector により, 単一のドメインが複数の DKIM 鍵を保持でき, 複数の同時鍵ペアを実現できます。Verifier は特定のドメインが使用する selector の数を気にしません; DKIM アーキテクチャは鍵識別が一意であることを保証します。ユーザーが複数の selector を使用できる方法の例には, 個別の MSA および MTA 鍵の維持, ユーザーごとの鍵, アップグレード前後の鍵 (鍵の重複), サードパーティ署名のサポートなどがあります。すべての場合において, selector はランダムな文字列であり, 操作とは無関係であるため, それらについて推測することはできません。鍵レコードは鍵管理目的で人間が読めるコメント (n= タグ) を提供する場合があります。

3.2. Tag=Value Lists (タグ=値リスト)​

DKIM は, 署名や鍵レコードなどのさまざまな構造を表現するために, シンプルな "tag=value" 構文を使用します。各 tag-spec は, タグ名の後に "=" と値が続きます。複数の tag-spec はセミコロンで区切られます。タグ名と値の構文は [RFC2822] の ABNF に従い, 具体的な構文は後続のセクションで定義されます。

tag-list  =  tag-spec *( ";" tag-spec ) [ ";" ]
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
              ; 先頭と末尾の WSP と FWS を禁止
tval      =  1*VALCHAR
VALCHAR   =  %x21-3A / %x3C-7E
              ; EXCLAMATION から TILDE まで SEMICOLON を除く
ALNUMPUNC =  ALPHA / DIGIT / "_"

3.3. Signing and Verification Algorithms (署名と検証アルゴリズム)​

DKIM は複数のデジタル署名アルゴリズムをサポートします。2 つのクラスのアルゴリズムがサポートされています: (1) 相互運用性を保証するためにサポートする必要がある必須アルゴリズム; (2) 必要に応じて新しいアルゴリズムを実装できるようにするオプションのアルゴリズム。

Signer は使用するアルゴリズムを選択します。Verifier は必須アルゴリズムを使用した署名を検証できなければなりません。

署名アルゴリズムは DKIM-Signature ヘッダーフィールドの "a=" タグで定義され, その構文は次のとおりです:

sig-a-tag-alg   = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k     = "rsa" / x-sig-a-tag-k
sig-a-tag-h     = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k   = ALPHA *(ALPHA / DIGIT)
                  ; 将来の拡張用
x-sig-a-tag-h   = ALPHA *(ALPHA / DIGIT)
                  ; 将来の拡張用

"rsa-sha1" と "rsa-sha256" はサポートおよび実装する必要があります。他のアルゴリズムの仕様は今後の定義に委ねられます。

3.4. Canonicalization (正規化)​

一部のインターネットメール転送システムはメッセージを変更します。例えば, ヘッダー行の再フォーマットや先頭または末尾の空白の追加/削除などです。このような変更により署名検証が失敗する可能性があります。

この問題を解決するために, DKIM はメッセージを正規化するための 2 つの正規化アルゴリズムを定義します: "simple" と "relaxed"。"simple" はほとんどまたはまったく変更を許可しません; "relaxed" は空白の再フォーマットなどの一般的な変更を許可します。Signer は使用するアルゴリズムを選択できます。2 つのアルゴリズムはヘッダーと本文にそれぞれ適用されます。

正規化アルゴリズムは DKIM-Signature ヘッダーフィールドの "c=" タグで指定され, 構文は次のとおりです:

sig-c-tag       = "simple" / "relaxed" /
                  (sig-c-tag-h "/" sig-c-tag-b)
sig-c-tag-h     = "simple" / "relaxed" / x-sig-c-tag
sig-c-tag-b     = "simple" / "relaxed" / x-sig-c-tag
x-sig-c-tag     = hyphenated-word  ; 将来の拡張用

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

"simple" ヘッダー正規化アルゴリズムは, 検証に影響を与える方法でヘッダーフィールドを変更しません。

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

"relaxed" ヘッダー正規化アルゴリズムは次の手順を順番に適用する必要があります:

  • すべてのヘッダーフィールド名 (コロンの前を含む) を小文字に変換します。例えば, "SUBJect: AbC" を "subject: AbC" に変換します。
  • コロンの後のすべての WSP 文字を削除します。
  • すべての連続する WSP 文字シーケンスを単一の SP 文字に変換します。WSP 文字は [RFC5234] の Appendix B.1 で定義されている SP および HTAB 文字です。
  • フィールド値の末尾のすべての WSP を削除します。
  • 本文境界に追加する必要のない行末の CRLF シーケンスを削除します。

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

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

  • メッセージ本文の末尾のすべての空行を無視します。空行は CRLF のみを含む行として定義されます; 他の WSP 文字は単独で行に表示できません。本文が完全に空の場合, 末尾の空行が削除された単一の CRLF の正規化バージョンが使用されます。

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

"relaxed" 本文正規化アルゴリズムは次の手順を適用する必要があります:

  • すべての連続する WSP 文字シーケンス (CRLF の後のものを含む) を単一の SP に減らします。
  • メッセージ本文で行末に WSP 文字が現れるすべての行を無視します。実装は最後の非 WSP 文字の後の CRLF を削除してはなりません。
  • メッセージ本文の末尾のすべての空行を無視します。

3.4.5. Canonicalization Examples (正規化の例)​

次の例はヘッダーと本文の正規化を示しています。ここでは "<SP>" はスペース文字, "<HTAB>" は水平タブ, "<CRLF>" はキャリッジリターン/ラインフィードのペアを表します。

元のメッセージ:

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

simple 正規化後のメッセージ:

ヘッダー:

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

本文:

\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

relaxed 正規化後のメッセージ:

ヘッダー:

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

本文:

\<SP\>C\<CRLF\>
D\<CRLF\>
に最終更新