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

1. Introduction (序論)

DomainKeys Identified Mail (DKIM) は、個人、役割、または組織が、使用を許可されたドメイン名 [RFC1034] をメッセージ [RFC5322] に関連付けることにより、メッセージに対する一定の責任を主張することを可能にします。これは、著者の組織、運用リレー、またはそれらの代理人のいずれかである可能性があります。責任の主張は、暗号署名を通じて検証され、適切な公開鍵を取得するために署名者のドメインに直接クエリを実行することによって検証されます。著者から受信者へのメッセージ転送は、通常、メッセージコンテンツに実質的な変更を加えないリレーを介して行われるため、DKIM 署名が保持されます。メッセージには、メッセージに関与する同じ組織または異なる組織からの複数の署名を含めることができます。

DKIM が採用するアプローチは、以前のメッセージ署名アプローチ (例: Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751]、OpenPGP [RFC4880]) とは以下の点で異なります。

  • メッセージ署名はメッセージヘッダーフィールドとして記述されるため、人間の受信者や既存の MUA (Mail User Agent) ソフトウェアが、メッセージ本文に表示される署名関連のコンテンツに混乱することはありません。

  • 公開鍵と秘密鍵のペアが、よく知られた信頼できる証明書機関によって発行されることへの依存性がありません。

  • 公開鍵の配布または失効のための新しいインターネットプロトコルまたはサービスの展開への依存性がありません。

  • 署名検証の失敗は、メッセージの拒否を強制しません。

  • メカニズムの一部として暗号化を含める試みは行われません。

  • メッセージのアーカイブは設計目標ではありません。

DKIM:

  • 既存の電子メールインフラストラクチャと互換性があり、可能な限り透過的です。

  • 最小限の新しいインフラストラクチャを必要とします。

  • 展開時間を短縮するために、クライアントとは独立して実装できます。

  • 段階的に展開できます。

  • サードパーティへの署名の委任を許可します。

1.1. DKIM Architecture Documents (DKIM アーキテクチャ文書)​

読者は、[RFC4686]、[RFC5585]、および [RFC5863] の資料に精通することをお勧めします。これらは、DKIM の開発の背景、サービスの概要、および展開と運用のガイダンスとアドバイスをそれぞれ提供します。

1.2. Signing Identity (署名アイデンティティ)​

DKIM は、メッセージの署名者のアイデンティティの問題を、メッセージの主張された著者の問題から分離します。特に、署名には署名者のアイデンティティが含まれます。検証者は、署名情報を使用して、メッセージの処理方法を決定できます。署名アイデンティティは、署名ヘッダーフィールドの一部として含まれます。

参考理由: DKIM 署名によって指定された署名アイデンティティは、MUA を含む受信者メールシステムによる解釈の幅広い方法があるため、特定のヘッダーフィールド内のアドレスと一致する必要はありません。

1.3. Scalability (スケーラビリティ)​

DKIM は、電子メール識別問題を特徴付ける極端なスケーラビリティ要件をサポートするように設計されています。数百万のドメインと、それよりはるかに多数の個別アドレスが存在します。DKIM は、紹介なしに誰もが誰とでも通信できる能力など、現在の電子メールインフラストラクチャの肯定的な側面を維持しようとしています。

1.4. Simple Key Management (シンプルな鍵管理)​

DKIM は、証明書機関インフラストラクチャが不要であるという点で、従来の階層的公開鍵システムとは異なります。検証者は、サードパーティからではなく、主張された署名者のドメイン内のリポジトリから公開鍵を直接要求します。

DNS は、公開鍵の初期メカニズムとして提案されています。したがって、DKIM は現在、DNS 管理と DNS システムのセキュリティに依存しています。DKIM は、利用可能になった他の鍵取得サービスに拡張できるように設計されています。

1.5. Data Integrity (データ整合性)​

DKIM 署名は、異なるメッセージでの署名の再利用を防ぐために、"d=" 名をメッセージの一部またはすべての計算されたハッシュと関連付けます (セクション 3.7 を参照)。署名を検証することは、ハッシュされたコンテンツが署名されてから変更されていないことを主張し、メッセージのエンドツーエンドの整合性を「保護する」ことについては何も主張しません。

に最終更新