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)
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）IETFトラスト（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".
電子メールのアイデンティティの証明と保護は、「スパム」と「フィッシング」のグローバル制御を補助することができます。
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.
ほとんどの電子メール交換は、本質的にコンテキストを超えて認証を必要としませんが、それは「スパマー」、「フィッシング」、および証明必要になり、その犯罪の同類によってアイデンティティの横行乱用です。言い換えれば、認証が証拠として保護に関する限りです。
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.
送信者が自明任意のメールアドレスをとることができるので、重要なことは、できないことは、送信者へのインバウンド電子メールの処分の制御の多くの電子メールを効果的代表者を認証します。電子メール認証を作成すると、受信者に電子メールのdispositional制御を返すための最初のステップです。
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.
このドキュメントの目的のために、認証は、ユーザーの視点から見た、との質問に答えるために意図され、「このメールを送りました？」ここで、「誰が」受信者が見て、「このメールは、」受信者が見ているコンテンツである電子メールアドレスです。
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.
電子メールは、特定のドメインに由来すると主張すると、DomainKeysのは、受信側システムは、クレディブルメールが実際にそのドメインの電子メールを送信する権限を与えた人やシステムから発信なかったと判断することができる機構を提供します。
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とのこの基本定義は、主に、ドメインレベルの信頼性を可能にするためのものです。与えられたメッセージが本当にドメイン内の主張ユーザーが送信されているかどうかをベース定義の範囲外です。この仕様は、いくつかのドメインは、個々のユーザーにきめ細かい認証を委任することを望むかもしれないという可能性を含む、と述べました。
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を活用という点でのDomainKeysは、従来の階層型公開鍵システムとは異なります。それはあなたが特定のドメインのDNSを管理している場合、あなたはそのドメインのためのあなたのDomainKeysを管理している、です。
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は、公開鍵を公開するための最初のメカニズムとして提案されています。ドメインキーは、具体的には、それらが利用可能になった他のキーフェッチサービスに拡張できるように設計されています。
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:
実用上の理由から、DomainKeysの初期の実装は受け入れるか、行政や組織の境界を越えてメールを中継メール転送エージェント（MTA）に配備されることが期待されます。 ：を含む境界MTAでの展開に多くの利点があり、
o a reduction in the number of MTAs that have to be changed to support an implementation of DomainKeys
ドメインキーの実装をサポートするように変更されなければならないのMTAの数の減少O
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.
内部電子メールネットワーク内のDomainKeysを実装する必要がなくなり、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.
しかし、そこに署名など国境でのDomainKeysを展開する一切必要ありませんし、効果的に右の背中メールユーザエージェント（MUA）にどこでも国境MTAから発生する可能性があります検証します。特に、多くのドメインの電子メールに署名するのに最適な場所は、送信者が、多くの場合、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-状態：」ヘッダは、メールに認証結果を記録するために本明細書に定義されています。
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
本明細書の目的は、実装するためにDomainKeysの基本的な特性を通信することです。しかし、いくつかの側面は、opensslコマンドの機能は[OPENSSL]から派生して、というよりもそのドキュメントを複製し、実装されています
are expected to understand the mechanics of the openssl command, sufficient to complete the implementation.
実装を完了するのに十分な、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は、ライン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].
このドキュメントは時折大文字で現れる用語を使用しています。ときの用語は、「MUST」、「推奨」「SHOULD」、「NOT MUST」、「SHOULD NOT」、および大文字表示される「MAY」、彼らは、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は[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.
DomainKeysの下では、ドメインの所有者は、そのドメインから送信されたメッセージに署名するために使用される1または複数の公開鍵/秘密鍵のペアを生成します。ドメインの所有者は（すなわち、そのドメインに関連付けられているDNSレコードで）彼のドメイン名前空間内の公開鍵を配置し、アウトバウンド電子メールシステムに利用できる秘密鍵になります。メールがそのドメインの承認されたユーザーによって提出された場合、電子メールシステムは、デジタル送信ドメインに関連付けられた電子メールに署名する秘密鍵を使用しています。署名は、電子メールのヘッダとして追加され、メッセージは通常の方法で、その受信者に転送されます。
When a message is received with a DomainKey signature header, the receiving system can verify the signature as follows:
メッセージがDomainKey署名ヘッダで受信される場合、以下のように、受信システムは、署名を検証することができます。
1. Extract the signature and claimed sending domain from the email.
1.署名を抽出し、電子メールのドメインを送信すると主張しました。
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:
このセクションでは、相互運用可能な実装を作成するために必要とされているのDomainKeysの詳細について説明します。このセクションでは、以下の質問に答えます。
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.
これらの基準の遵守は、いくつかの既存の電子メールの実装はDomainKeysのに参加するために変更が必要になることを意味します。最終的には、いくつかのハードの選択肢がより重要である要件に関してなされる必要があります。
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.
[RFC2822]を対処：最初のインスタンスでは、最も目に見えるアドレスは明らか「から」RFC 2822です。ドメイン名と電子メールアドレスを抽出することが可能なヘッダ：したがって、適合の電子メールは、単一の「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.
「送信者：」と有効：電子メールは、「から」の有効なを持っている場合は、「送信者：」ヘッダヘッダは、その後、署名者はで、送信アドレスを使用する必要があります。
If the email has a valid "From:" and no "Sender:" header, then the signer MUST use the first sending address in the "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名前空間に格納されています。
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"
”こおぅｍべあｃｈ。＿どまいんけｙ。えぁｍｐぇ。ねｔ” ”せばｓとぽｌ。＿どまいんけｙ。えぁｍｐぇ。ねｔ” ”れｙｋじゃゔぃｋ。＿どまいんけｙ。えぁｍｐぇ。ねｔ” ”でふぁうｌｔ。＿どまいんけｙ。えぁｍｐぇ。ねｔ”
and
そして
"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.
行政利便性を超えて、セレクタがシームレスに定期的に公開鍵を交換することを可能にします。ドメインは、セレクタ「2006」に関連する公開鍵へのセレクタ「2005」に関連した公開鍵を使用してから変更したい場合は、それは単に電子メールは可能性がある時に、両方の公開鍵は、移行期間のために同時に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:
DomainKeysのに適した768ビットの秘密鍵を生成するための一つの方法は、次のように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これに似たキー情報を含むファイルrsa.privateになり768：
-----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
$ 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 + 54yvctqc4rSEFYby9 + omKD3pJ / TVxATeTz msybuW3WZiamb + mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz / 0lsl
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
$ 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
$ 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で公開鍵を格納するために定義された標準的な方法は現在ありません。暫定措置として、公開鍵はDER符号化されたキーをBase64表現として、つまり、プライバシー強化メール（PEM）形式[PEM]に由来するTXTレコードとして格納されています。ここで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"
TXT、IN brisbane._domainkey "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ビットのキーサイズをサポートしなければなりません。署名者は、検証、サポート、キーのサイズの少なくとも一つをサポートしなければなりません。
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.
グラム=キーの細かさ。非ゼロの長さの値を持つ存在する場合、この値は正確に送信アドレスのローカル部分と一致しなければなりません。このタグはオプションです。
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.
This tag is optional.
このタグはオプションです。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（タグ= valueの形式の構文規則は、付録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.
コンテンツとキャッシュDNSサーバのいくつかの実装は、大TXTレコードをサポートしている問題を有することが報告されているように、最小に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
2048ビットの鍵は512バイトのDNSのUDP応答パケット内に収まる最大の鍵である実用的な制約O
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-署名」に格納されます。このヘッダは、署名と鍵フェッチデータのすべてを含みます。
When generating the signed email, the "DomainKey-Signature:" header MUST precede the original email headers presented to the signature algorithm.
署名された電子メールの「DomainKey-署名：」生成時ヘッダは、署名アルゴリズムに提示元のメールヘッダに先行しなければなりません。
The "DomainKey-Signature:" header is not included in the signature calculation.
「DomainKey-署名：」ヘッダは、署名計算には含まれません。
For extensibility, the "DomainKey-Signature:" header contains tag=value pairs separated by semicolons, for example, as in the following:
拡張性のために、「DomainKey-署名：」ヘッダは、タグ=以下のように、例えば、セミコロンで区切られた値のペアが含まれています。
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net; q=dns; c=simple
DomainKey-署名：= RSA-SHA1。 S =ブリスベン。 D = example.net。 Q = DNS。 C =シンプル
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".
=署名を生成するために使用されるアルゴリズム。デフォルトでは、 "RSA-SHA1"、RSAは、SHA1ダイジェストに署名しています。署名者と検証者は、「RSA-SHA1」をサポートしなければなりません。
b = The signature data, encoded as a Base64 string. This tag MUST be present.
B = 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」をサポートしなければなりません。署名者は、検証者がサポートするアルゴリズムのうち少なくとも一つをサポートしなければなりません。
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.
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.
検証者は、このタグをサポートしなければなりません。署名者はこのタグをサポートしてもよい（MAY）。署名者は、このタグを生成する場合、それは検証者として、元の電子メールのすべての電子メールヘッダを含まなければなりません、署名に含まれていない行を削除または疑わしいレンダリングすることができます。
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-署名」ヘッダがこのリストに含まれている場合、検証者は、すべての後、そのヘッダの発生を含まなければなりません。
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-署名：」の後に検出されない場合、検証プロセスにおいてヘッダ、「DomainKey-署名：」前マッチングヘッダの「見える」ことができる検証ヘッダ。 「DomainKey-署名：」ヘッダをただし、署名者は、このように初期の経験に頼るべきではありませんが、ほとんどの検証が前に戻って「見える」しようとしないことを示唆しています。
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.)
（タグ= valueの形式の構文規則は、付録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ビットの電子メールと長い行を受け入れることを観察しているが、いくつかの実装はまだありません。これにより、電子メールを準備する必要がありDomainKeysの実装が署名に電子メールを提示する前に、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のは、最初に展開されると予想、または組織のではなく、のMUAやSUBMISSIONサーバでは、電子メールの国境に近接しています。電子メールは、パッケージ化transmogrified、一般的にインターネット上で送信のために準備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-署名：」ヘッダのいずれかのアルゴリズム中の「H」タグと組み合わせて使用することができます。
Canonicalization simply prepares the email for the signing or verification algorithm. It does not change the transmitted data in any way.
正規化は、単に署名や検証アルゴリズムのための電子メールを準備します。それはどのような方法で送信されるデータは変更されません。
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.
（存在する場合と、その継続行）「H」タグが使用される場合、のみヘッダ行O「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 Append CRLF to the resulting line.
得られたラインに追加CRLF O。
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）は、二つの理由から、「シンプル」アルゴリズムよりも複雑です。折り畳み空白がアンラップされているすべての行およびヘッダ継続行から除去されます。
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.
そのヘッダー行を1行として処理されるように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.
（存在する場合と、その継続行）「H」タグが使用される場合、のみヘッダ行O「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電子メールの各行について、すべての折りたたみ空白文字を削除してください。折り畳み空白は小数ASCII値9（HTAB）、10（NL）、13（CR）、及び32（SP）であるとしてRFC 2822に定義されています。
o Append CRLF to the resulting line.
得られたラインに追加CRLF O。
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-署名」を前置
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.
ヘッダ、または、もし「送信者：」ヘッダは、「から：」の最初の電子メールアドレスに存在しないヘッダが送信ドメインを決定するために使用される：送信ドメインは、「送信者」の電子メールアドレスを見つけることによって決定されます。
If the email has an invalid "From:" or an invalid "Sender:" header, it MUST NOT be signed.
または無効「送信者：」：電子メールは、「から」、無効がある場合は、ヘッダを、それが署名してはなりません。
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-署名：」ヘッダを、そのタグは、送信ドメインを決定するために使用されたヘッダを含まなければなりません。
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-署名：」ヘッダのない限り、「送信者：」ヘッダは、元の署名に含まれていなかったが追加されました。この問題が発生した最も明白な場合には、メーリングリストです。
A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.
ヘッダ：署名者は、既存の「DomainKey-署名」を削除しないでください。
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.
署名者は、署名アルゴリズムに電子メールを提示するために定義された正規化アルゴリズムのいずれかを使用しなければなりません。正規化は、唯一の署名に電子メールを調製するために使用されます。それはどのような方法で送信された電子メールには影響を与えません。
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-ステータス」を削除することもできます。
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-署名」を前置しなければならないことです。
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.
インバウンド電子メールの処分が最終的に受信システムの問題であるが、電子メールでの認証の導入は、ドメインがDomainKeysのに参加しているかどうかを、具体的には、自分の署名ポリシーと符号なしの電子メールの優先配置を示すために、送信者のドメインの必要性を作成します、それはテストであるかどうか、そしてそれは、すべての送信メールに署名するかどうか。
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"
TXT IN _domainkey "T = Y; O = - であり; n =ノート; 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 =アウトバウンド署名ポリシーが（ - ;「〜」デフォルトで、このドメインはDomainKeysのといくつかの電子メールに署名することができることを意味し、「」このドメインの兆しすべての電子メールがあることを意味します）。
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).
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.)
（タグ= valueの形式の構文規則は、付録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レコードを取得するべきではありません。ドメイン所有者がDomainKeysのテストを実行している場合は、「テストモード」もセレクター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.
送信ドメインが受信側システムは、疑いの多大なと符号なしのメールを扱うことを好むすなわちことを、設定 - ドメインは、それが「0 =」ですべての電子メールに署名することを述べたときに重要な意味があります。このような疑惑は、合理的な電子メールを拒否するに拡張することができ。ドメインポリシーが、それはすべての電子メールに署名することを示しているかどうかの検査システムは、未確認のメールを拒否することがあります。
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-署名：」ヘッダは、暗号署名と検証の間に無傷の生存にほとんどの電子メールを可能にする本明細書の以前のバージョンの配置からの指示がで「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.
「DomainKey-シグニチャー」は、本明細書では何も前の位置に移動されるなど、並べ替えされていてもよいヘッダは、「探して」から検証排除ないがヘッダを、そのような並べ替え電子メールが正常にほとんどの実装によって確認されにくいです。
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.
この仮定の第二結果 - 特に複数の存在下での「DomainKey-署名：」 - ：電子メールのヘッダが最後の署名は、電子メールに加え、このように一つであるヘッダは最初の「DomainKey-署名」することです検証します。
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.
ヘッダ：であり、一つの「DomainKey-署名」 - ほとんどの場合、署名された電子メールはちょうど1つのシグネチャを有することが期待されます。しかし、電子メールが複数の署名を含めることができるということは完全に可能です。このような場合、検証者は、使用する最も適切なシグネチャを見つける必要があり、他のすべての署名を無視するべきです。
The process of finding the most appropriate signature consists of the following "best match" rules. The rules are to be evaluated in order.
最も適切な署名を見つけるプロセスは、以下の「ベストマッチ」のルールで構成されています。ルールは順番に評価されます。
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.
NO「送信者：」場合：ヘッダヘッダが存在し、送信ドメインが「から」の最初のアドレスから抽出されます。この抽出に失敗した場合、電子メールは、検証に失敗しないものとします。
A signature can only match if the sending domain matches the "d" tag domain -- according to the "d" tag subdomain matching rules.
「D」タグサブドメインマッチング規則に従って - 送信元ドメインが「D」タグドメインと一致する場合、署名にのみ一致させることができます。
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に送信ドメインを抽出するために使用されるヘッダを含まなければなりません。
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.
それはまだそうではないが、付加的なアルゴリズムは、本明細書に追加された場合に、検証者は、将来の仕様によって定義されるような最も安全なアルゴリズムが含まれている署名を使用しなければなりません。現在の実装では、それは、検証者が認識できない署名アルゴリズムで符号化された署名を無視しなければならないことを意味します。
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-署名：」ヘッダを、任意の矛盾または予期しない値は、そのヘッダを無視をもたらさなければなりません。 「あなたが受け入れるものにリベラル」であることは間違いなく、このセキュリティコンテキストで悪い戦略です。
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-ステータス：」ヘッダが生成され、失敗の理由を説明するためにメッセージを含めるべきである（SHOULD）。
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-署名：」ヘッダ行公開鍵を取得する処理は、で「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 =ブリスベン、および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.
前記公開鍵データで「」タグによって定義されたアルゴリズムのタイプとの使用に適していない場合、「DomainKey-署名：」ヘッダ、検証者は未確認として電子メールを処理しなければなりません。
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が算出されるまでの公開鍵が必要とされないように、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-署名：」ヘッダと、クエリによって返された公開鍵情報、電子メールの署名が現在確認することができます。
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.
中の「C」タグによって定義された正規化アルゴリズム「DomainKey-署名：」ヘッダは、データが検証アルゴリズムのために調製し、そして同一のヘッダに「」タグを使用するかを検証アルゴリズム定義される方法を定義します。
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レコードをコンサルティングを意味します。たとえば、example.netが送信ドメインの場合はTXTクエリは次のとおりです。
_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署名が最初に境界MTAで確認することが期待されているので、検証の結果は、電子メールクライアントに伝達する必要があります。電子メールの先頭に付加ヘッダ行：これは「DomainKey-ステータス」で行われます。
The "DomainKey-Status:" header starts with a string that indicate the result of the verification. Valid values are as follows:
「DomainKey-ステータス：」ヘッダは、検証の結果を示す文字列で始まります。有効な値は次のとおりです：
"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
「良い」 - 署名は、テストの時に確認された「悪い」 - 署名検証「どのキー」失敗しない - 鍵は「取り消し」は存在しないと公開鍵のクエリに失敗しました - 公開鍵問合せは、キーとして失敗しました「何の署名」を取り消されていない - このメールには、「DomainKey-署名：」持っていない - 署名や公開鍵は、予期しないデータが含まれている「非参加者」 - ヘッダー「悪い形式を」この送信ドメインが、それは参加しないことが示されましたDomainKeysの
Verifiers may append additional data that expands on the reason for the particular status value.
検証者は、特定のステータス値の理由を拡張し、追加のデータを追加します。
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-ステータス：良いDomainKey-ステータス：悪いフォーマット
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.
ヘッダ非DomainKey認識MTAを通過する：MTAがのMUA前に注意してくださいDomainKeyなることが予想されるが、DomainKey対応のMUAが偽装された「DomainKey-ステータス」にだまされてはいけできるということにもかかわらず可能です。
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>
From： "ジョーアメリカ人男性" <joe@football.example.com>へ： "スージーQ" <suzie@shopping.example.net>件名：夕食の準備ができていますか？日付：金、2003年7月11日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アウトバウンド電子メールサーバーによって署名され、現在は以下のように見えます。
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:
ヘッダおよびセレクタ「ブリスベン」：検証プロセス「はfootball.example.com」の「From」から抽出されたドメインを使用して「DomainKey-シグニチャー」のDNS TXTクエリを形成するヘッダ。
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-署名：」には「H」のタグが存在しないため、「DomainKey-署名：」行ヘッダは、署名検証は、次の行で始まります。電子メールは、「簡単な」方法で検証する正準用意があります。
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-状態」に格納されます。検証が成功した後、電子メールは次のようになります。
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.
CAは、コストを課すんが、彼らはまた、彼らの認証プロセスの一環として、付加価値を提供する可能性を持っています。金融機関、公益事業、法執行機関などを考慮してください。多くの場合、そのような実体は正当上との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.
正確な内容、構文、このヘッダの意味はまだ解決されるべきです。一つの可能性は、このヘッダは、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-署名」によって署名されたコンテンツの一部である必要がある場合はいずれの場合も、このヘッダのみを参照することができます。さらに、のMUAではなく、MTAはCA発行の証明書へのリンクが有効であることを確認する可能性があります。多くのMUAがすでに内蔵されているため、機能/セキュア多目的インターネットメール拡張（S / MIME）[SMIME]とのSecure Socket Layer（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のと証明書発行エンティティと解決する必要にDomainKeysの一の態様です。主なポイントは、リンクがより高い当局に可能であるということです。
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.
セレクタは、DomainKeysとの柔軟性の心臓部です。ドメイン管理者は、すべての送信メール用の単一DomainKeyを使用して自由です。代替的に、ドメイン管理者は、セレクタによって区別多くのドメインキーを使用して、異なるサーバーに各キーを割り当てることができます。
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.
たとえば、大規模なアウトバウンド電子メールファームは、サーバごとにユニークなDomainKeyがあるかもしれないので、そのDNSは、独自のセレクタを経由して、潜在的にキーの数百人をアドバタイズします。
Another example is a corporate email administrator who might generate a separate DomainKey for each regional office email server.
別の例では、各地域のオフィスの電子メールサーバー用に別のDomainKeyを生成する可能性があり、企業の電子メール管理者です。
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.
MLMの挙動は非常に可変であるようにドメインキー認証システムに既存のメーリングリストマネージャ（の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.
検証が失敗した方法で電子メールを変更のMLMは、「送信者：」先頭に追加しなければならないヘッダをし、「リスト-ID：」先頭に追加すべきである前に受信者をリストに配布するための署名にヘッダを。
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.
または「リスト-ID：」認可申請からヘッダー：参加SUBMISSIONサーバは、「送信者」の存在によって再署名、電子メールへの必要性を推測することができます。
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）またはバックSUBMISSIONサーバへの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.
ドメインは、ユーザーごとにDomainKeysを発行するために潜在的に権利を奪われ、ユーザーのこの偶発のニーズに対処するための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].
DomainKeysのは、主にセキュリティメカニズムです。そのコアの目的は、信頼性の高い方法で電子メール認証についての主張を作ることです。しかし、DomainKeysのは、事実上すべてのインターネットアプリケーションのように、よく知られたセキュリティ上の欠陥[RFC3833]を持っているDNSに依存しています。
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.
第二に、DomainKeysのに関連する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.
体系的にDomainKeysの意図を阻止するために、攻撃者が長期間にわたって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.
最後に、DomainKeysのが唯一の信憑性を証明する「十分な」方法として意図されています。著作者や内容についての強力な暗号証拠を提供するものではありません。このよう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トラフィックを中心に展開します。 DomainKeysとの広範な展開が主張送信ドメインへの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アドレスとドメイン名を公開するために共謀し、DomainKeysの署名を検証するために必要とされる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.
署名を検証することは、計算上重要です。初期の兆候は、一般的なメールサーバが8から15パーセントによってCPUの需要を高めることが期待できるということです。ベイジアンフィルタリングなど - - この需要の増加が他の一般的なメール処理コストに比べて控えめですが、リソース要件の増加は、メールシステムに対するサービス拒否攻撃をより効果的にすることができます。
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.
オープンソースの実装は、様々な場所、多数の実装、オープンソースと商用の両方へのリンクが含まれ、特にソースフォージ[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の裁判は、小さなドメインの多数の大規模ISPや多くの何千もの署名やDomainKeysのを確認することに参加した時に、約2年間のために走りました。低次数は、少なくとも10億DomainKeyは、いくつかの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でデータエンコーディング"、RFC 4648、2006年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]リン、J.、 "インターネット電子メールのためのプライバシー増進：パートI：メッセージの暗号化と認証手順"、RFC 1421 2月、1993。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキー・アイデンティファイド・メール（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]レズニック、P.、エディタ、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、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.、エド。、 "/セキュア多目的インターネットメール拡張（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:
シンプルタグ=値構文は電子メールに埋め込まれた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レコードに有効であり、包括チルド（0x7Eを）に対してSPACE（0x20の）から文字の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-署名：」ヘッダ現在、具体的に埋め込まれた空白を無視するだけでタグが「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.
エディタはラスAllbery、エリック・オールマン、エドウィン・青木、クラウスAsmann、スティーブ・アトキンス、ジョン・カラス、デイブ・クロッカー、マイケル・カダヒー、ユッタ・デッジナー、ティモシー・デア、ジム・フェントン、ダンカンフィンドレー、フィリップハラム - ベイカー、マレーS. Kucherawyに感謝したいです、ジョン・レヴァイン、マイルリビー、デビッド辺境伯、ジャスティン・メイソン、デイビット・メイン、ラッセル・ネルソン、フアンAltmayer Pizzorno、ブレイクRamsdell、スコット・レンフロ、Spamhaus.orgチーム、マルテS. Stretz、ロバート・サンダース、ブラッドリー・テイラー、そしてランドワッカーについて彼らの貴重な提案と建設的な批判。
Author's Address
著者のアドレス
Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
マーク・ディレイニーのYahoo!株式会社701まずアベニューサニーベール、CA 95087 USA
EMail: markd+domainkeys@yahoo-inc.com
メールアドレス：markd+domainkeys@yahoo-inc.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。