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

3.6 Key Management and Representation (鍵管理と表現)

3.6. Key Management and Representation (鍵管理と表現)​

署名アプリケーションは, 検証公開鍵が主張された Signer に関連付けられているという何らかの保証レベルを必要とします。多くのアプリケーションは, 信頼できる第三者が発行した公開鍵証明書を使用することでこれを実現します。しかし, DKIM は, Verifier が主張された Signer の DNS エントリ (またはセキュリティ同等物) をクエリして公開鍵を取得するだけで, 十分なセキュリティレベルを達成でき, スケーラビリティを大幅に向上させることができます。

DKIM 鍵は複数のタイプの鍵サーバーに複数の形式で保存される可能性があります。鍵のストレージと形式は DKIM アルゴリズムの残りの部分とは無関係です。

鍵ルックアップアルゴリズムのパラメータには, ルックアップのタイプ ("q=" タグ), Signer のドメイン (DKIM-Signature ヘッダーフィールドの "d=" タグ), およびセレクタ ("s=" タグ) が含まれます。

public_key = dkim_find_key(q_val, d_val, s_val)

この文書は DNS TXT RR を使用して鍵を配布する単一のバインディングを定義します。将来, 他のバインディングが定義される可能性があります。

3.6.1. Textual Representation (テキスト表現)​

多くの鍵サーバーが非構造化テキスト形式で鍵を提示することが予想されます (例えば, XML 形式はこの目的の非構造化テキストとは見なされません)。非構造化テキスト形式で表現される任意の DKIM 鍵には次の定義を使用する必要があります。

全体的な構文は Section 3.2 で説明されている tag-list です。現在有効なタグは以下に説明されています。他のタグが存在する可能性があり, それらを理解しない実装はそれらを無視する必要があります。

v= DKIM 鍵レコードのバージョン (プレーンテキスト; 推奨, デフォルトは "DKIM1")。指定された場合, このタグは "DKIM1" (引用符なし) に設定する必要があります。このタグはレコードの最初のタグでなければなりません。他の値で始まる "v=" タグを持つレコードは破棄する必要があります。検証者はこの値に対して文字列比較を行う必要があることに注意してください; 例えば, "DKIM1" は "DKIM1.0" とは異なります。

ABNF:

key-v-tag    = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31

h= 許容されるハッシュアルゴリズム (プレーンテキスト; オプション, デフォルトはすべてのアルゴリズムを許可)。使用される可能性のあるハッシュアルゴリズムのコロン区切りリスト。認識されないアルゴリズムは無視する必要があります。Signer と Verifier が実装するハッシュアルゴリズムの説明については Section 3.3 を参照してください。各レコードのこのタグにリストされるアルゴリズムのセットは Signer が行う運用上の選択です。

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                  *( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   ; 将来の拡張用

k= 鍵タイプ (プレーンテキスト; オプション, デフォルトは "rsa")。Signer と Verifier は "rsa" 鍵タイプをサポートする必要があります。"rsa" 鍵タイプは "p=" タグで ASN.1 DER エンコードされた [ITU-X660-1997] RSAPublicKey ([RFC3447], Sections 3.1 および A.1.1 を参照) が使用されていることを示します。(注: "p=" タグは base64 アルゴリズムを使用して値をさらにエンコードします。) 認識されない鍵タイプは無視する必要があります。

ABNF:

key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; 将来の拡張用

n= 人間にとって興味深い可能性のあるメモ (qp-section; オプション, デフォルトは空)。プログラムによる解釈は行われません。スペース制限のある鍵サーバーメカニズム (特に DNS) では, このタグは控えめに使用する必要があります。これは管理者用であり, エンドユーザー用ではありません。

ABNF:

key-n-tag    = %x6e [FWS] "=" [FWS] qp-section

p= 公開鍵データ (base64; 必須)。空の値はこの公開鍵が失効したことを意味します。base64 エンコード前のこのタグ値の構文とセマンティクスは "k=" タグで定義されます。

情報提供の理由: 秘密鍵が侵害されたか, その他の方法で無効化された場合 (例: アウトソーシング契約が終了した場合), Signer はセレクタについて知っていることを明示的に宣言したいが, そのセレクタを使用するすべてのメッセージは検証に失敗する必要があることを示したい場合があります。Verifier は失効した鍵を参照するセレクタを持つ DKIM-Signature ヘッダーフィールドに対してエラーコードを返す必要があります。(詳細は Section 6.1.2 を参照してください。)

ABNF:

key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]

情報提供のメモ: base64string は任意の場所に空白 (FWS) を含めることができます; ただし, CRLF の後には少なくとも 1 つの WSP 文字が続く必要があります。実装者と管理者はセレクタ TXT RR がこの仕様に準拠していることを確認するよう注意する必要があります。

s= サービスタイプ (プレーンテキスト; オプション; デフォルトは "*")。このレコードが適用されるサービスタイプのコロン区切りリスト。特定のサービスタイプの Verifier は, 適切なタイプがリストされていない場合, このレコードを無視する必要があります。認識されないサービスタイプは無視する必要があります。現在定義されているサービスタイプは次のとおりです:

  • * すべてのサービスタイプに一致
  • email 電子メール (必ずしも SMTP に限定されない)

このタグは, 将来 DKIM が他のサービスによって定義される場合に, 他の目的での鍵の使用を制限することを目的としています。

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                   *( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type   = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   ; 将来の拡張用

t= フラグ, 名前のコロン区切りリストとして表されます (プレーンテキスト; オプション, デフォルトはフラグが設定されていない)。認識されないフラグは無視する必要があります。定義されたフラグは次のとおりです:

  • y このドメインは DKIM をテストしています。Verifier は, 署名の検証に失敗した場合でも, テストモードの Signer からのメッセージを未署名の電子メールと異なる方法で扱ってはなりません。Verifier は Signer を支援するためにテストモードの結果を追跡することを希望する場合があります。

  • s "i=" タグを使用する任意の DKIM-Signature ヘッダーフィールドは, "i=" タグの "@" の右側と "d=" タグの値に同じドメイン値を持つ必要があります。つまり, "i=" ドメインは "d=" のサブドメインであってはなりません。サブドメイン化が必要でない限り, このフラグの使用が推奨されます。

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS] key-t-tag-flag
                   *( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   ; 将来の拡張用

3.6.2. DNS Binding (DNS バインディング)​

鍵サービスとして DNS TXT RR を使用するバインディングがここに定義されます。すべての実装はこのバインディングをサポートする必要があります。

3.6.2.1. Namespace (名前空間)​

すべての DKIM 鍵は "_domainkey" という名前のサブドメインに保存されます。"d=" タグが "example.com", "s=" タグが "foo.bar" の DKIM-Signature フィールドが与えられた場合, DNS クエリは "foo.bar._domainkey.example.com" に対して行われます。

3.6.2.2. Resource Record Types for Key Storage (鍵ストレージ用のリソースレコードタイプ)​

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

TXT RR 内の文字列は, 使用前に中間の空白なしで連結する必要があります。TXT RR は特定のセレクタ名に対して一意でなければなりません; つまり, RRset に複数のレコードがある場合, 結果は未定義です。

TXT RR は Section 3.6.1 で説明されているようにエンコードされます。

に最終更新