[要約] RFC 4870は、DNSで公開された公開鍵を使用したドメインベースのメール認証（DomainKeys）に関する規格です。このRFCの目的は、メールの送信者のドメインの信頼性を確保し、スパムやフィッシングなどの不正なメール送信を防止することです。
Network Working Group M. Delany
Request for Comments: 4870 Yahoo! Inc
Obsoleted By: 4871 May 2007
Category: Historic
Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
DNS（ドメインキー）で宣伝されているパブリックキーを使用したドメインベースの電子メール認証
Status of This Memo
本文書の位置付け
This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティ向けの歴史的な文書を定義しています。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.
「DomainKeys」は、公開キーテクノロジーとDNSを使用して電子メールの起源と内容を証明することにより、電子メールのドメインレベルの認証フレームワークを作成します。
This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.
このドキュメントでは、ドメインごとに電子メールに署名するためのフレームワークを定義します。このフレームワークの究極の目標は、今日知られているように、インターネットメールのセマンティクスを保持しながら、アイデンティティを明確に証明および保護することです。
Proof and protection of email identity may assist in the global control of "spam" and "phishing".
電子メールIDの証明と保護は、「スパム」と「フィッシング」のグローバルな制御を支援する可能性があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Lack of Authentication Is Damaging Internet Email ..........3
1.2. Digitally Signing Email Creates Credible Domain
Authentication .............................................4
1.3. Public Keys in the DNS .....................................4
1.4. Initial Deployment Is Likely at the Border MTA .............5
1.5. Conveying Verification Results to MUAs .....................5
1.6. Technical Minutiae Are Not Completely Covered ..............5
1.7. Motivation .................................................6
1.8. Benefits of DomainKeys .....................................6
1.9. Definitions ................................................7
1.10. Requirements Notation .....................................8
2. DomainKeys Overview .............................................8
3. DomainKeys Detailed View ........................................8
3.1. Determining the Sending Address of an Email ................9
3.2. Retrieving the Public Key Given the Sending Domain ........10
3.2.1. Introducing "selectors" ............................10
3.2.2. Public Key Signing and Verification Algorithm ......11
3.2.3. Public key Representation in the DNS ...............13
3.2.4. Key Sizes ..........................................14
3.3. Storing the Signature in the Email Header .................15
3.4. Preparation of Email for Transit and Signing ..............17
3.4.1. Preparation for Transit ............................18
3.4.2. Canonicalization for Signing .......................18
3.4.2.1. The "simple" Canonicalization Algorithm ...19
3.4.2.2. The "nofws" Canonicalization Algorithm ....19
3.5. The Signing Process .......................................20
3.5.1. Identifying the Sending Domain .....................20
3.5.2. Determining Whether an Email Should Be Signed ......21
3.5.3. Selecting a Private Key and Corresponding
Selector Information ...............................21
3.5.4. Calculating the Signature Value ....................21
3.5.5. Prepending the "DomainKey-Signature:" Header .......21
3.6. Policy Statement of Sending Domain ........................22
3.7. The Verification Process ..................................23
3.7.1. Presumption that Headers Are Not Reordered .........24
3.7.2. Verification Should Render a Binary Result .........24
3.7.3. Selecting the Most Appropriate
"DomainKey-Signature:" Header ......................24
3.7.4. Retrieve the Public Key Based on the
Signature Information ..............................26
3.7.5. Verify the Signature ...............................27
3.7.6. Retrieving Sending Domain Policy ...................27
3.7.7. Applying Local Policy ..............................27
3.8. Conveying Verification Results to MUAs ....................27
4. Example of Use .................................................29
4.1. The User Composes an Email ................................29
4.2. The Email Is Signed .......................................29
4.3. The Email Signature Is Verified ...........................30
5. Association with a Certificate Authority .......................31
5.1. The "DomainKey-X509:" Header ..............................31
6. Topics for Discussion ..........................................32
6.1. The Benefits of Selectors .................................32
6.2. Canonicalization of Email .................................33
6.3. Mailing Lists .............................................33
6.4. Roving Users ..............................................33
7. Security Considerations ........................................34
7.1. DNS .......................................................34
7.1.1. The DNS Is Not Currently Secure ....................34
7.1.2. DomainKeys Creates Additional DNS Load .............35
7.2. Key Management ............................................35
7.3. Implementation Risks ......................................35
7.4. Privacy Assumptions with Forwarding Addresses .............35
7.5. Cryptographic Processing Is Computationally Intensive .....36
8. The Trial ......................................................36
8.1. Goals .....................................................36
8.2. Results of Trial ..........................................37
9. Note to Implementors Regarding TXT Records .....................37
10. References ....................................................37
10.1. Normative References .....................................37
10.2. Informative References ...................................38
Appendix A - Syntax Rules for the Tag=Value Format .............39
Acknowledgments ................................................40
This document proposes an authentication framework for email that stores public keys in the DNS and digitally signs email on a domain basis. Separate documents discuss how this framework can be extended to validate the delivery path of email as well as facilitate per-user authentication.
このドキュメントは、DNSにパブリックキーを保存し、ドメインベースで電子メールにデジタル的に署名する電子メールの認証フレームワークを提案しています。個別のドキュメントでは、このフレームワークを拡張して電子メールの配信パスを検証し、ユーザーごとの認証を促進する方法について説明します。
The DomainKeys specification was a primary source from which the DomainKeys Identified Mail [DKIM] specification has been derived. The purpose in submitting this document is as an historical reference for deployed implementations written prior to the DKIM specification.
DomainKeys仕様は、ドメインキーがメール[DKIM]仕様を特定した主要なソースであり、派生しました。このドキュメントを提出する目的は、DKIM仕様の前に記述された展開された実装の履歴リファレンスとしてです。
Authentication of email is not currently widespread. Not only is it difficult to prove your own identity, it is impossible to prevent others from abusing your identity.
現在、電子メールの認証は広まっていません。あなた自身のアイデンティティを証明することは難しいだけでなく、他の人があなたのアイデンティティを虐待するのを防ぐことは不可能です。
While most email exchanges do not intrinsically need authentication beyond context, it is the rampant abuse of identity by "spammers", "phishers", and their criminal ilk that makes proof necessary. In other words, authentication is as much about protection as proof.
ほとんどの電子メール交換は本質的にコンテキストを超えて認証を必要としませんが、それは「スパマー」、「フィッシャー」、および証拠を必要とする彼らの犯罪的な同類によるアイデンティティのramp延の虐待です。言い換えれば、認証は証明と同じくらい保護に関するものです。
Importantly, the inability to authenticate email effectively delegates much of the control of the disposition of inbound email to the sender, since senders can trivially assume any email address. Creating email authentication is the first step to returning dispositional control of email to the recipient.
重要なことに、送信者は電子メールアドレスを簡単に想定できるため、電子メールを認証できないことは、送信者へのインバウンドメールの処分の制御の多くを委任します。電子メール認証の作成は、受信者に電子メールの処分制御を返すための最初のステップです。
For the purposes of this document, authentication is seen from a user perspective, and is intended to answer the question "who sent this email?" where "who" is the email address the recipient sees and "this email" is the content that the recipient sees.
このドキュメントの目的のために、認証はユーザーの観点から見られ、「誰がこのメールを送ったのか」という質問に答えることを目的としています。ここで、「who」は受信者が見るメールアドレスと「このメール」は受信者が見るコンテンツです。
DomainKeys combines public key cryptography and the DNS to provide credible domain-level authentication for email.
Domainkeysは、公開キーの暗号とDNSを組み合わせて、電子メールに信頼できるドメインレベルの認証を提供します。
When an email claims to originate from a certain domain, DomainKeys provides a mechanism by which the recipient system can credibly determine that the email did in fact originate from a person or system authorized to send email for that domain.
電子メールが特定のドメインに由来すると主張する場合、ドメインキーは、受信者システムが実際にそのドメインの電子メールを送信することが許可された人またはシステムに由来したことを受信者システムが信頼できるように決定できるメカニズムを提供します。
The authentication provided by DomainKeys works in a number of scenarios in which other authentication systems fail or create complex operational requirements. These include the following:
DomainKeysが提供する認証は、他の認証システムが故障または複雑な運用要件を作成する多くのシナリオで機能します。これらには次のものが含まれます。
o forwarded email
o 転送されたメール
o distributed sending systems
o 分散送信システム
o authorized third-party sending
o 承認されたサードパーティの送信
This base definition of DomainKeys is intended to primarily enable domain-level authenticity. Whether a given message is really sent by the purported user within the domain is outside the scope of the base definition. Having said that, this specification includes the possibility that some domains may wish to delegate fine-grained authentication to individual users.
ドメインキーのこの基本定義は、主にドメインレベルの信頼性を有効にすることを目的としています。特定のメッセージが実際にドメイン内のユーザーと呼ばれるユーザーによって実際に送信されるかどうかは、ベース定義の範囲外です。そうは言っても、この仕様には、一部のドメインが個々のユーザーに細粒認証を委任したい可能性が含まれます。
DomainKeys differs from traditional hierarchical public key systems in that it leverages the DNS for public key management, placing complete and direct control of key generation and management with the owner of the domain. That is, if you have control over the DNS for a given domain, you have control over your DomainKeys for that domain.
ドメインキーは、従来の階層的な公開キーシステムとは異なります。これは、公開キー管理のためにDNSを活用し、ドメインの所有者とキー生成と管理の完全かつ直接的な制御を配置するからです。つまり、特定のドメインのDNSを制御できる場合、そのドメインのドメインキーを制御できます。
The DNS is proposed as the initial mechanism for publishing public keys. DomainKeys is specifically designed to be extensible to other key-fetching services as they become available.
DNSは、公開キーを公開するための初期メカニズムとして提案されています。Domainkeysは、利用可能になるにつれて、他のキーフェッチングサービスに拡張できるように特別に設計されています。
For practical reasons, it is expected that initial implementations of DomainKeys will be deployed on Mail Transfer Agents (MTAs) that accept or relay email across administrative or organizational boundaries. There are numerous advantages to deployment at the border MTA, including:
実際的な理由から、管理者または組織の境界を越えて電子メールを受け入れるかリレーする郵便送金エージェント（MTA）にドメインキーの初期実装が展開されることが期待されています。Border MTAでの展開には多くの利点があります。
o a reduction in the number of MTAs that have to be changed to support an implementation of DomainKeys
o ドメインキーの実装をサポートするために変更する必要があるMTAの数の減少
o a reduction in the number of MTAs involved in transmitting the email between a signing system and a verifying system, thus reducing the number of places that can make accidental changes to the contents
o 署名システムと検証システムの間で電子メールの送信に関与するMTAの数の減少により、コンテンツに偶発的な変更を加えることができる場所の数が減少します
o removing the need to implement DomainKeys within an internal email network.
o 内部メールネットワーク内でドメインキーを実装する必要性を削除します。
However, there is no necessity to deploy DomainKeys at the border as signing and verifying can effectively occur anywhere from the border MTA right back to the Mail User Agent (MUA). In particular, the best place to sign an email for many domains is likely to be at the point of SUBMISSION where the sender is often authenticated through SMTP AUTH or other identifying mechanisms.
ただし、署名と検証は、ボーダーMTAからメールユーザーエージェント（MUA）に戻る署名と検証が効果的に発生する可能性があるため、国境にドメインキーを展開する必要はありません。特に、多くのドメインに電子メールに署名するのに最適な場所は、送信者がSMTP AUTHまたは他の識別メカニズムを介してしばしば認証されることが多い提出ポイントにある可能性があります。
It follows that testing the authenticity of an email results in some action based on the results of the test. Oftentimes, the action is to notify the MUA in some way -- typically via a header line.
そのため、電子メールの信頼性をテストすると、テストの結果に基づいてアクションが発生します。多くの場合、アクションはMUAに何らかの方法で通知することです - 通常はヘッダーラインを介して。
The "Domainkey-Status:" header is defined in this specification for recording authentication results in the email.
「domainkey-status：」ヘッダーは、電子メールに認証結果を記録するためのこの仕様で定義されています。
The intent of this specification is to communicate the fundamental characteristics of DomainKeys for an implementor. However, some aspects are derived from the functionality of the openssl command [OPENSSL] and, rather than duplicate that documentation, implementors are expected to understand the mechanics of the openssl command, sufficient to complete the implementation.
この仕様の目的は、実装者のドメインキーの基本的な特性を伝えることです。ただし、いくつかの側面は、OpenSSLコマンド[openSSL]の機能から派生しており、そのドキュメントを複製するのではなく、実装者はOpenSSLコマンドのメカニズムを理解し、実装を完了するのに十分なことが期待されています。
The motivation for DomainKeys is to define a simple, cheap, and "sufficiently effective" mechanism by which domain owners can control who has authority to send email using their domain. To this end, the designers of DomainKeys set out to build a framework that:
Domainkeysの動機は、ドメインの所有者がドメインを使用して電子メールを送信する権限を持っている人を制御できるシンプルで安価で「十分に効果的な」メカニズムを定義することです。この目的のために、Domainkeysのデザイナーは、次のようなフレームワークを構築するために着手しました。
o is transparent and compatible with the existing email infrastructure
o 透明性があり、既存の電子メールインフラストラクチャと互換性があります
o requires no new infrastructure
o 新しいインフラストラクチャは必要ありません
o can be implemented independently of clients in order to reduce deployment time
o 展開時間を短縮するために、クライアントとは独立して実装できます
o does not require the use of a central certificate authority that might impose fees for certificates or introduce delays to deployment
o 証明書に料金を課したり、展開に遅延を導入したりする可能性のある中央認証局の使用を必要としません
o can be deployed incrementally
o 徐々に展開できます
While we believe that DomainKeys meets these criteria, it is by no means a perfect solution. The current Internet imposes considerable compromises on any similar scheme, and readers should be careful not to misinterpret the information provided in this document to imply that DomainKeys makes stronger credibility statements than it is able to do.
Domainkeysはこれらの基準を満たしていると信じていますが、決して完璧な解決策ではありません。現在のインターネットは、同様のスキームにかなりの妥協を課しており、読者はこのドキュメントに提供された情報を誤って解釈しないように注意して、Domainkeysができるよりも強力な信頼できる声明を上げることを暗示する必要があります。
As the reader will discover, DomainKeys is solely an authentication system. It is not a magic bullet for spam, nor is it an authorization system, a reputation system, a certification system, or a trust system.
読者が発見するように、Domainkeysは認証システムのみです。これは、スパムの魔法の弾丸ではなく、認可システム、評判システム、認定システム、または信頼システムでもありません。
However, a strong authentication system such as DomainKeys creates an unimpeachable framework within which comprehensive authorization systems, reputations systems, and their ilk can be developed.
ただし、Domainkeysなどの強力な認証システムは、包括的な認可システム、評判システム、およびその同類を開発できる意外なフレームワークを作成します。
With reference to the following sample email:
次のサンプルメールを参照してください。
Line Data
Number Bytes Content
---- --- --------------------------------------------
01 46 From: "Joe SixPack" <joe@football.example.com>
02 40 To: "Suzie Q" <suzie@shopping.example.net>
03 25 Subject: Is dinner ready?
04 43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
05 40 Comment: This comment has a continuation
06 51 because this line begins with folding white space
07 60 Message-ID: <20030712040037.46341@football.example.com>
08 00
09 03 Hi.
10 00
11 37 We lost the game. Are you hungry yet?
12 00
13 04 Joe.
14 00
15 00
Line 01 is the first line of the email and the first line of the headers.
行01は、電子メールの最初の行であり、ヘッダーの最初の行です。
Lines 05 and 06 constitute the "Comment:" header.
行05および06は、「コメント：」ヘッダーを構成します。
Line 06 is a continuation header line.
ライン06は継続ヘッダーラインです。
Line 07 is the last line of the headers.
ライン07はヘッダーの最後の行です。
Line 08 is the empty line that separates the header from the body.
ライン08は、ヘッダーを体から分離する空の線です。
Line 09 is the first line of the body.
ライン09は体の最初の線です。
Lines 10, 12, 14, and 15 are empty lines.
10行目、12、14、および15行目は空の行です。
Line 13 is the last non-empty line of the email.
13行目は、電子メールの最後の非空白の行です。
Line 15 is the last line of the body and the last line of the email.
15行目は、ボディの最後の行であり、電子メールの最後の行です。
Lines 01 to 15 constitute the complete email.
行01〜15は、完全な電子メールを構成します。
Line 01 is earlier than line 02, and line 02 is later than line 01.
行01は行02よりも早く、行02は1行01より遅いです。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119].
このドキュメントは、大文字に表示される用語を使用することがあります。「必須」、「「推奨」、「推奨」、「そうはない」、「そうではない」、「必要はない」という用語が大文字に表示される場合、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は[RFC2119]に表示されます。
Under DomainKeys, a domain owner generates one or more private/public key pairs that will be used to sign messages originating from that domain. The domain owner places the public key in his domain namespace (i.e., in a DNS record associated with that domain), and makes the private key available to the outbound email system. When an email is submitted by an authorized user of that domain, the email system uses the private key to digitally sign the email associated with the sending domain. The signature is added as a header to the email, and the message is transferred to its recipients in the usual way.
ドメインキーの下では、ドメインの所有者は、そのドメインから発信されたメッセージに署名するために使用される1つまたは複数のプライベート/公開キーペアを生成します。ドメインの所有者は、公開キーをドメイン名空間（つまり、そのドメインに関連付けられたDNSレコード）に配置し、秘密鍵をアウトバウンドメールシステムで利用できるようにします。そのドメインの承認されたユーザーによって電子メールが送信されると、電子メールシステムは秘密キーを使用して、送信ドメインに関連付けられた電子メールにデジタルに署名します。署名はメールのヘッダーとして追加され、メッセージは通常の方法で受信者に転送されます。
When a message is received with a DomainKey signature header, the receiving system can verify the signature as follows:
DomainKey Signature Headerでメッセージを受信すると、受信システムは次のように署名を検証できます。
1. Extract the signature and claimed sending domain from the email.
1. 署名を抽出し、電子メールからドメインを送信すると主張します。
2. Fetch the public key from the claimed sending domain namespace.
2. 主張された送信ドメイン名空間から公開キーを取得します。
3. Use public key to determine whether the signature of the email has been generated with the corresponding private key, and thus whether the email was sent with the authority of the claimed sending domain.
3. 公開鍵を使用して、電子メールの署名が対応する秘密鍵で生成されたかどうか、したがって、電子メールが請求された送信ドメインの権限で送信されたかどうかを判断します。
In the event that an email arrives without a signature or when the signature verification fails, the receiving system retrieves the policy of the claimed sending domain to ascertain the preferred disposition of such email.
署名なしで電子メールが到着した場合、または署名検証が失敗した場合、受信システムは、そのような電子メールの優先された処分を確認するために、請求されたドメインを送信するポリシーを取得します。
Armed with this information, the recipient system can apply local policy based on the results of the signature test.
この情報を武装して、受信者システムは署名テストの結果に基づいてローカルポリシーを適用できます。
This section discusses the specifics of DomainKeys that are needed to create interoperable implementations. This section answers the following questions:
このセクションでは、相互運用可能な実装を作成するために必要なドメインキーの詳細について説明します。このセクションは、次の質問に答えます。
Given an email, how is the sending domain determined?
メールが与えられた場合、送信ドメインはどのように決定されますか？
How is the public key retrieved for a sending domain?
送信ドメインの公開キーはどのように取得されますか？
As email transits the email system, it can potentially go through a number of changes. Which parts of the email are included in the signature and how are they protected from such transformations?
電子メールが電子メールシステムを通過すると、潜在的に多くの変更を実行する可能性があります。電子メールのどの部分が署名に含まれており、それらはそのような変換からどのように保護されていますか？
How is the signature represented in the email?
署名はメールにどのように表されていますか？
If a signature is not present, or a verification fails, how does the recipient determine the policy intent of the sending domain?
署名が存在しない場合、または検証が失敗した場合、受信者は送信ドメインのポリシー意図をどのように決定しますか？
Finally, on verifying the authenticity of an email, how is that result conveyed to participating MUAs?
最後に、電子メールの信頼性を確認すると、その結果はどのように参加しているMUAに伝えられますか？
While there are many alternative design choices, most lead to comparable functionality. The overriding selection criteria used to choose among the alternatives are as follows:
多くの代替設計の選択肢がありますが、ほとんどは同等の機能につながります。代替案の中から選択するために使用される最優先選択基準は次のとおりです。
o use deployed technology whenever possible
o 可能な限り展開されたテクノロジーを使用してください
o prefer ease of implementation
o 実装の容易さを好む
o avoid trading risk for excessive flexibility or interoperability
o 過度の柔軟性や相互運用性のための取引リスクを避けてください
o include basic flexibility
o 基本的な柔軟性を含めます
Adherence to these criteria implies that some existing email implementations will require changes to participate in DomainKeys. Ultimately, some hard choices need to be made regarding which requirements are more important.
これらの基準を順守することは、既存の電子メールの実装では、ドメインキーに参加するために変更が必要になることを意味します。最終的に、どの要件がより重要であるかに関して、いくつかの難しい選択をする必要があります。
The goal of DomainKeys is to give the recipient confidence that the email originated from the claimed sender. As with much of Internet email, agreement over what constitutes the "sender" is no easy matter. Forwarding systems and mailing lists add serious complications to an overtly simple question. From the point of view of the recipient, the authenticity claim should be directed at the domain most visible to the recipient.
Domainkeysの目標は、電子メールが請求された送信者から発信されたという自信を受信者に与えることです。多くのインターネットメールと同様に、「送信者」を構成するものに関する同意は簡単なことではありません。転送システムとメーリングリストは、あからさまに簡単な質問に深刻な合併症を加えます。受信者の観点から、信頼性の請求は、受信者に最も見えるドメインに向けられるべきです。
In the first instance, the most visible address is clearly the RFC 2822 "From:" address [RFC2822]. Therefore, a conforming email MUST contain a single "From:" header from which an email address with a domain name can be extracted.
最初の例では、最も目に見えるアドレスは明らかにRFC 2822 "から次のとおりです。アドレス[RFC2822]。したがって、適合電子メールには、ドメイン名を持つ電子メールアドレスを抽出できる単一の「from：」ヘッダーを含める必要があります。
A conforming email MAY contain a single RFC 2822 "Sender:" header from which an email address with a domain name can be extracted.
適合電子メールには、単一のRFC 2822 "送信者："ヘッダーが含まれている場合があります。ヘッダーは、ドメイン名を持つ電子メールアドレスを抽出できます。
If the email has a valid "From:" and a valid "Sender:" header, then the signer MUST use the sending address in the "Sender:" header.
電子メールに有効な「from」と有効な「送信者」がある場合、 "ヘッダー、署名者は「送信者：」ヘッダーの送信アドレスを使用する必要があります。
If the email has a valid "From:" and no "Sender:" header, then the signer MUST use the first sending address in the "From:" header.
電子メールに有効な「from：」と「no "sender："ヘッダーがある場合、署名者は "from：" headerの最初の送信アドレスを使用する必要があります。
In all other cases, a signer MUST NOT sign the email. Implementors should note that an email with a "Sender:" header and no "From:" header MUST NOT be signed.
他のすべての場合、署名者は電子メールに署名してはなりません。実装者は、「送信者：」の電子メールが次のようになっていることに注意する必要があります。
The domain name in the sending address constitutes the "sending domain".
送信アドレスのドメイン名は、「送信ドメイン」を構成します。
To avoid namespace conflicts, it is proposed that the DNS namespace "_domainkey." be reserved within the sending domain for storing public keys, e.g., if the sending domain is example.net, then the public keys for that domain are stored in the _domainkey.example.net namespace.
名前空間の競合を回避するために、DNS名空間「_DomainKey」が提案されています。パブリックキーを保存するための送信ドメイン内に予約されます。たとえば、送信ドメインがexample.netの場合、そのドメインのパブリックキーは_domainkey.example.net namespaceに保存されます。
To support multiple concurrent public keys per sending domain, the DNS namespace is further subdivided with "selectors". Selectors are arbitrary names below the "_domainkey." namespace. A selector value and length MUST be legal in the DNS namespace and in email headers with the additional provision that they cannot contain a semicolon.
送信ドメインごとに複数の同時パブリックキーをサポートするために、DNSネームスペースはさらに「セレクター」で細分されます。セレクターは、「_domainkey」の下に任意の名前です。名前空間。セレクターの値と長さは、DNSネームスペースと電子メールヘッダーで、セミコロンを封じ込めることができない追加のプロビジョニングを備えている必要があります。
Examples of namespaces using selectors are as follows:
セレクターを使用した名前空間の例は次のとおりです。
"coolumbeach._domainkey.example.net" "sebastopol._domainkey.example.net" "reykjavik._domainkey.example.net" "default._domainkey.example.net"
"coolumbeach.key.example.net" "sebastopol._domainkey.example.net" "reykjavik._domainkey.example.net" "default._domainkey.example.net"
and
と
"2005.pao._domainkey.example.net" "2005.sql._domainkey.example.net" "2005.rhv._domainkey.example.net"
"2005.pao._domainkey.example.net" "" 2005.sql._domainkey.example.net "" "2005.rhv._domainkey.example.net"
Periods are allowed in selectors and are to be treated as component separators. In the case of DNS queries, that means the period defines subdomain boundaries.
期間はセレクターで許可されており、コンポーネントセパレーターとして扱われます。DNSクエリの場合、それは期間がサブドメインの境界を定義することを意味します。
The number of public keys and corresponding selectors for each domain is determined by the domain owner. Many domain owners will be satisfied with just one selector, whereas administratively distributed organizations may choose to manage disparate selectors and key pairs in different regions, or on different email servers.
各ドメインのパブリックキーと対応するセレクターの数は、ドメイン所有者によって決定されます。多くのドメイン所有者は、1つのセレクターのみに満足しますが、管理的に分散された組織は、異なる地域または異なる電子メールサーバーで、異なるセレクターとキーペアを管理することを選択できます。
Beyond administrative convenience, selectors make it possible to seamlessly replace public keys on a routine basis. If a domain wishes to change from using a public key associated with selector "2005" to a public key associated with selector "2006", it merely makes sure that both public keys are advertised in the DNS concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the "2006" private key. At the end of the transition period, the "2005" public key is removed from the DNS.
管理者の利便性を超えて、セレクターは日常的にパブリックキーをシームレスに交換することを可能にします。ドメインがセレクター「2005」に関連付けられた公開キーの使用から、セレクター「2006」に関連付けられた公開キーに変更したい場合、電子メールができる移行期間中、両方のパブリックキーがDNSで同時に宣伝されることを確認するだけです。検証前に輸送中に。トランジション期間の開始時に、アウトバウンドメールサーバーは、「2006」秘密鍵で署名するように構成されています。移行期間の終わりに、「2005」の公開キーがDNSから削除されます。
While some domains may wish to make selector values well known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties. For example, if per-user keys are issued, the domain owner will need to make the decision as to whether to make this selector associated directly with the user name or make it some unassociated random value, such as the fingerprint of the public key.
一部のドメインは、セレクターの値をよく知られていることを望むかもしれませんが、他のドメインは、外部の当事者によるデータの収穫を可能にする方法でセレクター名を割り当てないように注意したいと考えています。たとえば、ユーザーごとのキーが発行された場合、ドメインの所有者は、このセレクターをユーザー名に直接関連付けるか、公開鍵の指紋などの関連性のないランダム値にするかどうかを決定する必要があります。
The default signature is an RSA signed SHA1 digest of the complete email.
デフォルトの署名は、完全な電子メールのRSA署名されたSHA1ダイジェストです。
For ease of explanation, the openssl command is used throughout this document to describe the mechanism by which keys and signatures are managed.
説明のために、OpenSSLコマンドは、このドキュメント全体で使用され、キーと署名が管理されるメカニズムを説明します。
One way to generate a 768-bit private key suitable for DomainKeys is to use openssl like this:
ドメインキーに適した768ビットの秘密鍵を生成する1つの方法は、次のようなOpenSSLを使用することです。
$ openssl genrsa -out rsa.private 768 which results in the file rsa.private containing the key information similar to this:
$ openssl genrsa -out rsa.private 768で、これに類似した重要な情報を含むファイルrsa.privateになります。
-----BEGIN RSA PRIVATE KEY-----
MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
-----END RSA PRIVATE KEY-----
Once a private key has been generated, the openssl command can be used to sign an appropriately prepared email, like this:
秘密鍵が生成されると、OpenSSLコマンドを使用して、このような適切に準備された電子メールに署名できます。
$ openssl dgst -sign rsa.private -sha1 <input.file
which results in signature data similar to this when represented in Base64 [BASE64] format:
これにより、Base64 [base64]形式で表された場合、これに類似した署名データが得られます。
aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl
AOIDEX42BB/GP4SCQTDIQJCPAOBYR 54YVCTQCCCC4RSEFYBY9 OMKD3PJ/TVXATETZ MSYBUW3WZIAMB MVN7F3RHMNOZHJ0YORQBNN4QJQHPBBPBPBWEQW09AMJBYZ/0LSLSL
How this signature is added to the email is discussed later in this document.
この署名がメールに追加される方法については、このドキュメントの後半で説明します。
To extract the public key component from the private key, use openssl like this:
秘密鍵から公開キーコンポーネントを抽出するには、次のようにopenSSLを使用します。
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
which results in the file rsa.public containing the key information similar to this:
これは、これに類似した主要な情報を含むファイルrsa.publicになります。
-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----
This public key data is placed in the DNS.
この公開データはDNSに配置されます。
With the signature, canonical email contents and public key, a verifying system can test the validity of the signature. The openssl invocation to verify a signature looks like this:
署名、標準電子メールのコンテンツ、および公開キーを使用すると、検証システムは署名の有効性をテストできます。署名を確認するためのOpenSSLの呼び出しは次のようになります。
$ openssl dgst -verify rsa.public -sha1 -signature sig.file <input.file
There is currently no standard method defined for storing public keys in the DNS. As an interim measure, the public key is stored as a TXT record derived from a Privacy-Enhanced Mail (PEM) format [PEM], that is, as a Base64 representation of a DER encoded key. Here is an example of a 768-bit RSA key in PEM form:
現在、DNSにパブリックキーを保存するための標準メソッドは定義されていません。暫定的な尺度として、公開キーは、プライバシー強化メール（PEM）形式[PEM]から派生したTXTレコードとして保存されます。つまり、DERエンコードキーのBase64表現です。PEM形式の768ビットRSAキーの例を次に示します。
-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----
To save scarce DNS packet space and aid extensibility, the PEM wrapping MUST be removed and the remaining public key data along with other attributes relevant to DomainKeys functionality are stored as tag=value pairs separated by semicolons, for example, as in the following:
DNSパケットスペースを削減し、拡張性を補うために、PEMラッピングを削除する必要があり、残りの公開キーデータとドメインキー機能に関連する他の属性は、次のようにセミコロンで区切られたタグ=値ペアとして保存されます。
brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048 bits. Signers MUST support at least one of the verifier supported key sizes.
検証剤は、512、768、1024、1536、および2048ビットのキーサイズをサポートする必要があります。署名者は、検証剤をサポートするキーサイズの少なくとも1つをサポートする必要があります。
The current valid tags are as follows:
現在の有効なタグは次のとおりです。
g = granularity of the key. If present with a non-zero length value, this value MUST exactly match the local part of the sending address. This tag is optional.
G =キーの粒度。ゼロ以外の長さの値が存在する場合、この値は送信アドレスのローカル部分と正確に一致する必要があります。このタグはオプションです。
The intent of this tag is to constrain which sending address can legitimately use this selector. An email with a sending address that does not match the value of this tag constitutes a failed verification.
このタグの意図は、アドレスを送信することがこのセレクターを合法的に使用できることを制約することです。このタグの値と一致しない送信アドレスを含むメールは、失敗した検証を構成します。
k = key type (rsa is the default). Signers and verifiers MUST support the 'rsa' key type. This tag is optional.
k =キータイプ（RSAがデフォルト）。署名者と検証者は、「RSA」キータイプをサポートする必要があります。このタグはオプションです。
n = Notes that may be of interest to a human. No interpretation is made by any program. This tag is optional.
n =人間にとって興味深いメモ。どのプログラムでも解釈は行われません。このタグはオプションです。
p = public key data, encoded as a Base64 string. An empty value means that this public key has been revoked. This tag MUST be present.
p = base64文字列としてエンコードされた公開キーデータ。空の値は、この公開鍵が取り消されたことを意味します。このタグは存在する必要があります。
t = a set of flags that define boolean attributes. Valid attributes are as follows:
T =ブール属性を定義するフラグのセット。有効な属性は次のとおりです。
y = testing mode. This domain is testing DomainKeys and unverified email MUST NOT be treated differently from verified email. Recipient systems MAY wish to track testing mode results to assist the sender.
y =テストモード。このドメインはドメインキーをテストしており、未検証の電子メールを検証された電子メールとは異なる方法で扱うべきではありません。受信者システムは、送信者を支援するためにテストモードの結果を追跡したい場合があります。
This tag is optional.
このタグはオプションです。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（タグの構文ルール=値形式については、付録Aで説明します。）
Keeping the size of the TXT record to a minimum is important as some implementations of content and caching DNS servers are reported to have problems supporting large TXT records. In the example above, the encoding generates a 182-byte TXT record. That this encoding is less than 512 bytes is of particular significance as it fits within a single UDP response packet. With careful selection of query values, a TXT record can accommodate a 2048 bit key.
TXTレコードのサイズを最小限に抑えることは重要です。コンテンツとキャッシュDNSサーバーのいくつかの実装には、大規模なTXTレコードをサポートする問題があると報告されています。上記の例では、エンコードは182バイトのTXTレコードを生成します。このエンコードが512バイト未満であることは、単一のUDP応答パケットに収まるため、特に重要です。クエリ値を慎重に選択すると、TXTレコードは2048ビットキーに対応できます。
For the same size restriction reason, the "n" tag SHOULD be used sparingly. The most likely use of this tag is to convey a reason why a public key might have been revoked. In this case, set the "n" tag to the explanation and remove the public key value from the "p" tag.
同じサイズの制限の理由で、「n」タグを控えめに使用する必要があります。このタグの最も可能性の高い使用は、公開鍵が取り消された理由を伝えることです。この場合、「n」タグを説明に設定し、「p」タグから公開キーの値を削除します。
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. This specification does not define either minimum or maximum key sizes -- that decision is a matter for each domain owner.
適切なキーサイズを選択することは、コスト、パフォーマンス、リスクのトレードオフです。この仕様では、最小または最大のキーサイズのいずれも定義されていません。その決定は、各ドメイン所有者の問題です。
Factors that should influence this decision include the following:
この決定に影響を与えるべき要因には、次のものが含まれます。
o the practical constraint that a 2048-bit key is the largest key that fits within a 512-byte DNS UDP response packet
o 2048ビットキーが512バイトのDNS UDP応答パケットに適合する最大のキーであるという実際の制約
o larger keys impose higher CPU costs to verify and sign email
o 電子メールを確認して署名するために、より大きなキーがCPUコストを高くします
o keys can be replaced on a regular basis; thus, their lifetime can be relatively short
o キーは定期的に交換できます。したがって、彼らの寿命は比較的短くなる可能性があります
o the security goals of this specification are modest compared to typical goals of public key systems
o この仕様のセキュリティ目標は、公開キーシステムの典型的な目標と比較して控えめです
In general, it is expected that most domain owners will use keys that are no larger than 1024 bits.
一般に、ほとんどのドメイン所有者は、1024ビット以下のキーを使用することが期待されています。
The signature of the email is stored in the "DomainKey-Signature:" header. This header contains all of the signature and key-fetching data.
電子メールの署名は、「domainkey-signature：」ヘッダーに保存されます。このヘッダーには、すべての署名データとキーフェッチングデータが含まれています。
When generating the signed email, the "DomainKey-Signature:" header MUST precede the original email headers presented to the signature algorithm.
署名された電子メールを生成するとき、「domainkey-signature：」ヘッダーは、署名アルゴリズムに提示された元のメールヘッダーの前に先行する必要があります。
The "DomainKey-Signature:" header is not included in the signature calculation.
「DomainKey-Signature：」ヘッダーは署名計算に含まれていません。
For extensibility, the "DomainKey-Signature:" header contains tag=value pairs separated by semicolons, for example, as in the following:
拡張性のために、「DomainKey-Signature：」ヘッダーには、次のように、セミコロンで区切られたタグ=値ペアが含まれます。
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
q=dns; c=simple
The current valid tags are as follows:
現在の有効なタグは次のとおりです。
a = The algorithm used to generate the signature. The default is "rsa-sha1", an RSA signed SHA1 digest. Signers and verifiers MUST support "rsa-sha1".
a =署名を生成するために使用されるアルゴリズム。デフォルトは「RSA-Sha1」で、RSAはSHA1ダイジェストに署名します。署名者と検証者は「RSA-Sha1」をサポートする必要があります。
b = The signature data, encoded as a Base64 string. This tag MUST be present.
b = signatureデータ、base64文字列としてエンコードされています。このタグは存在する必要があります。
Whitespace is ignored in this value and MUST be removed when reassembling the original signature. This is another way of saying that the signing process can safely insert folding whitespace in this value to conform to line-length limits.
この値では白文学は無視され、元の署名を再組み立てするときは削除する必要があります。これは、署名プロセスがこの値に折りたたみホワイトスペースを安全に挿入して、ラインレングスの制限に準拠できると言う別の方法です。
c = Canonicalization algorithm. The method by which the headers and content are prepared for presentation to the signing algorithm. This tag MUST be present. Verifiers MUST support "simple" and "nofws". Signers MUST support at least one of the verifier-supported algorithms.
C =標準化アルゴリズム。ヘッダーとコンテンツが署名アルゴリズムへのプレゼンテーションのために準備される方法。このタグは存在する必要があります。検証剤は、「シンプル」と「nofws」をサポートする必要があります。署名者は、検証者がサポートするアルゴリズムの少なくとも1つをサポートする必要があります。
d = The domain name of the signing domain. This tag MUST be present. In conjunction with the selector tag, this domain forms the basis of the public key query. The value in this tag MUST match the domain of the sending email address or MUST be one of the parent domains of the sending email address. Domain name comparison is case insensitive.
d =署名ドメインのドメイン名。このタグは存在する必要があります。セレクタータグと組み合わせて、このドメインは公開キークエリの基礎を形成します。このタグの値は、送信メールアドレスのドメインと一致する必要があります。または、送信メールアドレスの親ドメインの1つである必要があります。ドメイン名の比較は、症例鈍感です。
The matching process for this tag is called subdomain matching, as the sending email address must be the domain or subdomain of the value.
送信メールアドレスが値のドメインまたはサブドメインでなければならないため、このタグのマッチングプロセスはサブドメインマッチングと呼ばれます。
h = A colon-separated list of header field names that identify the headers presented to the signing algorithm. If present, the value MUST contain the complete list of headers in the order presented to the signing algorithm.
H =署名アルゴリズムに提示されたヘッダーを識別するヘッダーフィールド名のコロン分離リスト。存在する場合、値には、署名アルゴリズムに提示された順序でヘッダーの完全なリストを含める必要があります。
If present, this tag MUST include the header that was used to identify the sending domain, i.e., the "From:" or "Sender:" header; thus, this tag can never contain an empty value.
存在する場合、このタグには、送信ドメイン、つまり「from」または「sender：」ヘッダーを識別するために使用されたヘッダーを含める必要があります。したがって、このタグには空の値を含めることはできません。
If this tag is not present, all headers subsequent to the signature header are included in the order found in the email.
このタグが存在しない場合、署名ヘッダーに続くすべてのヘッダーは、電子メールにある順序に含まれています。
A verifier MUST support this tag. A signer MAY support this tag. If a signer generates this tag, it MUST include all email headers in the original email, as a verifier MAY remove or render suspicious, lines that are not included in the signature.
検証者はこのタグをサポートする必要があります。署名者はこのタグをサポートする場合があります。署名者がこのタグを生成する場合、検証者が署名に含まれていない行を削除またはレンダリングする可能性があるため、元の電子メールにすべての電子メールヘッダーを含める必要があります。
In the presence of duplicate headers, a signer may include duplicate entries in the list of headers in this tag. If a header is included in this list, a verifier must include all occurrences of that header, subsequent to the "DomainKey-Signature:" header in the verification.
重複したヘッダーが存在する場合、署名者には、このタグのヘッダーのリストに重複するエントリを含めることができます。このリストにヘッダーが含まれている場合、検証者は、「DomainKey-Signature：」ヘッダーに続いて、そのヘッダーのすべての発生を含める必要があります。
If a header identified in this list is not found after the "DomainKey-Signature:" header in the verification process, a verifier may "look" for a matching header prior to the "DomainKey-Signature:" header; however, signers should not rely on this as early experience suggests that most verifiers do not try to "look" back before the "DomainKey-Signature:" header.
このリストで識別されたヘッダーが「Domainkey-Signature：」の後に検証プロセスのヘッダーの後に見つからない場合、検証者は「DomainKey-Signature：」ヘッダーの前に一致するヘッダーを「見る」ことができます。ただし、初期の経験は、ほとんどの検証者が「domainkey-signature：」ヘッダーの前に「見て」しようとしないことを示唆しているため、署名者はこれに依存すべきではありません。
Whitespace is ignored in this value and header comparisons are case insensitive.
この値では白文学が無視され、ヘッダーの比較は症例鈍感です。
q = The query method used to retrieve the public key. This tag MUST be present. Currently, the only valid value is "dns", which defines the DNS lookup algorithm described in this document. Verifiers and signers MUST support "dns".
Q =公開キーを取得するために使用されるクエリメソッド。このタグは存在する必要があります。現在、唯一の有効な値は「DNS」です。これは、このドキュメントで説明されているDNSルックアップアルゴリズムを定義しています。検証者と署名者は「DNS」をサポートする必要があります。
s = The selector used to form the query for the public key. This tag MUST be present. In the DNS query type, this value is prepended to the "_domainkey." namespace of the sending domain.
s =公開キーのクエリを形成するために使用されるセレクター。このタグは存在する必要があります。DNSクエリタイプでは、この値は「_DomainKey」に加えられます。送信ドメインの名前空間。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（タグの構文ルール=値形式については、付録Aで説明します。）
Here is an example of a signature header spread across multiple continuation lines:
これは、複数の継続ラインに広がる署名ヘッダーの例です。
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Extreme care must be taken to ensure that any new tags added to this header are defined and used solely for the purpose of fetching and verifying the signature. Any semantics beyond verification cannot be trusted, as this header is not protected by the signature.
このヘッダーに追加された新しいタグが定義され、署名を取得して検証する目的でのみ使用されることを確認するために、細心の注意を払う必要があります。このヘッダーは署名によって保護されていないため、検証を超えたセマンティクスを信頼することはできません。
If additional semantics not pertaining directly to signature verification are required, they must only be added as subsequent headers protected by the signature. Semantic additions might include audit information describing the initial submission.
署名検証に直接関係しない追加のセマンティクスが必要である場合、それらは署名によって保護された後続のヘッダーとしてのみ追加する必要があります。セマンティックの追加には、最初の提出を説明する監査情報が含まれる場合があります。
The fundamental purpose of a cryptographic signature is to ensure that the signed content matches the contents presented for verification. However, unlike just about every other Internet protocol, the email content is routinely modified as it enters and transits the email system.
暗号化署名の基本的な目的は、署名されたコンテンツが検証のために提示されたコンテンツと一致するようにすることです。ただし、他のすべてのインターネットプロトコルとは異なり、電子メールコンテンツは、電子メールシステムに入ってトランジットするときに定期的に変更されます。
Fortunately most of the modifications typically made to email can be predicted and consequently accounted for when signing and verifying.
幸いなことに、通常、電子メールに対して行われた変更のほとんどは予測でき、その結果、署名と検証の際に説明することができます。
To maximize the chance of a successful verification, submitted email should be prepared for transport prior to signing, and the data presented to the signing algorithm is canonicalized to exclude the most common and minor changes made to email.
検証が成功する可能性を最大化するために、署名する前に送信された電子メールを輸送用に準備する必要があり、署名アルゴリズムに提示されたデータは、電子メールに行われた最も一般的でマイナーな変更を除外するために標準化されます。
The SMTP protocol defines a number of potential limitations to email transport, particularly pertaining to line lengths and 8-bit content.
SMTPプロトコルは、特にラインの長さと8ビットコンテンツに関連する電子メールトランスポートに多くの潜在的な制限を定義します。
While the editor has observed that most modern SMTP implementations accept 8-bit email and long lines, some implementations still do not. Consequently, a DomainKeys implementation SHOULD prepare an email to be suitable for the lowest common denominator of SMTP prior to presenting the email for signing.
編集者は、ほとんどの最新のSMTP実装が8ビットの電子メールと長い行を受け入れることを観察しましたが、いくつかの実装はまだそうではありません。その結果、ドメインキーの実装は、署名のために電子メールを提示する前に、SMTPの最も低い一般的な分母に適した電子メールを準備する必要があります。
DomainKeys is initially expected to be deployed at, or close to, the email borders of an organization rather than in MUAs or SUBMISSION servers. In other words, the signing and verifying algorithms normally apply after an email has been packaged, transmogrified, and generally prepared for transmission across the Internet via SMTP and, thus the likelihood of the email being subsequently modified is reduced.
Domainkeysは、MUASまたは提出サーバーではなく、組織の電子メールの境界線に展開されるか、または近くに展開される予定です。言い換えれば、電子メールがパッケージ化され、伝達され、一般的にSMTPを介してインターネットを介して送信するために署名と検証のアルゴリズムが通常適用されるため、電子メールがその後変更される可能性が削減されます。
Nonetheless, empirical evidence suggests that some mail servers and relay systems modify email in transit, potentially invalidating a signature.
それにもかかわらず、経験的証拠は、一部のメールサーバーとリレーシステムが輸送中に電子メールを変更し、署名を無効にする可能性があることを示唆しています。
There are two competing perspectives on such modifications. For most senders, mild modification of email is immaterial to the authentication status of the email. For such senders, a canonicalization algorithm that survives modest in-transit modification is preferred.
このような変更には2つの競合する視点があります。ほとんどの送信者にとって、電子メールの軽度の変更は、電子メールの認証ステータスには重要ではありません。このような送信者には、控えめな輸送内の変更に耐える標準化アルゴリズムが推奨されます。
For other senders however, any modification of the email - however minor -- results in a desire for the authentication to fail. In other words, such senders do not want a modified email to be seen as being authorized by them. These senders prefer a canonicalization algorithm that does not tolerate in-transit modification of the signed email.
ただし、他の送信者の場合、電子メールの変更 - マイナーでは、認証が失敗することを望んでいます。言い換えれば、そのような送信者は、変更された電子メールが彼らによって許可されていると見なされることを望んでいません。これらの送信者は、署名された電子メールの輸送内の変更に耐えられない標準化アルゴリズムを好みます。
To satisfy both requirements, two canonicalization algorithms are defined. A "simple" algorithm that tolerates almost no modification and a "nofws" algorithm that tolerates common modifications as whitespace replacement and header line rewrapping.
両方の要件を満たすために、2つの標準化アルゴリズムが定義されています。ほぼ修正がないことを許容する「単純な」アルゴリズムと、ホワイトスペースの交換およびヘッダーラインの書き直しとして一般的な変更を許容する「nofws」アルゴリズム。
A sender may choose either algorithm when signing an email. A verifier MUST be able to process email using either algorithm.
送信者は、電子メールに署名するときにいずれかのアルゴリズムを選択できます。検証器は、いずれかのアルゴリズムを使用して電子メールを処理できる必要があります。
Either algorithm can be used in conjunction with the "h" tag in the "DomainKey-Signature:" header.
どちらのアルゴリズムも、「domainkey-signature：」ヘッダーの「h」タグと組み合わせて使用できます。
Canonicalization simply prepares the email for the signing or verification algorithm. It does not change the transmitted data in any way.
Canonicalizationは、署名または検証アルゴリズムのために電子メールを準備するだけです。送信されたデータは決して変更されません。
o Each line of the email is presented to the signing algorithm in the order it occurs in the complete email, from the first line of the headers to the last line of the body.
o メールの各行は、ヘッダーの最初の行からボディの最後の行まで、完全な電子メールで発生する順序で署名アルゴリズムに表示されます。
o If the "h" tag is used, only those header lines (and their continuation lines if any) added to the "h" tag list are included.
o 「H」タグを使用する場合、「H」タグリストに追加されたヘッダーライン（およびそれらの継続ライン）のみが含まれています。
o The "h" tag only constrains header lines. It has no bearing on body lines, which are always included.
o 「H」タグはヘッダーラインのみを制約します。常に含まれているボディラインには関係ありません。
o Remove any local line terminator.
o ローカルラインターミネーターを削除します。
o Append CRLF to the resulting line.
o 結果のラインにCRLFを追加します。
o All trailing empty lines are ignored. An empty line is a line of zero length after removal of the local line terminator.
o すべての後続の空の線は無視されます。空の線は、ローカルラインターミネーターを除去した後の長さのゼロのラインです。
If the body consists entirely of empty lines, then the header/body line is similarly ignored.
ボディが完全に空の線で構成されている場合、ヘッダー/ボディラインも同様に無視されます。
The "No Folding Whitespace" algorithm (nofws) is more complicated than the "simple" algorithm for two reasons; folding whitespace is removed from all lines and header continuation lines are unwrapped.
「折りたたみ式のホワイトスペース」アルゴリズム（NOFWS）は、2つの理由で「単純な」アルゴリズムよりも複雑です。折り畳み式のホワイトスペースはすべてのラインから削除され、ヘッダーの継続ラインは包装されています。
o Each line of the email is presented to the signing algorithm in the order it occurs in the complete email, from the first line of the headers to the last line of the body.
o メールの各行は、ヘッダーの最初の行からボディの最後の行まで、完全な電子メールで発生する順序で署名アルゴリズムに表示されます。
o Header continuation lines are unwrapped so that header lines are processed as a single line.
o ヘッダーの継続ラインは、ヘッダーラインが単一のラインとして処理されるように包装されています。
o If the "h" tag is used, only those header lines (and their continuation lines if any) added to the "h" tag list are included.
o 「H」タグを使用する場合、「H」タグリストに追加されたヘッダーライン（およびそれらの継続ライン）のみが含まれています。
o The "h" tag only constrains header lines. It has no bearing on body lines, which are always included.
o 「H」タグはヘッダーラインのみを制約します。常に含まれているボディラインには関係ありません。
o For each line in the email, remove all folding whitespace characters. Folding whitespace is defined in RFC 2822 as being the decimal ASCII values 9 (HTAB), 10 (NL), 13 (CR), and 32 (SP).
o 電子メールの各行について、すべての折りたたみ式の白い文字を削除します。折りたたみホワイトスペースは、RFC 2822で、小数ASCII値9（HTAB）、10（NL）、13（CR）、および32（SP）として定義されています。
o Append CRLF to the resulting line.
o 結果のラインにCRLFを追加します。
o Trailing empty lines are ignored. An empty line is a line of zero length after removal of the local line terminator. Note that the test for an empty line occurs after removing all folding whitespace characters.
o 後続の空の線は無視されます。空の線は、ローカルラインターミネーターを除去した後の長さのゼロのラインです。空のラインのテストは、すべての折りたたみ式の空白文字を削除した後に発生することに注意してください。
If the body consists entirely of empty lines, then the header/body line is similarly ignored.
ボディが完全に空の線で構成されている場合、ヘッダー/ボディラインも同様に無視されます。
The previous sections defined the various components and mechanisms needed to sign an email. This section brings those together to define the complete process of signing an email.
前のセクションでは、電子メールに署名するために必要なさまざまなコンポーネントとメカニズムを定義しました。このセクションでは、それらをまとめて、電子メールに署名する完全なプロセスを定義します。
A signer MUST only sign email from submissions that are authorized to use the sending address.
署名者は、送信アドレスを使用することが許可されている提出物からの電子メールのみに署名する必要があります。
Once authorization of the submission has been determined, the signing process consists of the following steps:
提出の許可が決定されると、署名プロセスは次の手順で構成されています。
o identifying the sending domain
o 送信ドメインを識別します
o determining if an email should be signed
o 電子メールに署名するかどうかを判断します
o selecting a private key and corresponding selector information
o 秘密キーと対応するセレクター情報の選択
o calculating the signature value
o 署名値の計算
o prepending the "DomainKey-Signature:" header
o 「DomainKey-Signature：」ヘッダーの準備
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email.
何らかの理由で電子メールに署名できない場合、それはそのメールをどうするかについてのローカルポリシーの決定です。
The sending domain is determined by finding the email address in the "Sender:" header, or, if the "Sender:" header is not present, the first email address of the "From:" header is used to determine the sending domain.
送信ドメインは、「送信者：」にメールアドレスを見つけることによって決定されます。または、「送信者：」ヘッダーが存在しない場合、「from：」ヘッダーの最初の電子メールアドレスが送信ドメインを決定するために使用されます。
If the email has an invalid "From:" or an invalid "Sender:" header, it MUST NOT be signed.
電子メールに「from」または無効な」送信者が無効な場合： "ヘッダー、署名してはいけません。
If the signer adds the "h" tag to the "DomainKey-Signature:" header, that tag MUST include the header that was used to determine the sending domain.
署名者が「h」タグを「domainkey-signature：」ヘッダーに追加する場合、そのタグには、送信ドメインを決定するために使用されたヘッダーを含める必要があります。
A signer can obviously only sign email for domains for which it has a private key and the necessary knowledge of the corresponding public key and selector information, however there are a number of other reasons why a signer may choose not to sign an email.
署名者は、秘密鍵と対応する公開キーとセレクター情報の必要な知識を持っているドメインの電子メールのみにのみ署名できますが、署名者が電子メールに署名しないことを選択する他の多くの理由があります。
A signer MUST NOT sign an email if the email submission is not authorized to use the sending domain.
電子メールの送信が送信ドメインを使用することを許可されていない場合、署名者は電子メールに署名してはなりません。
A signer MUST NOT sign an email that already contains a "DomainKey-Signature:" header unless a "Sender:" header has been added that was not included in the original signature. The most obvious case where this occurs is with mailing lists.
署名者は、「domainkey-signature：」ヘッダーを既に含んでいる電子メールに署名してはなりません。これが発生する最も明白なケースは、メーリングリストの場合です。
A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.
署名者は、既存の「DomainKey-Signature：」ヘッダーを削除しないでください。
This specification does not define the basis by which a signer should choose which private key and selector information to use. Currently, all selectors are equal as far as this specification is concerned, so the decision should largely be a matter of administrative convenience.
この仕様は、署名者が使用する秘密キーとセレクターの情報を選択する根拠を定義するものではありません。現在、この仕様に関する限り、すべてのセレクターは等しいため、決定は主に管理上の利便性の問題である必要があります。
The signer MUST use one of the defined canonicalization algorithms to present the email to the signing algorithm. Canonicalization is only used to prepare the email for signing. It does not affect the transmitted email in any way.
署名者は、定義された正規化アルゴリズムの1つを使用して、署名アルゴリズムにメールを提示する必要があります。標準化は、署名用の電子メールを準備するためにのみ使用されます。送信された電子メールに決して影響しません。
To avoid possible ambiguity, a signing server may choose to remove any pre-existing "DomainKey-Status:" headers from the email prior to preparation for signing and transmission.
あいまいさの可能性を回避するために、署名サーバーは、既存の「DomainKey-Status：」を削除することを選択できます。
The final step in the signing process is that the signer MUST prepend the "DomainKey-Signature:" header prior to continuing with the process of transmitting the email.
署名プロセスの最後のステップは、署名者が電子メールを送信するプロセスを継続する前に、「Domainkey-Signature：」ヘッダーを準備する必要があることです。
While the disposition of inbound email is ultimately a matter for the receiving system, the introduction of authentication in email creates a need for the sender domain to indicate their signing policy and preferred disposition of unsigned email, in particular, whether a domain is participating in DomainKeys, whether it is testing, and whether it signs all outbound email.
インバウンド電子メールの処分は最終的に受信システムの問題ですが、電子メールに認証を導入すると、送信者ドメインが署名ポリシーと未署名の電子メール、特にドメインがドメインキーに参加しているかどうかを示す必要があります。、それがテストであるかどうか、そしてそれがすべてのアウトバウンド電子メールに署名するかどうか。
The sending domain policy is very simple and is expressed in the _domainkey TXT record in the DNS of the sending domain. For example, in the example.com domain, the record is called _domainkey.example.com.
送信ドメインポリシーは非常に単純で、送信ドメインのDNSの_DomainKey TXTレコードで表現されています。たとえば、example.comドメインでは、レコードは_domainkey.example.comと呼ばれます。
The contents of this TXT record are stored as tag=value pairs separated by semicolons, for example, as in the following:
このTXTレコードの内容は、たとえば、以下のように、セミコロンで区切られたタグ=値ペアとして保存されます。
_domainkey IN TXT "t=y; o=-; n=notes; r=emailAddress"
All tags are optional. The current valid tags are as follows:
すべてのタグはオプションです。現在の有効なタグは次のとおりです。
n = Notes that may be of interest to a human. No interpretation is made by any program.
n =人間にとって興味深いメモ。どのプログラムでも解釈は行われません。
o = Outbound Signing policy ("-" means that this domain signs all email; "~" is the default and means that this domain may sign some email with DomainKeys).
o =アウトバウンド署名ポリシー（ " - "は、このドメインがすべての電子メールに署名することを意味します。
r = A reporting email address. If present, this defines the email address where invalid verification results are reported. This tag is primarily intended for early implementers -- the content and frequency of the reports will be defined in a separate document.
R =レポートメールアドレス。存在する場合、これは無効な検証結果が報告されているメールアドレスを定義します。このタグは主に初期の実装者向けです。レポートの内容と頻度は、別のドキュメントで定義されます。
t = a set of flags that define boolean attributes. Valid attributes are as follows:
T =ブール属性を定義するフラグのセット。有効な属性は次のとおりです。
y = testing mode. This domain is testing DomainKeys, and unverified email MUST NOT be treated differently from verified email. Recipient systems MAY wish to track testing mode results to assist the sender).
y =テストモード。このドメインはドメインキーをテストしており、未検証の電子メールを検証された電子メールとは異なる方法で扱う必要はありません。受信者システムは、送信者を支援するためにテストモードの結果を追跡したい場合があります）。
Note that testing mode cannot be turned off by this tag; thus, policy cannot revert the testing mode setting of a Selector.
このタグでは、テストモードをオフにすることはできないことに注意してください。したがって、ポリシーはセレクターのテストモード設定を元に戻すことができません。
This tag is optional.
このタグはオプションです。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（タグの構文ルール=値形式については、付録Aで説明します。）
Recipient systems SHOULD only retrieve this policy TXT record to determine policy when an email fails to verify or does not include a signature. Recipient systems SHOULD not retrieve this policy TXT record for email that successfully verifies. Note that "testing mode" SHOULD also be in the Selector TXT record if the domain owner is running a DomainKeys test.
受信者システムは、このポリシーTXTレコードを取得して、電子メールが署名を確認できない、または署名を含めていない場合にのみポリシーを決定する必要があります。受信者システムは、このポリシーTXTレコードを正常に検証する電子メールで取得してはなりません。ドメインの所有者がドメインキーテストを実行している場合、「テストモード」もセレクターTXTレコードにある必要があることに注意してください。
If the policy TXT record does not exist, recipient systems MUST assume the default values.
ポリシーTXTレコードが存在しない場合、受信者システムはデフォルト値を想定する必要があります。
There is an important implication when a domain states that it signs all email with the "o=-" setting, namely that the sending domain prefers that the recipient system treat unsigned mail with a great deal of suspicion. Such suspicion could reasonably extend to rejecting such email. A verifying system MAY reject unverified email if a domain policy indicates that it signs all email.
ドメインが「O = - 」の設定にすべての電子メールに署名すること、つまり送信ドメインがレシピエントシステムが符号なしのメールを大量の疑いで扱うことを好むことをドメインが述べている場合、重要な意味があります。そのような疑いは、そのような電子メールを拒否することに合理的に拡張される可能性があります。検証システムは、ドメインポリシーがすべての電子メールに署名することを示している場合、未検証の電子メールを拒否する場合があります。
Of course, nothing compels a recipient MTA to abide by the policy of the sender. In fact, during the trial, a sending domain would want to be very certain about setting this policy, as processing by recipient MTAs may be unpredictable. Nonetheless, a domain that states that it signs all email MUST expect that unverified email may be rejected by some receiving MTAs.
もちろん、受信者MTAが送信者のポリシーを順守することを強いるものはありません。実際、試験中、受信者によるMTAによる処理は予測不可能である可能性があるため、送信ドメインはこのポリシーの設定について非常に確実にしたいと考えています。それにもかかわらず、すべての電子メールに署名することを示すドメインは、未検証の電子メールが一部のMTAによって拒否される可能性があることを期待する必要があります。
There is no defined or recommended limit on the lifetime of a selector and corresponding public key; however, it is recommended that verification occur in a timely manner with the most timely place being during acceptance or local delivery by the MTA.
セレクターと対応する公開キーの寿命に定義または推奨制限はありません。ただし、MTAによる受け入れまたは現地配信中に最もタイムリーな場所であるため、検証がタイムリーに行われることをお勧めします。
Verifying a signature consists of the following three steps:
署名の確認は、次の3つのステップで構成されています。
o extract signature information from the headers
o ヘッダーから署名情報を抽出します
o retrieve the public key based on the signature information
o 署名情報に基づいて公開キーを取得します
o check that the signature verifies against the contents
o 署名がコンテンツに対して検証されていることを確認してください
In the event that any of these steps fails, the sending domain policy is ascertained to assist in applying local policy.
これらの手順のいずれかが失敗した場合、ローカルポリシーの適用を支援するために、送信ドメインポリシーが確認されます。
Indications from deployment of previous versions of this specification suggest that the canonicalization algorithms in conjunction with the "h" tag in the "DomainKey-Signature:" header allows most email to cryptographically survive intact between signing and verifying.
この仕様の以前のバージョンの展開からの適応は、「domainkey-signature：」の「H」タグと組み合わせた標準化アルゴリズムが、署名と検証の間に暗号化されたほとんどの電子メールを暗号化することを可能にすることを示唆しています。
The one assumption that most of the early deployments make is that the headers included in the signature are not reordered prior to verification.
初期の展開のほとんどが行うという仮定の1つは、署名に含まれるヘッダーが検証の前に並べ替えられないことです。
While nothing in this specification precludes a verifier from "looking" for a header that may have been reordered, including being moved to a position prior to the "DomainKey-Signature:" header, such reordered email is unlikely to be successfully verified by most implementations.
この仕様の何も、「ドメインキーシグネチャー：」ヘッダーの前に位置に移動するなど、再注文されたヘッダーを「探している」ことを検証者に排除するものはありませんが、そのような並べ替えの電子メールは、ほとんどの実装によって正常に検証される可能性は低いでしょう。。
A second consequence of this assumption -- particularly in the presence of multiple "DomainKey-Signature:" headers -- is that the first "DomainKey-Signature:" header in the email was the last signature added to the email and thus is the one to be verified.
この仮定の2番目の結果 - 特に複数の「domainkey-signature： "headersが存在する場合 - 最初の「ドメインキーシグネチャ：」というメールのヘッダーは、電子メールに追加された最後の署名であり、したがって1つです。検証されます。
While the symptoms of a failed verification are obvious -- the signature doesn't verify -- establishing the exact cause can be more difficult. If a selector cannot be found, is that because the selector has been removed, or was the value changed somehow in transit? If the signature line is missing, is that because it was never there, or was it removed by an overzealous filter?
失敗した検証の症状は明らかです - 署名は検証しません - 正確な原因を確立することはより困難です。セレクターが見つからない場合、セレクターが削除されたのか、それとも輸送中に値が何らかの形で変更されたためですか？署名ラインが欠落している場合、それは決してそこになかったからですか、それとも熱心なフィルターによって削除されましたか？
For diagnostic purposes, the exact reason why the verification fails SHOULD be recorded; however, in terms of presentation to the end user, the result SHOULD be presented as a simple binary result: either the email is verified or it is not. If the email cannot be verified, then it SHOULD be rendered the same as all unverified email regardless of whether or not it looks like it was signed.
診断のために、検証が失敗する正確な理由を記録する必要があります。ただし、エンドユーザーへのプレゼンテーションの観点から、結果は単純なバイナリ結果として提示する必要があります。メールが検証されているか、そうではありません。電子メールを確認できない場合は、署名されたように見えるかどうかに関係なく、すべての未検証の電子メールと同じレンダリングされる必要があります。
In most cases, a signed email is expected to have just one signature -- that is, one "DomainKey-Signature:" header. However, it is entirely possible that an email can contain multiple signatures. In such cases, a verifier MUST find the most appropriate signature to use and SHOULD ignore all other signatures.
ほとんどの場合、署名された電子メールには、1つの署名、つまり1つの「DomainKey-Signature：」ヘッダーがあると予想されます。ただし、電子メールに複数の署名が含まれる可能性があります。そのような場合、検証者は使用するのに最も適切な署名を見つけ、他のすべての署名を無視する必要があります。
The process of finding the most appropriate signature consists of the following "best match" rules. The rules are to be evaluated in order.
最も適切な署名を見つけるプロセスは、次の「ベストマッチ」ルールで構成されています。ルールは順番に評価されます。
1. Selecting the sending domain
1. 送信ドメインの選択
If the email contains a "Sender:" header, the sending domain is extracted from the "Sender:" address. If this extraction fails, the email SHALL fail verification.
電子メールに「送信者：」が含まれている場合、送信ドメインは「送信者：」アドレスから抽出されます。この抽出が失敗した場合、電子メールは検証に失敗するものとします。
If no "Sender:" header is present, the sending domain is extracted from the first address of the "From:" header. If this extraction fails, the email SHALL fail verification.
「送信者：」ヘッダーが存在しない場合、送信ドメインは「from：」ヘッダーの最初のアドレスから抽出されます。この抽出が失敗した場合、電子メールは検証に失敗するものとします。
2. Domain matching
2. ドメインマッチング
A signature can only match if the sending domain matches the "d" tag domain -- according to the "d" tag subdomain matching rules.
署名は、送信ドメインが「d」タグドメインと一致する場合にのみ一致します - 「D」タグサブドメインマッチングルールに従って。
3. "h" tag matching
3. 「H」タグマッチング
If the signature contains the "h" tag list of headers, that list must include the header used to extract the sending domain in rule 1, above.
署名にヘッダーの「H」タグリストが含まれている場合、そのリストには、上記のルール1で送信ドメインを抽出するために使用されるヘッダーを含める必要があります。
4. Most secure signing algorithm
4. 最も安全な署名アルゴリズム
While it is not yet the case, in the event that additional algorithms are added to this specification, a verifier MUST use the signature that contains the most secure algorithm as defined by the future specification. For current implementations, that means verifiers MUST ignore signatures that are coded with an unrecognized signing algorithm.
まだそうではありませんが、この仕様に追加のアルゴリズムが追加された場合、検証者は将来の仕様で定義されている最も安全なアルゴリズムを含む署名を使用する必要があります。現在の実装では、認識者が認識されていない署名アルゴリズムでコーディングされた署名を無視する必要があることを意味します。
5. Earlier signatures are preferred
5. 以前の署名が推奨されます
If multiple signatures are equal as far as these rules apply, the signature from the earlier header MUST be used in preference to later signature headers.
これらのルールが適用される限り、複数の署名が等しい場合、以前のヘッダーからの署名は、後の署名ヘッダーよりも優先して使用する必要があります。
Implementors MUST meticulously validate the format and values in the "DomainKey-Signature:" header; any inconsistency or unexpected values MUST result in ignoring that header. Being "liberal in what you accept" is definitely a bad strategy in this security context.
実装者は、「domainkey-signature：」ヘッダーの形式と値を細心の注意を払って検証する必要があります。矛盾または予期しない値は、そのヘッダーを無視することにつながる必要があります。「あなたが受け入れるものにおけるリベラル」であることは、このセキュリティの文脈において間違いなく悪い戦略です。
In all cases, if a verification fails, the "DomainKey-Status:" header SHOULD be generated and include a message to help explain the reason for failure.
すべての場合において、検証が失敗した場合、「domainkey-status：」ヘッダーを生成し、障害の理由を説明するのに役立つメッセージを含める必要があります。
The public key is needed to complete the verification process. The process of retrieving the public key depends on the query type as defined by the "q" tag in the "DomainKey-Signature:" header line. Obviously, a public key should only be retrieved if the process of extracting the signature information is completely successful.
検証プロセスを完了するには、公開鍵が必要です。公開キーを取得するプロセスは、「domainkey-signature：」ヘッダーラインの「q」タグで定義されているクエリタイプに依存します。明らかに、署名情報を抽出するプロセスが完全に成功した場合にのみ、公開キーを取得する必要があります。
Currently, the only valid query type is "dns". The public key retrieval process for this type is as follows:
現在、唯一の有効なクエリタイプは「DNS」です。このタイプの公開キー検索プロセスは次のとおりです。
1. Using the selector name defined by the "s" tag, the "_domainkey" namespace and the domain name defined by the "d" tag, construct and issue the DNS TXT record query string.
1. 「s」タグ、「_domainkey」名前空間で定義されたセレクター名、および「d」タグで定義されたドメイン名を使用して、DNS TXTレコードクエリ文字列を構築し、発行します。
For example, if s=brisbane and d=example.net, the query string is "brisbane._domainkey.example.net".
たとえば、s = brisbaneおよびd = example.netの場合、クエリ文字列は「brisbane._domainkey.example.net」です。
2. If the query for the public key fails to respond, the verifier SHOULD defer acceptance of this email (normally this will be achieved with a 4XX SMTP response code).
2. 公開キーのクエリが応答できない場合、検証者はこのメールの受け入れを延期する必要があります（通常、これは4xx SMTP応答コードで達成されます）。
3. If the query for the public key fails because the corresponding data does not exist, the verifier MUST treat the email as unverified.
3. 対応するデータが存在しないために公開キーのクエリが失敗した場合、検証者は電子メールを未検証のように扱う必要があります。
4. If the result returned from the query does not adhere to the format defined in this specification, the verifier MUST treat the email as unverified.
4. クエリから返された結果がこの仕様で定義されている形式に付着していない場合、検証者は電子メールを未検証のように扱う必要があります。
5. If the public key data is not suitable for use with the algorithm type defined by the "a" tag in the "DomainKey-Signature:" header, the verifier MUST treat the email as unverified.
5. 公開キーデータが「domainkey-signature：」の「a」タグで定義されたアルゴリズムタイプでの使用に適していない場合、ヘッダー、検証者は電子メールを未確認として扱う必要があります。
Implementors MUST meticulously validate the format and values returned by the public key query. Any inconsistency or unexpected values MUST result in an unverified email. Being "liberal in what you accept" is definitely a bad strategy in this security context.
実装者は、公開キーのクエリによって返される形式と値を細心の注意を払って検証する必要があります。一貫性のない値または予期しない値は、未検証の電子メールにつながる必要があります。「あなたが受け入れるものにおけるリベラル」であることは、このセキュリティの文脈において間違いなく悪い戦略です。
Latency critical implementations may wish to initiate the public key query in parallel with calculating the SHA-1 hash, as the public key is not needed until the final RSA is calculated.
最終的なRSAが計算されるまで公開キーは必要ないため、Latencyの重要な実装は、SHA-1ハッシュの計算と並行して公開キークエリを開始することをお勧めします。
Armed with the signature information from the "DomainKey-Signature:" header and the public key information returned by the query, the signature of the email can now be verified.
「domainkey-signature：」の署名情報を装備して、ヘッダーとクエリによって返された公開キー情報では、電子メールの署名を検証することができます。
The canonicalization algorithm defined by the "c" tag in the "DomainKey-Signature:" header defines how the data is prepared for the verification algorithm, and the "a" tag in the same header defines which verification algorithm to use.
「DomainKey-Signature：」の「C」タグによって定義された正規化アルゴリズムは、検証アルゴリズムのデータの準備方法を定義し、同じヘッダーの「A」タグは、使用する検証アルゴリズムを定義します。
In the event that an email fails to verify, the policy of the sending domain MUST be consulted. For now, that means consulting the _domainkey TXT record in the DNS of the domain in the sending domain as defined in Section 3.5.1. For example, if example.net is the sending domain the TXT query is:
電子メールが確認に失敗した場合、送信ドメインのポリシーを参照する必要があります。今のところ、セクション3.5.1で定義されているように、送信ドメインのDNSに_DomainKey TXTレコードに相談することを意味します。たとえば、exple.netが送信ドメインである場合、txtクエリは次のとおりです。
_domainkey.example.net
_domainkey.example.net
A verifier SHOULD consider the sending domain policy statement and act accordingly. The range of possibilities is up to the receiver, but it MAY include rejecting the email.
検証者は、送信ドメインポリシーステートメントを考慮し、それに応じて行動する必要があります。可能性の範囲はレシーバー次第ですが、電子メールの拒否が含まれる場合があります。
After all verification processes are complete, the recipient system has authentication information that can help it decide what to do with the email.
すべての検証プロセスが完了した後、受信者システムには認証情報があり、電子メールで何をすべきかを決定するのに役立ちます。
It is beyond the scope of this specification to describe what actions a recipient system should take, but an authenticated email presents an opportunity to a receiving system that unauthenticated email cannot. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation.
この仕様の範囲は、受信者システムがどのようなアクションをとるべきかを説明することですが、認証された電子メールは、認識されていない電子メールができない受信システムに機会を提供します。具体的には、認証された電子メールは、信頼や評判など、他の決定を確実に管理できる予測可能な識別子を作成します。
Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation. It is not unreasonable to treat unauthenticated email as lacking any trust and having no positive reputation.
逆に、認識されていない電子メールには、信頼と評判を割り当てるために使用できる信頼できる識別子がありません。認識されていないメールを信頼を欠いており、肯定的な評判がないものとして扱うことは不合理ではありません。
Apart from the application of automated policy, the result of a signature verification should be conveyed to the user reading the email.
自動化されたポリシーの適用とは別に、署名検証の結果は、電子メールを読んでいるユーザーに伝える必要があります。
Most email clients can be configured to recognize specific headers and apply simple rules, e.g., filing into a particular folder. Since DomainKey signatures are expected to be initially verified at the border MTA, the results of the verification need to be conveyed to the email client. This is done with the "DomainKey-Status:" header line prepended to the email.
ほとんどの電子メールクライアントは、特定のヘッダーを認識し、特定のフォルダーにファイリングする簡単なルールを適用するように構成できます。Domainkey署名は最初にBorder MTAで検証されると予想されるため、検証の結果を電子メールクライアントに伝える必要があります。これは、「domainkey-status：」というヘッダーラインで行われます。
The "DomainKey-Status:" header starts with a string that indicate the result of the verification. Valid values are as follows:
「domainkey-status：」ヘッダーは、検証の結果を示す文字列から始まります。有効な値は次のとおりです。
"good" - the signature was verified at the time of testing "bad" - the signature failed the verification "no key" - the public key query failed as the key does not exist "revoked" - the public key query failed as the key has been revoked "no signature" - this email has no "DomainKey-Signature:" header "bad format" - the signature or the public key contains unexpected data "non-participant" - this sending domain has indicated that it does not participate in DomainKeys
「良い」 - 署名は「悪い」テスト時に検証されました - 署名は検証「キー」に失敗しました - キーが「取り消された」鍵が存在しないために公開キーのクエリは失敗しました - 公開キーのクエリはキーとして失敗しました「署名なし」に取り消されました - この電子メールには「ドメインキーシグネチャ：「ヘッダー」バッドフォーマット」 - 署名または公開キーには、予期しないデータが含まれています。ドメインキー
Verifiers may append additional data that expands on the reason for the particular status value.
Verifiersは、特定のステータス値の理由で拡張する追加のデータを追加する場合があります。
A client SHOULD just look for "good" and assume that all other values imply that the verification could not be performed for some reason. Policy action as a consequence of this header is entirely a local matter.
クライアントは「良い」を探すだけで、他のすべての値が何らかの理由で検証を実行できなかったことを暗示する必要があります。このヘッダーの結果としての政策措置は、完全にローカルな問題です。
Here are some examples:
ここではいくつかの例を示します。
DomainKey-Status: good DomainKey-Status: bad format
domainkey-status：Good domainkey-status：悪い形式
Although it is expected that MTAs will be DomainKey aware before MUAs, it is nonetheless possible that a DomainKey-aware MUA can be fooled by a spoofed "DomainKey-Status:" header that passes through a non-DomainKey-aware MTA.
MTAはMUASの前にドメインキーに気付くことが予想されますが、それでもドメインキーに認識されたMUAがスプーフィングされた「ドメインキーステータス：「非ドメインキーが認識しているMTA」を通過するヘッダーにだまされる可能性があります。
If this is perceived to be a serious problem, then it may make sense to preclude the "good" value and only have values that effectively demote the email as far as the UA is concerned. That way successful spoofing attempts can only serve to demote themselves.
これが深刻な問題であると認識されている場合、「良い」値を排除することは理にかなっており、UAが関係する限り、電子メールを効果的に降格させる値のみを持っているかもしれません。そうすれば、成功したスプーフィングの試みは、自分自身を降格するのに役立ちます。
This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together.
このセクションでは、送信から最終配信への電子メールの完全な流れを示し、さまざまなコンポーネントがどのように適合するかを示します。
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.
ジョー。
This email is signed by the football.example.com outbound email server and now looks like this:
このメールはFootball.example.com Outbound Email Serverによって署名されていますが、今は次のようになります。
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.football.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.
ジョー。
The signing email server requires access to the private key associated with the "brisbane" selector to generate this signature. Distribution and management of private keys are outside the scope of this document.
署名電子メールサーバーには、この署名を生成するために「ブリスベン」セレクターに関連付けられている秘密鍵へのアクセスが必要です。プライベートキーの配布と管理は、このドキュメントの範囲外です。
The signature is normally verified by an inbound SMTP server or possibly the final delivery agent. However, intervening MTAs can also perform this verification if they choose to do so.
署名は通常、インバウンドSMTPサーバーまたは場合によっては最終配信エージェントによって検証されます。ただし、介在するMTAは、そうすることを選択した場合、この検証を実行することもできます。
The verification process uses the domain "football.example.com" extracted from the "From:" header and the selector "brisbane" from the "DomainKey-Signature:" header to form the DNS TXT query for:
検証プロセスでは、「domainkey-signature：」から「ヘッダーとセレクター」ブリスベン "から抽出されたドメイン「Football.example.com」を使用します。
brisbane._domainkey.football.example.com
brisbane._domainkey.football.example.com
Since there is no "h" tag in the "DomainKey-Signature:" header, signature verification starts with the line following the "DomainKey-Signature:" line. The email is canonically prepared for verifying with the "simple" method.
「domainkey-signature：」に「h」タグがないため、ヘッダー、署名検証は「domainkey-signature：」行に続く行から始まります。電子メールは、「単純な」メソッドで検証するために標準的に準備されています。
The result of the query and subsequent verification of the signature is stored in the "DomainKey-Status:" header line. After successful verification, the email looks like this:
クエリとその後の署名の検証の結果は、「domainkey-status：」ヘッダーラインに保存されます。検証が成功した後、メールは次のようになります。
DomainKey-Status: good
from=joe@football.example.com; domainkeys=pass
Received: from mout23.brisbane.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4]
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.
ジョー。
A fundamental aspect of DomainKeys is that public keys are generated and advertised by each domain at no additional cost. This accessibility markedly differs from traditional Public Key Infrastructures where there is typically a Certificate Authority (CA) who validates an applicant and issues a signed certificate -- containing their public key -- often for a recurring fee.
ドメインキーの基本的な側面は、パブリックキーが追加費用なしで各ドメインによって生成および宣伝されることです。このアクセシビリティは、通常、申請者を検証し、署名された証明書（公開鍵を含む）を発行する認証局（CA）が存在する従来の公開鍵インフラストラクチャと著しく異なります。
While CAs do impose costs, they also have the potential to provide additional value as part of their certification process. Consider financial institutions, public utilities, law enforcement agencies, and the like. In many cases, such entities justifiably need to discriminate themselves above and beyond the authentication that DomainKeys offers.
CASはコストを課しますが、認定プロセスの一部として追加の価値を提供する可能性もあります。金融機関、公益事業、法執行機関などを検討してください。多くの場合、そのようなエンティティは、Domainkeysが提供する認証を超えて自分自身を差別する必要があります。
Creating a link between DomainKeys and CA-issued certificates has the potential to access additional authentication mechanisms that are more authoritative than domain-owner-issued authentication. It is well beyond the scope of this specification to describe such authorities apart from defining how the linkage could be achieved with the "DomainKey-X509:" header.
ドメインキーとCA発行の証明書の間にリンクを作成するには、ドメイン所有者が発行する認証よりも権威ある追加の認証メカニズムにアクセスする可能性があります。この仕様の範囲をはるかに超えて、「domainkey-x509：」ヘッダーでリンケージをどのように達成できるかを定義することとは別に説明します。
The "DomainKey-X509:" header provides a link between the public key used to sign the email and the certificate issued by a CA.
「domainkey-x509：」ヘッダーは、電子メールに署名するために使用される公開鍵と、caによって発行された証明書の間にリンクを提供します。
The exact content, syntax, and semantics of this header are yet to be resolved. One possibility is that this header contains an encoding of the certificate issued by a CA. Another possibility is that this header contains a URL that points to a certificate issued by a CA.
このヘッダーの正確なコンテンツ、構文、およびセマンティクスはまだ解決されていません。1つの可能性は、このヘッダーにはCAによって発行された証明書のエンコードが含まれていることです。別の可能性は、このヘッダーには、CAによって発行された証明書を指すURLが含まれていることです。
In either case, this header can only be consulted if the signature verifies and MUST be part of the content signed by the corresponding "DomainKey-Signature:" header. Furthermore, it is likely that MUAs rather than MTAs will confirm that the link to the CA-issued certificate is valid. In part, this is because many MUAs already have built-in capabilities as a consequence of Secure/Multipurpose Internet Mail Extensions (S/MIME) [SMIME] and Secure Socket Layer (SSL) [SSL] support.
どちらの場合でも、このヘッダーは署名が検証されている場合にのみ相談することができ、対応する「DomainKey-Signature：」ヘッダーによって署名されたコンテンツの一部でなければなりません。さらに、MTAではなくMUASがCA発行証明書へのリンクが有効であることを確認する可能性があります。部分的には、これは、多くのMUAが、安全/多目的インターネットメールエクステンション（S/MIME）[SMIME]およびセキュアソケットレイヤー（SSL）[SSL]サポートの結果として、すでに組み込みの機能を備えているためです。
The proof of linkage is made by testing that the public key in the certificate matches the public key used to sign the email.
リンケージの証明は、証明書の公開鍵が電子メールに署名するために使用される公開鍵と一致することをテストすることによって行われます。
An example of an email containing the "DomainKey-X509:" header is:
「domainkey-x509：」を含む電子メールの例は次のとおりです。
DomainKey-Signature: a=rsa-sha1; s=statements;
d=largebank.example.com; c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
DomainKey-X509: https://ca.example.net/largebank.example.com
From: "Large Bank" <statements@largebank.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Statement for Account: 1234-5678
...
The format of the retrieved value from the URL is not yet defined, nor is the determination of valid CAs.
URLから取得された値の形式はまだ定義されておらず、有効なCAの決定も定義されていません。
The whole matter of linkage to CA-issued certificates is one aspect of DomainKeys that needs to be resolved with relevant CA's and certificate-issuing entities. The primary point is that a link is possible to a higher authority.
CA発行証明書とのリンケージの問題全体は、関連するCAおよび証明書発行エンティティで解決する必要があるドメインキーの1つの側面です。主なポイントは、より高い権限へのリンクが可能であるということです。
Selectors are at the heart of the flexibility of DomainKeys. A domain administrator is free to use a single DomainKey for all outbound mail. Alternatively, the domain administrator may use many DomainKeys differentiated by selector and assign each key to different servers.
セレクターは、ドメインキーの柔軟性の中心にあります。ドメイン管理者は、すべてのアウトバウンドメールに単一のドメインキーを無料で使用できます。または、ドメイン管理者は、セレクターによって区別された多くのドメインキーを使用して、各キーを異なるサーバーに割り当てることができます。
For example, a large outbound email farm might have a unique DomainKey for each server, and thus their DNS will advertise potentially hundreds of keys via their unique selectors.
たとえば、大規模なアウトバウンドメールファームには、各サーバーに一意のドメインキーがある場合があるため、DNSは一意のセレクターを介して潜在的に数百のキーを宣伝します。
Another example is a corporate email administrator who might generate a separate DomainKey for each regional office email server.
別の例は、各地域のオフィスメールサーバーに個別のドメインキーを生成する可能性のあるコーポレートメール管理者です。
In essence, selectors allow a domain owner to distribute authority to send on behalf of that domain. Combined with the ability to revoke by removal or Time to Live (TTL) expiration, a domain owner has coarse-grained control over the duration of the distributed authority.
本質的に、セレクターにより、ドメインの所有者がそのドメインに代わって送信する権限を配布することができます。ドメインの所有者は、除去または生きる時間（TTL）の有効期限を除去することで取り消す能力と組み合わせて、分散型の当局の期間を粗く制御します。
Selectors are particularly useful for domain owners who want to contract a third-party mailing system to send a particular set of mail. The domain owner can generate a special key pair and selector just for this mail-out. The domain owner has to provide the private key and selector to the third party for the life of the mail-out.
セレクターは、特定のメールを送信するためにサードパーティの郵送システムに契約したいドメイン所有者にとって特に便利です。ドメインの所有者は、このメールアウトのためだけに特別なキーペアとセレクターを生成できます。ドメインの所有者は、メールアウトの存続期間中、秘密鍵とセレクターを第三者に提供する必要があります。
However, as soon as the mail-out is completely delivered, the domain owner can revoke the public key by the simple expedient of removing the entry from the DNS.
ただし、メールアウトが完全に配信されるとすぐに、ドメインの所有者は、DNSからエントリを削除するという単純な手段によって公開キーを取り消すことができます。
It is an unfortunate fact that some email software routinely (and often unnecessarily) transforms email as it transits through the network. Such transformations conflict with the fundamental purpose of cryptographic signatures - to detect modifications.
一部の電子メールソフトウェアは、ネットワークを通過するときにメールを日常的に（そしてしばしば不必要に）変換するという残念な事実です。このような変換は、変更を検出するために、暗号化署名の基本的な目的と矛盾しています。
While two canonicalization algorithms are defined in this specification, the primary goal of "nofws" is to provide a transition path to "simple". With a mixture of "simple" and "nofws" email, a receiver can determine which systems are modifying email in ways that cause the signature to fail and thus provide feedback to the modifying system.
この仕様では2つの標準化アルゴリズムが定義されていますが、「nofws」の主な目標は、「単純」への移行パスを提供することです。「シンプル」と「nofws」電子メールが混在する場合、受信者は、どのシステムが署名を失敗させる方法で電子メールを変更し、したがって修正システムにフィードバックを提供しているかを決定できます。
Integrating existing Mailing List Managers (MLMs) into the DomainKeys authentication system is a complicated area, as the behavior of MLMs is highly variable. Essentially, there are two types of MLMs under consideration: those that modify email to such an extent that verification of the original content is not possible, and those that make minimal or no modifications to an email.
既存のメーリングリストマネージャー（MLMS）をDomainKeys認証システムに統合することは、MLMの動作が非常に可変であるため、複雑な領域です。基本的に、検討中のMLMには2つのタイプがあります。元のコンテンツの検証が不可能な範囲で電子メールを変更するものと、電子メールを最小限または変更しないものです。
MLMs that modify email in a way that causes verification to fail MUST prepend a "Sender:" header and SHOULD prepend a "List-ID:" header prior to signing for distribution to list recipients.
検証が失敗するように電子メールを変更するMLMSは、「送信者」をプレップする必要があります。
A participating SUBMISSION server can deduce the need to re-sign such an email by the presence of a "Sender:" or "List-ID:" header from an authorized submission.
参加している提出サーバーは、「送信者」または「list-id：」の存在により、そのような電子メールを再署名する必要性を推測できます。
MLMs that do not modify email in a way that causes verification to fail MAY perform the same actions as a modifying MLM.
検証が故障するように電子メールを変更しないMLMは、修正MLMと同じアクションを実行できます。
One scenario that presents a particular problem with any form of email authentication, including DomainKeys, is the roving user: a user who is obliged to use a third-party SUBMISSION service when unable to connect to the user's own SUBMISSION service. The classic example cited is a traveling salesperson being redirected to a hotel email server to send email.
ドメインキーを含むあらゆる形式の電子メール認証で特定の問題を提示する1つのシナリオは、ロービングユーザーです。ユーザー自身の提出サービスに接続できない場合、サードパーティの提出サービスを使用する義務があるユーザーです。引用されている古典的な例は、メールを送信するためにホテルの電子メールサーバーにリダイレクトされる旅行営業担当者です。
As far as DomainKeys is concerned, email of this nature clearly originates from an email server that does not have authority to send on behalf of the domain of the salesperson and is therefore indistinguishable from a forgery. While DomainKeys does not prescribe any specific action for such email, it is likely that over time, such email will be treated as second-class email.
Domainkeysに関する限り、この性質の電子メールは、営業担当者のドメインに代わって送信する権限がないため、偽造と区別できない電子メールサーバーに由来します。DomainKeysはそのような電子メールの特定のアクションを規定していませんが、時間の経過とともにそのような電子メールはセカンドクラスの電子メールとして扱われる可能性があります。
The typical solution offered to roving users is to submit email via an authorized server for their domain -- perhaps via a Virtual Private Network (VPN) or a web interface or even SMTP AUTH back to a SUBMISSION server.
ロービングユーザーに提供される典型的なソリューションは、おそらく仮想プライベートネットワーク（VPN）またはWebインターフェイス、さらにはSMTP AUTHを介して、ドメインの許可サーバーを介して電子メールを送信することです。
While these are perfectly acceptable solutions for many, they are not necessarily solutions that are available or possible for all such users.
これらは多くの人にとって完全に受け入れられるソリューションですが、そのようなすべてのユーザーが利用できる、または可能なソリューションではありません。
One possible way to address the needs of this contingent of potentially disenfranchised users is for the domain to issue per-user DomainKeys. Per-user DomainKeys are identified by a non-empty "g" tag value in the corresponding DNS record.
潜在的に権利を剥奪されたユーザーのこの条件のニーズに対処する1つの可能な方法は、ドメインがユーザーごとのドメインキーを発行することです。ユーザーごとのドメインキーは、対応するDNSレコードの空でない「G」タグ値によって識別されます。
DomainKeys is primarily a security mechanism. Its core purpose is to make claims about email authentication in a credible way. However, DomainKeys, like virtually all Internet applications, relies on the DNS, which has well-known security flaws [RFC3833].
While the DNS is currently insecure, it is expected that the security problems should and will be solved by DNS Security (DNSSEC) [DNSSEC], and all users of the DNS will reap the benefit of that work.
DNSは現在安全ではありませんが、セキュリティの問題はDNSセキュリティ（DNSSEC）[DNSSEC]によって解決されるべきであり、解決されることが予想され、DNSのすべてのユーザーはその作業の利益を享受します。
Secondly, the types of DNS attacks relevant to DomainKeys are very costly and are far less rewarding than DNS attacks on other Internet applications.
第二に、ドメインキーに関連するDNS攻撃のタイプは非常にコストがかかり、他のインターネットアプリケーションに対するDNS攻撃よりもはるかにやりがいがありません。
To systematically thwart the intent of DomainKeys, an attacker must conduct a very costly and very extensive attack on many parts of the DNS over an extended period. No one knows for sure how attackers will respond; however, the cost/benefit of conducting prolonged DNS attacks of this nature is expected to be uneconomical.
ドメインキーの意図を体系的に阻止するために、攻撃者は長期間にわたって非常に費用のかかる非常に広範な攻撃をDNSの多くの攻撃を行う必要があります。攻撃者がどのように反応するかを確信していません。ただし、この性質の長期にわたるDNS攻撃を実施するコスト/利益は、非経済的であると予想されます。
Finally, DomainKeys is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as GnuPG and S/MIME address those requirements.
最後に、ドメインキーは、信頼性を証明する「十分な」方法としてのみ意図されています。著者や内容について強力な暗号化された証拠を提供することを意図したものではありません。GNUPGやS/MIMEなどの他のテクノロジーは、これらの要件に対応しています。
A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching selector-based data, as well as fetching sending domain policy. Widespread deployment of DomainKeys will result in a significant increase in DNS queries to the claimed sending domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries.
DNSに関連する2番目のセキュリティの問題は、セレクターベースのデータを取得し、ドメインポリシーの送信を取得した結果として、DNSトラフィックの増加を中心に展開します。ドメインキーの広範な展開により、請求された送信ドメインに対してDNSクエリが大幅に増加します。大規模な偽造の場合、DNSサーバーはクエリが大幅に増加する可能性があります。
All public key systems require management of key pairs. Private keys in particular need to be securely distributed to each signing mail server and protected on those servers. For those familiar with SSL, the key management issues are similar to those of managing SSL certificates. Poor key management may result in unauthorized access to private keys, which in essence gives unauthorized access to your identity.
すべての公開キーシステムには、キーペアの管理が必要です。特に、プライベートキーは、各署名メールサーバーに安全に配布され、それらのサーバーで保護される必要があります。SSLに精通している人の場合、主要な管理問題はSSL証明書の管理の問題と似ています。キー管理が不十分な場合、プライベートキーへの不正アクセスが発生する可能性があります。
It is well recognized in cryptographic circles that many security failures are caused by poor implementations rather than poor algorithms. For example, early SSL implementations were vulnerable because the implementors used predictable "random numbers".
暗号化サークルでは、多くのセキュリティ障害は、アルゴリズムの低下ではなく、実装が不十分であることによって引き起こされることがよく認識されています。たとえば、実装者が予測可能な「乱数」を使用したため、初期のSSL実装は脆弱でした。
While some MTA software already supports various cryptographic techniques, such as TLS, many do not. This proposal introduces cryptographic requirements into MTA software that implies a much higher duty of care to manage the increased risk.
一部のMTAソフトウェアは、TLSなどのさまざまな暗号化技術をすでにサポートしていますが、多くはそうではありません。この提案は、リスクの増加を管理するためのはるかに高いケア義務を意味するMTAソフトウェアに暗号化要件を導入します。
There are numerous articles, books, courses, and consultants that help programming security applications. Potential implementors are strongly encouraged to avail themselves of all possible resources to ensure secure implementations.
セキュリティアプリケーションのプログラミングを支援する多くの記事、本、コース、コンサルタントがあります。潜在的な実装者は、安全な実装を確保するために、あらゆる可能なリソースを利用できるように強く奨励されています。
Some people believe that they can achieve anonymity by using an email forwarding service. While this has never been particularly true, as bounces, over-quota messages, vacation messages, and web bugs all conspire to expose IP addresses and domain names associated with the delivery path, the DNS queries that are required to verify DomainKeys signature can provide additional information to the sender.
一部の人々は、電子メール転送サービスを使用することで匿名性を達成できると信じています。これは特に真実ではありませんでしたが、バウンス、超過メッセージ、休暇メッセージ、およびWebバグはすべて共謀して配信パスに関連するIPアドレスとドメイン名を公開するために、ドメインキーの署名を確認するために必要なDNSクエリは追加を提供できます送信者への情報。
In particular, as mail is forwarded through the mail network, the DNS queries for the selector will typically identify the DNS cache used by the forwarding and delivery MTAs.
特に、メールはメールネットワークを介して転送されるため、セレクターのDNSクエリは通常、転送および配信MTAで使用されるDNSキャッシュを識別します。
Verifying a signature is computationally significant. Early indications are that a typical mail server can expect to increase CPU demands by 8-15 percent. While this increased demand is modest compared to other common mail processing costs -- such as Bayesian filtering -- any increase in resource requirements can make a denial-of-service attack more effective against a mail system.
署名の確認は計算上重要です。早期の兆候は、典型的なメールサーバーがCPUの需要を8〜15％増加させることを期待できることです。この需要の増加は、ベイジアンフィルタリングなど、他の一般的なメール処理コストと比較して控えめですが、リソース要件の増加は、メールシステムに対してサービス拒否攻撃をより効果的にする可能性があります。
A constraining factor of such attacks is that the net computational cost of verifying is bounded by the maximum key size allowed by this specification and is essentially linear to the rate at which mail is accepted by the verifying system. Consequently, the additional computational cost may augment a denial-of-service attack, but it does not add a non-linear component to such attacks.
このような攻撃の制約要因は、検証の正味計算コストが、この仕様によって許可された最大キーサイズによって制限され、検証システムによってメールが受け入れられるレートに対して本質的に線形であることです。その結果、追加の計算コストはサービス拒否攻撃を強化する可能性がありますが、そのような攻撃に非線形コンポーネントを追加しません。
The DomainKeys protocol was deployed as a trial to better understand the implications of deploying wide-scale cryptographic email authentication.
DomainKeysプロトコルは、幅広い暗号化電子メール認証を展開することの意味をよりよく理解するための試行として展開されました。
Open Source implementations were made available at various places, particularly Source Forge [SOURCEFORGE], which includes links to numerous implementations, both Open Source and commercial.
オープンソースの実装は、さまざまな場所、特にSource Forge [SourceForge]で利用可能になりました。これには、オープンソースとコマーシャルの両方の多数の実装へのリンクが含まれています。
The primary goals of the trial were to:
裁判の主な目標は次のとおりです。
o understand the operational implications of running a DNS-based public key system for email
o 電子メールのDNSベースの公開キーシステムを実行することの運用上の意味を理解する
o measure the effectiveness of the canonicalization algorithms
o 標準化アルゴリズムの有効性を測定します
o experiment with possible per-user key deployment models
o 可能なユーザーごとのキー展開モデルを実験します
o fully define the semantics of the "DomainKey-X509:" header
o 「domainkey-x509：」のセマンティクスを完全に定義するヘッダー
The DomainKeys trial ran for approximately 2 years, in which time numerous large ISPs and many thousands of smaller domains participated in signing or verifying with DomainKeys. The low order numbers are that at least one billion DomainKey signed emails transit the Internet each day between some 12,000 participating domains.
DomainKeysの試験は約2年間実行されましたが、その間に多数の大規模なISPと数千の小さなドメインがドメインキーとの署名または検証に参加しました。低い注文数は、少なくとも10億のドメインキー署名電子メールが毎日約12,000の参加ドメインの間にインターネットを通過することです。
The operational and development experience of that trial was applied to DKIM.
その試験の運用と開発の経験は、DKIMに適用されました。
The DNS is very flexible in that it is possible to have multiple TXT records for a single name and for those TXT records to contain multiple strings.
DNSは、単一の名前に複数のTXTレコードを使用し、それらのTXTレコードが複数の文字列を含むことができるという点で非常に柔軟です。
In all cases, implementors of DomainKeys should expect a single TXT record for any particular name. If multiple TXT records are returned, the implementation is free to pick any single TXT record as the authoritative data. In other words, if a name server returns different TXT records for the same name, it can expect unpredictable results.
すべての場合において、DomainKeysの実装者は、特定の名前の単一のTXTレコードを期待する必要があります。複数のTXTレコードが返された場合、実装は権威あるデータとして単一のTXTレコードを自由に選択できます。言い換えれば、名前サーバーが同じ名前の異なるTXTレコードを返す場合、予測不可能な結果が予想される可能性があります。
Within a single TXT record, implementors should concatenate multiple strings in the order presented and ignore string boundaries. Note that a number of popular DNS command-line tools render multiple strings as separately quoted strings, which can be misleading to a novice implementor.
単一のTXTレコード内で、実装者は提示された順序で複数の文字列を連結し、文字列の境界を無視する必要があります。多くの一般的なDNSコマンドラインツールは、個別に引用された文字列として複数の文字列をレンダリングすることに注意してください。これは初心者の実装者に誤解を招く可能性があります。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[Base64] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、2006年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PEM] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421 February, 1993.
[PEM] Linn、J。、「インターネット電子メールのプライバシー強化：パートI：メッセージ暗号化と認証手順」、RFC 1421 1993年2月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[Dkim] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J。、およびM. Thomas、「Domainkeys Idified Mail（DKIM）署名」、RFC 4871、2007年5月。
[DNSSEC] http://www.ietf.org/html.charters/dnsext-charter.html
[dnssec] http://www.ietf.org/html.charters/dnsext-charter.html
[OPENSSL] http://www.openssl.org
[openssl] http://www.openssl.org
[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、編集者、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[Smime] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[SOURCEFORGE] http://domainkeys.sourceforge.net
[SourceForge] http://domainkeys.sourceforge.net
[SSL] http://wp.netscape.com/security/techbriefs/ssl.html
[SSL] http://wp.netscape.com/security/techbriefs/ssl.html
Appendix A - Syntax Rules for the Tag=Value Format
付録A-タグの構文ルール=値形式
A simple tag=value syntax is used to encode data in the response values for DNS queries as well as headers embedded in emails. This section summarized the syntactic rules for this encoding:
Simple Tag = value構文を使用して、DNSクエリの応答値とメールに埋め込まれたヘッダーのデータをエンコードします。このセクションでは、このエンコードの構文規則を要約しました。
o A tag=value pair consists of three tokens, a "tag", the "=" character, and the "value"
o タグ=値ペアは、3つのトークン、「タグ」、「=」文字、および「値」で構成されています
o A tag MUST be one character long and MUST be a lowercase alphabetic character
o タグは1文字の長さでなければならず、小文字のアルファベット文字でなければなりません
o Duplicate tags are not allowed
o 重複したタグは許可されていません
o A value MUST only consist of characters that are valid in RFC 2822 headers and DNS TXT records and are within the ASCII range of characters from SPACE (0x20) to TILDE (0x7E) inclusive. Values MUST NOT contain a semicolon but they may contain "=" characters.
o 値は、RFC 2822ヘッダーとDNS TXTレコードで有効な文字のみで構成され、スペース（0x20）からTilde（0x7e）を含むASCIIの範囲内にある文字で構成されている必要があります。値にはセミコロンを含めてはなりませんが、「=」文字が含まれる場合があります。
o A tag=value pair MUST be terminated by a semicolon or the end of the data
o タグ=値ペアは、セミコロンまたはデータの終了によって終了する必要があります
o Values MUST be processed as case sensitive unless the specific tag description of semantics imply case insensitivity.
o セマンティクスの特定のタグの説明が症例の鈍感を意味しない限り、値はケースに敏感に処理する必要があります。
o Values MAY be zero bytes long
o 値はゼロバイトの長さである可能性があります
o Whitespace MAY surround any of the tokens; however, whitespace within a value MUST be retained unless explicitly excluded by the specific tag description. Currently, the only tags that specifically ignore embedded whitespace are the "b" and "h" tags in the "DomainKey-Signature:" header.
o ホワイトスペースは、トークンのいずれかを囲む場合があります。ただし、特定のタグの説明によって明示的に除外されない限り、値内のホワイトスペースは保持する必要があります。現在、埋め込まれた空白を明確に無視するタグは、「domainkey-signature：」ヘッダーの「b」と「h」タグです。
o Tag=value pairs that represent the default value MAY be included to aid legibility.
o タグ=デフォルト値を表す値ペアは、読みやすくするために含まれる場合があります。
o Unrecognized tags MUST be ignored
o 認識されていないタグを無視する必要があります
Acknowledgments
謝辞
The editor wishes to thank Russ Allbery, Eric Allman, Edwin Aoki, Claus Asmann, Steve Atkins, Jon Callas, Dave Crocker, Michael Cudahy, Jutta Degener, Timothy Der, Jim Fenton, Duncan Findlay, Phillip Hallam-Baker, Murray S. Kucherawy, John Levine, Miles Libbey, David Margrave, Justin Mason, David Mayne, Russell Nelson, Juan Altmayer Pizzorno, Blake Ramsdell, Scott Renfro, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Bradley Taylor, and Rand Wacker for their valuable suggestions and constructive criticism.
編集者は、Russ Allbery、Eric Allman、Edwin Aoki、Claus Asmann、Steve Atkins、Jon Callas、Dave Crocker、Michael Cudahy、Jutta Degener、Timothy Der、Jim Fenton、Duncan Findlay、Phillip Hallam-Bakerに感謝したいと考えています。、ジョン・レヴァイン、マイルズ・リビー、デビッド・マーグレイブ、ジャスティン・メイソン、デビッド・メイン、ラッセル・ネルソン、フアン・アルトマイヤー・ピッツォーノ、ブレイク・ラムズデル、スコット・レンフロ、スパムハウス・オルグチーム、マルテ・S・ストレッツ、ロバート・サンダース、ブラッドリー・テイラー、ランド・ワッカーのランド・ワッカーのためのランド・ワッカー彼らの貴重な提案と建設的な批判。
Author's Address
著者の連絡先
Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
マーク・デラニー・ヤフー！Inc 701 First Avenue Sunnyvale、CA 95087 USA
EMail: markd+domainkeys@yahoo-inc.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。