RFC4870 日本語訳
4870 Domain-Based Email Authentication Using Public Keys Advertised inthe DNS (DomainKeys). M. Delany. May 2007. (Format: TXT=87378 bytes) (Obsoleted by RFC4871) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Delany Request for Comments: 4870 Yahoo! Inc Obsoleted By: 4871 May 2007 Category: Historic
コメントを求めるワーキンググループM.ディラニー要求をネットワークでつないでください: 以下によって時代遅れにされた4870Yahoo!Inc 4871 2007年5月のカテゴリ: 歴史的
Domain-Based Email Authentication Using Public Keys
Advertised in the DNS (DomainKeys)
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.
このメモはインターネットコミュニティのためにHistoric Documentを定義します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
公開鍵技術とDNSを使用するのによるメールがメールの起源とコンテンツを立証するように、「DomainKeys」はドメインレベル認証枠組みを作成します。
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.
このドキュメントは、1ドメインあたり1個のベースに関するメールにデジタルにサインするために枠組みを定義します。 この枠組みの究極の目標は、明確にそれが今日知られているようにインターネットメールの意味論を保有している間、アイデンティティを立証して、保護することです。
Proof and protection of email identity may assist in the global control of "spam" and "phishing".
メールのアイデンティティの証拠と保護は「スパム」と「フィッシング詐欺」のグローバルなコントロールを助けるかもしれません。
Delany Historic [Page 1] RFC 4870 DomainKeys May 2007
[1ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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
1. 序論…3 1.1. 認証の不足はダメージが大きいインターネットメールです…3 1.2. メールにデジタルにサインすると、確かなドメイン認証は作成されます…4 1.3. DNSの公開鍵…4 1.4. 初期の展開は境界MTAでありそうです…5 1.5. 検証結果をMUAsに伝えます…5 1.6. 技術的な詳細は完全にカバーされているというわけではありません…5 1.7. 動機…6 1.8. DomainKeysの利益…6 1.9. 定義…7 1.10. 要件記法…8 2. DomainKeys概観…8 3. DomainKeysは視点を詳しく述べました…8 3.1. メールの送付アドレスを決定します…9 3.2. 送付ドメインを考えて、公開鍵を検索します…10 3.2.1. 「セレクタ」を導入します…10 3.2.2. 公開鍵調印と検証アルゴリズム…11 3.2.3. DNSの公開鍵Representation…13 3.2.4. 主要なサイズ…14 3.3. メールヘッダーに署名を格納します…15 3.4. トランジットと調印のためのメールの準備…17 3.4.1. トランジットのための準備…18 3.4.2. 調印のためのCanonicalization…18 3.4.2.1. 「簡単な」Canonicalizationアルゴリズム…19 3.4.2.2. "nofws"Canonicalizationアルゴリズム…19 3.5. サインアップ過程…20 3.5.1. 送付ドメインを特定します…20 3.5.2. メールがサインされるべきであるかどうか決定します…21 3.5.3. 秘密鍵と対応するセレクタ情報を選択します…21 3.5.4. 署名値について計算します…21 3.5.5. Prependingする、「DomainKey-署名:」 ヘッダー…21 3.6. 送付ドメインの施政方針…22 3.7. 検証の過程…23 3.7.1. 推定、そのHeaders Are Not Reordered…24 3.7.2. 検証は2進の結果をレンダリングするべきです…24 3.7.3. 最も好個を選択する、「DomainKey-署名:」 ヘッダー…24 3.7.4. 署名情報に基づく公開鍵を検索してください…26 3.7.5. 署名について確かめてください…27 3.7.6. 送付ドメイン方針を検索します…27 3.7.7. ローカルの方針を適用します…27 3.8. 検証結果をMUAsに伝えます…27
Delany Historic [Page 2] RFC 4870 DomainKeys May 2007
[2ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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
4. 使用に関する例…29 4.1. ユーザはメールを構成します…29 4.2. メールはサインされます…29 4.3. メール署名は確かめられます…30 5. 認証局との協会…31 5.1. 「DomainKey-X509:」 ヘッダー…31 6. 議論のための話題…32 6.1. セレクタの利益…32 6.2. メールのCanonicalization…33 6.3. メーリングリスト…33 6.4. ユーザを流浪させます…33 7. セキュリティ問題…34 7.1. DNS…34 7.1.1. DNSは現在、安全ではありません…34 7.1.2. DomainKeysは追加DNS荷重を作成します…35 7.2. 主要な管理…35 7.3. 実現リスク…35 7.4. フォーワーディング・アドレスとのプライバシー仮定…35 7.5. 暗号の処理は計算上徹底的です…36 8. トライアル…36 8.1. 目標…36 8.2. トライアルの結果…37 9. TXTを見なすのが記録することに作成者に注意してください…37 10. 参照…37 10.1. 標準の参照…37 10.2. 有益な参照…38 付録A--タグのためのシンタックス・ルールは値の形式と等しいです…39の承認…40
1. Introduction
1. 序論
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仕様はDomainKeys Identifiedメール[DKIM]仕様が引き出された一次資料でした。 DKIM仕様の前に書かれた配備された実現に関する歴史上の記述としてこのドキュメントを提出することにおける目的があります。
1.1. Lack of Authentication Is Damaging Internet Email
1.1. 認証の不足はダメージが大きいインターネットメールです。
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.
メールの認証は現在、広範囲ではありません。 単にあなた自身のアイデンティティを立証するのが難しいのではなく、他のものがあなたのアイデンティティを乱用するのを防ぐのは不可能です。
Delany Historic [Page 3] RFC 4870 DomainKeys May 2007
[3ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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.
重要に、認証する無能は有効に送付者への本国行きのメールの気質のコントロールの多くを代表にメールします、送付者がどんなEメールアドレスも些細なことに仮定できるので。 メール認証を作成するのは、メールの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.
このドキュメントの目的のために、認証は、ユーザ見解から見られて、「だれがこのメールを送りましたか?」という受取人が、Eメールアドレスが「だれ」であるかと見て、「このメール」が受取人が見る内容である質問に答えることを意図します。
1.2. Digitally Signing Email Creates Credible Domain Authentication
1.2. メールにデジタルにサインすると、確かなドメイン認証は作成されます。
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のこのベース定義が主としてドメインレベルの信憑性を可能にすることを意図します。 ベース定義の範囲の外に与えられたメッセージが本当にドメインの中の主張されたユーザによって送られるかどうかがあります。 それを言ったので、この仕様はいくつかのドメインがきめ細かに粒状の認証を個々のユーザへ代表として派遣したがっているかもしれない可能性を含んでいます。
1.3. Public Keys in the DNS
1.3. DNSの公開鍵
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
DomainKeysはそれのそれがキー生成と管理の公開鍵管理、完全な状態で入賞して、および直轄のためのDNSに投機する伝統的な階層的な公開鍵システムと異なっています。
Delany Historic [Page 4] RFC 4870 DomainKeys May 2007
[4ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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を管理します。
The DNS is proposed as the initial mechanism for publishing public keys. DomainKeys is specifically designed to be extensible to other key-fetching services as they become available.
DNSは出版公開鍵のための初期のメカニズムとして提案されます。 DomainKeysは、利用可能になるので他の主要に魅惑的なサービスに広げることができるように明確に設計されています。
1.4. Initial Deployment Is Likely at the Border MTA
1.4. 初期の展開は境界MTAでありそうです。
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の初期の実現が管理の、または、組織的な境界の向こう側に受け入れるメール配達エージェント(MTAs)かリレーメールで配備されると予想されます。 である:展開の多数の利点が境界MTAにあります。
o a reduction in the number of MTAs that have to be changed to
support an implementation of DomainKeys
o DomainKeysの実現を支持するために変えられなければならないMTAsの数の減少
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 その結果、コンテンツへの偶然の変更を行うことができる場所について調印システムと検証システム、数を減らすことの間のメールを伝えるのにかかわるMTAsの数の減少
o removing the need to implement DomainKeys within an internal
email network.
o 内部のメールネットワークの中でDomainKeysを実行する必要性を取り除きます。
However, there is no necessity to deploy DomainKeys at the border as signing and verifying can effectively occur anywhere from the border MTA right back to the Mail User Agent (MUA). In particular, the best place to sign an email for many domains is likely to be at the point of SUBMISSION where the sender is often authenticated through SMTP AUTH or other identifying mechanisms.
しかしながら、事実上、調印と検証がどこでも境界MTAからまさしくメール・ユーザー・エージェント(MUA)まで起こることができるように境界でDomainKeysを配備する必要は全くありません。 特に、多くのドメインのためのメールにサインする最も良い場所が送付者がメカニズムを特定しながらSMTP AUTHを通してしばしば認証されているか、または他であるSUBMISSIONの先にありそうです。
1.5. Conveying Verification Results to MUAs
1.5. 検証結果をMUAsに伝えます。
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-状態:」 ヘッダーは認証結果をメールに記録するためのこの仕様に基づき定義されます。
1.6. Technical Minutiae Are Not Completely Covered
1.6. 技術的な詳細は完全にカバーされているというわけではありません。
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]の機能性からいくつかの局面が派生する、むしろ、そのドキュメンテーション、作成者をコピーします。
Delany Historic [Page 5] RFC 4870 DomainKeys May 2007
[5ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
are expected to understand the mechanics of the openssl command, sufficient to complete the implementation.
実現を終了できるくらいのopensslコマンドの整備士を理解していると予想されます。
1.7. Motivation
1.7. 動機
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がそれより強い真実性声明を出すのを含意するために本書では提供された情報を誤解しないように注意しているべきです。
1.8. Benefits of DomainKeys
1.8. 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などの強い認証システムは包括的な認可システム、評判システム、および彼らの一族が発展できる疑いようのない枠組みを作成します。
Delany Historic [Page 6] RFC 4870 DomainKeys May 2007
[6ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
1.9. Definitions
1.9. 定義
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
線データ番号バイト内容---- --- -------------------------------------------- 01 46、From: 「ジョーSixPack、「 <joe@football.example.com 、gt;、02 40、To:、」 「スージーQ、「 <suzie@shopping.example.net 、gt;、03 25、Subject:、」 夕食は準備ができていますか? 04 43、日付: 金曜日に、2003年7月11日21:00:37 -0700(太平洋夏時間の)の05 40はコメントします: このコメントには、この線が折りたたみの余白07 60Message-IDと共に始まるので、継続06 51があります: <20030712040037.46341@football.example.com>08 00 09 03、こんにちは。 10 00 11 37、私たちはゲームに負けました。 あなたはもう、空腹ですか? 12 00 13 04、ジョー。 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より遅れています。
Delany Historic [Page 7] RFC 4870 DomainKeys May 2007
[7ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
1.10. Requirements Notation
1.10. 要件記法
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」と「推薦した」とき「」 「5月」は大文字で書かれるように見えて、それらは、この仕様の特定の要件を示すのに使用されるべきです。 これらの用語の意味の議論は[RFC2119]に現れます。
2. DomainKeys Overview
2. DomainKeys概観
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. メールから署名と要求された送付ドメインを抽出してください。
2. Fetch the public key from the claimed sending domain namespace.
2. 要求された送付ドメイン名前空間から公開鍵をとって来てください。
3. Use public key to determine whether the signature of the email
has been generated with the corresponding private key, and thus
whether the email was sent with the authority of the claimed
sending domain.
3. 公開鍵を使用して、メールの署名が対応する秘密鍵で発生するかどうかと、その結果、メールが要求された送付ドメインの権威と共に送られたかどうか決定してください。
In the event that an email arrives without a signature or when the signature verification fails, the receiving system retrieves the policy of the claimed sending domain to ascertain the preferred disposition of such email.
メールが署名なしで到着するか、または署名照合が失敗すると、受電方式はそのようなメールの都合のよい気質を確かめる要求された送付ドメインの方針を検索します。
Armed with this information, the recipient system can apply local policy based on the results of the signature test.
この情報で武装していて、受取人システムは署名テストの結果に基づくローカルの方針を当てはまることができます。
3. DomainKeys Detailed View
3. DomainKeysの詳細な視点
This section discusses the specifics of DomainKeys that are needed to create interoperable implementations. This section answers the following questions:
このセクションは共同利用できる実現を作成するのが必要であるDomainKeysの詳細について論じます。 このセクションは以下の質問に答えます:
Delany Historic [Page 8] RFC 4870 DomainKeys May 2007
[8ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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?
最終的に、メールの信憑性について確かめるとき、参加するのに伝えられたその結果はどのようにMUAsですか?
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に参加するために釣り銭がいるのを含意します。 結局、いくつかの厳しい選択が、どちらの要件が、より重要であるかに関して作られている必要があります。
3.1. Determining the Sending Address of an Email
3.1. メールの送付アドレスを決定します。
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「From:」です。 [RFC2822]を記述してください。 したがって、従うメールは単一の「From:」を含まなければなりません。 ドメイン名があるEメールアドレスを抜粋できるヘッダー。
Delany Historic [Page 9] RFC 4870 DomainKeys May 2007
[9ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
A conforming email MAY contain a single RFC 2822 "Sender:" header from which an email address with a domain name can be extracted.
従うメールが独身のRFC2822を含むかもしれない、「送付者:」 ドメイン名があるEメールアドレスを抜粋できるヘッダー。
If the email has a valid "From:" and a valid "Sender:" header, then the signer MUST use the sending address in the "Sender:" header.
メールに有効な「From:」があるなら a有効である、「送付者:」 ヘッダー、次に、署名者が中で送付アドレスを使用しなければならない、「送付者:」 ヘッダー。
If the email has a valid "From:" and no "Sender:" header, then the signer MUST use the first sending address in the "From:" header.
メールに有効な「From:」があるなら いいえ、「送付者:」 ヘッダー、そして、署名者は「From:」における最初の送付アドレスを使用しなければなりません。 ヘッダー。
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.
他のすべての場合では、署名者はメールにサインしてはいけません。 作成者がそれに注意するべきである、aがあるメール、「送付者:」 ヘッダーにもかかわらず、「From:」がありません。 ヘッダーにサインしてはいけません。
The domain name in the sending address constitutes the "sending domain".
送付アドレスのドメイン名は「送付ドメイン」を構成します。
3.2. Retrieving the Public Key Given the Sending Domain
3.2. 送付ドメインを考えて、公開鍵を検索します。
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名前空間に格納されます。
3.2.1. Introducing "selectors"
3.2.1. 「セレクタ」を導入します。
To support multiple concurrent public keys per sending domain, the DNS namespace is further subdivided with "selectors". Selectors are arbitrary names below the "_domainkey." namespace. A selector value and length MUST be legal in the DNS namespace and in email headers with the additional provision that they cannot contain a semicolon.
複数の送付ドメインあたりの同時発生の公開鍵を支持するために、DNS名前空間は「セレクタ」でさらに細分されます。 「セレクタが以下の任意の名前である、」 _domainkey」 名前空間。 セレクタ値と長さは、DNS名前空間で法的であり、追加支給がある彼らがそうすることができないメールヘッダーにセミコロンを含まなければなりません。
Examples of namespaces using selectors are as follows:
セレクタを使用する名前空間の例は以下の通りです:
"coolumbeach._domainkey.example.net"
"sebastopol._domainkey.example.net"
"reykjavik._domainkey.example.net"
"default._domainkey.example.net"
「coolumbeach_domainkey.example.net、」 「sebastopol_domainkey.example.net」が「. _domainkey.example.netをreykjavikする」、「デフォルト_domainkey.example.net」
and
そして
"2005.pao._domainkey.example.net"
"2005.sql._domainkey.example.net"
"2005.rhv._domainkey.example.net"
「2005.pao._domainkey.example.net」「2005.sql._domainkey.example.net」「2005.rhv._domainkey.example.net」
Periods are allowed in selectors and are to be treated as component separators. In the case of DNS queries, that means the period defines subdomain boundaries.
期間は、セレクタに許容されていて、コンポーネント分離符として扱われることです。 DNS質問の場合では、それは、期間がサブドメイン限界を定義することを意味します。
Delany Historic [Page 10] RFC 4870 DomainKeys May 2007
[10ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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.
各ドメインへの公開鍵と対応するセレクタの数はドメイン所有者によって測定されます。 行政上分配された組織は、異なった領域、または、異なったEメールサーバの上で異種のセレクタと主要な組を経営するのを選ぶかもしれませんが、多くのドメイン所有者がちょうど1個のセレクタに満足するでしょう。
Beyond administrative convenience, selectors make it possible to seamlessly replace public keys on a routine basis. If a domain wishes to change from using a public key associated with selector "2005" to a public key associated with selector "2006", it merely makes sure that both public keys are advertised in the DNS concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the "2006" private key. At the end of the transition period, the "2005" public key is removed from the DNS.
管理便利を超えて、セレクタで継ぎ目なく普段から公開鍵を交換するのは可能になります。 ドメインであるなら、公開鍵を使用するので変化するという願望は公開鍵への「2005」がセレクタ「2006」に関連づけたセレクタと交際して、それは、両方の公開鍵がメールが検証の前にトランジット中であるかもしれない過渡期のために同時にDNSに広告を出すのを単に確実にします。 過渡期の始めでは、外国行きのEメールサーバは、「2006」秘密鍵と契約するために構成されます。 過渡期の終わりでは、DNSから「2005」公開鍵を取り除きます。
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.
いくつかのドメインがセレクタ値をよく明らかにしたがっているかもしれない間、他のものは、外部のパーティーでデータを取り入れる方法でセレクタ名を割り当てないように注意したくなるでしょう。 例えば、1ユーザあたりのキーが支給されると、ドメイン所有者は、このセレクタが直接ユーザ名と交際するか、またはそれをいくつかにするのを作るのが無作為の値を非連想したかどうかに関して決定をする必要があるでしょう、公開鍵の指紋などのように。
3.2.2. Public Key Signing and Verification Algorithm
3.2.2. 公開鍵調印と検証アルゴリズム
The default signature is an RSA signed SHA1 digest of the complete email.
デフォルト署名はサインされたSHA1が読みこなす完全なメールのRSAです。
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ビットの秘密鍵を発生させる1つの方法はこのようにopensslを使用することです:
$ openssl genrsa -out rsa.private 768
openssl genrsaの出ているrsa.private768ドル
Delany Historic [Page 11] RFC 4870 DomainKeys May 2007
[11ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
which results in the file rsa.private containing the key information similar to this:
これと同様の主要な情報を含むファイルrsa.privateのどの結果:
-----BEGIN RSA PRIVATE KEY----- MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= -----END RSA PRIVATE KEY-----
-----RSA秘密鍵を始めてください。----- MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/; -----終わりのRSA秘密鍵-----
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サイン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コネrsa.privateアウト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-----
-----公開鍵を始めてください。----- MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB-----終わりの公開鍵-----
This public key data is placed in the DNS.
この公開鍵データはDNSに置かれます。
Delany Historic [Page 12] RFC 4870 DomainKeys May 2007
[12ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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はrsa.public -sha1署名sig.file<input.fileについて確かめます。
3.2.3. Public key Representation in the DNS
3.2.3. DNSの公開鍵Representation
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に公開鍵を格納するために定義された標準方法が全くありません。 臨時措置として、TXT記録がPrivacyによって高められたメール(PEM)から形式を引き出したので[PEM]、公開鍵は格納されます、すなわち、DERのBase64表現がキーをコード化したので。 ここに、PEMフォームで主要な768ビットのRSAに関する例があります:
-----BEGIN PUBLIC KEY----- MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB -----END PUBLIC KEY-----
-----公開鍵を始めてください。----- MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB-----終わりの公開鍵-----
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ラッピングを取り除かなければなりません、そして、例えば、タグ=値組が以下のようにセミコロンで分離したので、DomainKeysの機能性に関連している他の属性に伴う残っている公開鍵データを格納します:
brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
brisbane_domainkey IN TXT「g=」。 k=rsa。 p=MHww… "IDAQAB"
Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048 bits. Signers MUST support at least one of the verifier supported key sizes.
検証は512、768、1024、1536、および2048ビットの主要なサイズを支持しなければなりません。 署名者は少なくとも検証の支持された主要なサイズの1つを支持しなければなりません。
The current valid tags are as follows:
現在の有効なタグは以下の通りです:
g = granularity of the key. If present with a non-zero length
value, this value MUST exactly match the local part of the
sending address. This tag is optional.
gはキーの粒状と等しいです。 非ゼロ・レングス値について存在しているなら、この値はまさに送付アドレスの地方の部分に合わなければなりません。 このタグは任意です。
The intent of this tag is to constrain which sending address
can legitimately use this selector. An email with a sending
address that does not match the value of this tag constitutes
a failed verification.
このタグの意図はどの送付アドレスを抑制するかが合法的にこのセレクタを使用できるということです。 このタグの値に合っていない送付アドレスがあるメールは失敗した検証を構成します。
k = key type (rsa is the default). Signers and verifiers MUST
support the 'rsa' key type. This tag is optional.
kは主要なタイプと等しいです(rsaはデフォルトです)。 署名者と検証は'rsa'主要なタイプを支持しなければなりません。 このタグは任意です。
Delany Historic [Page 13] RFC 4870 DomainKeys May 2007
[13ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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は論理演算子属性を定義する1セットの旗と等しいです。 有効な属性は以下の通りです:
y = testing mode. This domain is testing DomainKeys and
unverified email MUST NOT be treated differently from
verified email. Recipient systems MAY wish to track
testing mode results to assist the sender.
yはテストモードと等しいです。 このドメインはDomainKeysをテストしています、そして、非検証されたメールは確かめられたメールと異なって扱われてはいけません。 送付者を補助するためにモード結果をテストして、受取人システムは追跡したがっているかもしれません。
This tag is optional.
このタグは任意です。
(Syntax rules for the tag=value format are discussed in Appendix A.)
(Appendix A.で値のタグ=形式のためのシンタックス・ルールについて議論します)
Keeping the size of the TXT record to a minimum is important as some implementations of content and caching DNS servers are reported to have problems supporting large TXT records. In the example above, the encoding generates a 182-byte TXT record. That this encoding is less than 512 bytes is of particular significance as it fits within a single UDP response packet. With careful selection of query values, a TXT record can accommodate a 2048 bit key.
TXT記録のサイズを最小に抑えるのは内容のいくつかの実現として重要です、そして、DNSをキャッシュして、サーバには大きいTXT記録を支持することにおける問題があると報告されます。 例では、上では、コード化が182バイトのTXT記録を発生させます。 このコード化が512バイト未満であることは単一のUDP応答パケットの中で合うように特定の意味のものです。 質問値の厳選によって、TXT記録は2048年のビットのキーを収容できます。
For the same size restriction reason, the "n" tag SHOULD be used sparingly. The most likely use of this tag is to convey a reason why a public key might have been revoked. In this case, set the "n" tag to the explanation and remove the public key value from the "p" tag.
同じサイズのために、制限理由、「n」はSHOULDにタグ付けをします。控えめに使用されます。 このタグの最もありそうな使用は公開鍵が取り消されたかもしれない理由を伝えることです。 この場合、「n」タグを説明に設定してください、そして、「p」タグから公開鍵値を移してください。
3.2.4. Key Sizes
3.2.4. 主要なサイズ
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. This specification does not define either minimum or maximum key sizes -- that decision is a matter for each domain owner.
適切な主要なサイズを選択するのは、費用と、性能と、リスクの間のトレードオフです。 この仕様は最小の、または、最大の主要なサイズを定義しません--その決定はそれぞれのドメイン所有者のための問題です。
Factors that should influence this decision include the following:
この決定に影響を及ぼすべきである要素が以下を含んでいます:
o the practical constraint that a 2048-bit key is the largest key
that fits within a 512-byte DNS UDP response packet
o 2048年のビットのキーが512バイトのDNS UDP応答パケットの中で合う最も大きいキーであるという実用的な規制
o larger keys impose higher CPU costs to verify and sign email
o より大きいキーは、メールを確かめて、サインするために、より高いCPUコストを課します。
o keys can be replaced on a regular basis; thus, their lifetime
can be relatively short
o 定期的にキーを取り替えることができます。 したがって、彼らの寿命は比較的短い場合があります。
Delany Historic [Page 14] RFC 4870 DomainKeys May 2007
[14ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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ビットほど大きくないキーを使用すると予想されます。
3.3. Storing the Signature in the Email Header
3.3. メールヘッダーに署名を格納します。
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-署名: a=rsa-sha1。 s=brisbane。 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"、サインされたSHA1が読みこなすRSA」です。 署名者と検証は"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はCanonicalizationアルゴリズムと等しいです。 方法はヘッダーと内容がどれであるかで調印アルゴリズムにプレゼンテーションの用意をしました。 このタグは存在していなければなりません。 検証は「簡単」、そして、"nofws"を支持しなければなりません。 署名者は少なくとも検証で支持されたアルゴリズムの1つを支持しなければなりません。
Delany Historic [Page 15] RFC 4870 DomainKeys May 2007
[15ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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は調印ドメインのドメイン名と等しいです。 このタグは存在していなければなりません。 セレクタタグに関連して、このドメインは公開鍵質問の基礎を形成します。 このタグの値は、送付Eメールアドレスのドメインを合わせなければならないか、送付Eメールアドレスの親ドメインの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.
このタグのためのマッチング過程はサブドメインマッチングと呼ばれます、送付Eメールアドレスが価値に関するドメインかサブドメインであるに違いないので。
h = A colon-separated list of header field names that identify the
headers presented to the signing algorithm. If present, the
value MUST contain the complete list of headers in the order
presented to the signing algorithm.
調印アルゴリズムに紹介されたヘッダーを特定するヘッダーフィールド名のコロンで切り離されたh=リスト。 存在しているなら、値は調印アルゴリズムに提示されたオーダーにヘッダーに関する全リストを含まなければなりません。
If present, this tag MUST include the header that was used to
identify the sending domain, i.e., the "From:" or "Sender:"
header; thus, this tag can never contain an empty value.
存在しているなら、このタグはすなわち、送付ドメイン、「From:」を特定するのに使用されたヘッダーを含まなければなりません。 または、「送付者:」 ヘッダー。 したがって、このタグは空の値を決して含むことができません。
If this tag is not present, all headers subsequent to the
signature header are included in the order found in the email.
このタグが存在していないなら、署名ヘッダーにおける、その後のすべてのヘッダーがメールで見つけられたオーダーに含まれています。
A verifier MUST support this tag. A signer MAY support this
tag. If a signer generates this tag, it MUST include all
email headers in the original email, as a verifier MAY remove
or render suspicious, lines that are not included in the
signature.
検証はこのタグを支えなければなりません。 署名者はこのタグを支えるかもしれません。 署名者がこのタグを発生させるなら、オリジナルのヘッダーが検証が取り外されるときメールするか、または疑わしげに表すすべてのメールを含まなければなりません、署名に含まれていない線。
In the presence of duplicate headers, a signer may include
duplicate entries in the list of headers in this tag. If a
header is included in this list, a verifier must include all
occurrences of that header, subsequent to the "DomainKey-
Signature:" header in the verification.
写しヘッダーの面前で、署名者はこのタグにヘッダーのリストに写しエントリーを含むかもしれません。 ヘッダーがこのリストに含まれているなら、検証はそのヘッダーのすべての発生を含まなければなりません、その後、「DomainKey署名:」 検証におけるヘッダー。
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-署名:」 加工処理した検証a検証のヘッダーが合っているヘッダーを「見るかもしれない」前、「DomainKey-署名:」 ヘッダー。 しかしながら、早めの経験が、ほとんどの検証が以前戻るとして「見ようとしないこと」を示すとき署名者がこれを当てにするはずがない、「DomainKey-署名:」 ヘッダー。
Whitespace is ignored in this value and header comparisons are
case insensitive.
空白はこの値で無視されます、そして、ヘッダー比較は大文字と小文字を区別しないです。
Delany Historic [Page 16] RFC 4870 DomainKeys May 2007
[16ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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質問タイプで、この値にprependedされる、」 _domainkey」 送付ドメインの名前空間。
(Syntax rules for the tag=value format are discussed in Appendix A.)
(Appendix 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;
DomainKey-署名: a=rsa-sha1。 s=brisbane。 d=example.net。 c=簡単。 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.
直接署名照合に関係しない追加意味論が必要であるなら、その後のヘッダーが署名で保護したので、それらを加えるだけでよいです。 意味追加は初期の服従について説明する監査情報を含むかもしれません。
3.4. Preparation of Email for Transit and Signing
3.4. トランジットと調印のためのメールの準備
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.
うまくいっている検証の機会を最大にするために、提出されたメールは調印の前に輸送のために準備されるべきです、そして、調印アルゴリズムに提示されたデータは最も一般的、そして、メールさせられたマイナーチェンジを除くためにcanonicalizedされます。
Delany Historic [Page 17] RFC 4870 DomainKeys May 2007
[17ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
3.4.1. Preparation for Transit
3.4.1. トランジットのための準備
The SMTP protocol defines a number of potential limitations to email transport, particularly pertaining to line lengths and 8-bit content.
特に行長と8ビットの内容に関して、SMTPプロトコルは、輸送をメールするために多くの潜在的制限を定義します。
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ビットのメールと長い線を受け入れます、実現がまだそうしていないいくつか。 その結果SHOULDが調印のためにメールを提示する前にSMTPの最小公分母に適するメールを準備するDomainKeys実現。
3.4.2. Canonicalization for Signing
3.4.2. 調印のためのCanonicalization
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.
初めは、境界において、または、MUAsかSUBMISSIONサーバでというよりむしろ組織のメール境界でDomainKeysが配備されると予想されます。 言い換えれば、メールがパッケージされて、姿を変えられて、一般に、トランスミッションのためにインターネットの向こう側に準備された後に調印と通常、アルゴリズムを確かめるのは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つの競争している見解があります。 ほとんどの送付者にとって、メールの軽い変更はメールの認証状態に重要でないです。 そのような送付者に関しては、トランジットにおける穏やかな変更を乗り切るcanonicalizationアルゴリズムは好まれます。
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.
しかしながら、他の送付者に関しては、メールのどんなに小さい方であってもどんな変更も認証が失敗する願望をもたらします。 言い換えれば、そのような送付者は彼らによって認可されるのを変更されたメールを見て欲しくはありません。 これらの送付者はトランジットにおける、サインされたメールの変更を許容しないcanonicalizationアルゴリズムを好みます。
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つのcanonicalizationアルゴリズムが定義されます。 変更をほとんど全く許容しない「簡単な」アルゴリズムと空白交換とヘッダーとして一般的な変更を許容する"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.
中で「h」タグに関連してどちらのアルゴリズムも使用できる、「DomainKey-署名:」 ヘッダー。
Delany Historic [Page 18] RFC 4870 DomainKeys May 2007
[18ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
Canonicalization simply prepares the email for the signing or verification algorithm. It does not change the transmitted data in any way.
Canonicalizationは調印か検証アルゴリズムのために単にメールを準備します。 それは何らかの方法で伝えられたデータを変えません。
3.4.2.1. The "simple" Canonicalization Algorithm
3.4.2.1. 「簡単な」Canonicalizationアルゴリズム
o Each line of the email is presented to the signing algorithm in
the order it occurs in the complete email, from the first line of
the headers to the last line of the body.
o メールの各線はオーダーにおける調印アルゴリズムに提示されて、完全なメールに起こります、ヘッダーの最初の線からボディーの最終ラインまでことです。
o If the "h" tag is used, only those header lines (and their
continuation lines if any) added to the "h" tag list are included.
o 「h」タグが使用されているなら、「h」タグリストに追加されたそれらのヘッダー線(そして、もしあればそれらの継続行)だけが含まれています。
o The "h" tag only constrains header lines. It has no bearing on
body lines, which are always included.
o 「h」タグはヘッダー線を抑制するだけです。 それはボディー・ラインに堪えることを持っていません。(ボディー・ラインはいつも含まれています)。
o Remove any local line terminator.
o あらゆるローカル線ターミネータを取り除いてください。
o Append CRLF to the resulting line.
o 結果として起こる線にCRLFを追加してください。
o All trailing empty lines are ignored. An empty line is a line of
zero length after removal of the local line terminator.
o すべての引きずっている人影のない線が無視されます。 人影のない線はローカル線ターミネータの取り外しの後のゼロ・レングスの線です。
If the body consists entirely of empty lines, then the header/body
line is similarly ignored.
ボディーが人影のない線から完全に成るなら、ヘッダー/ボディー・ラインは同様に無視されます。
3.4.2.2. The "nofws" Canonicalization Algorithm
3.4.2.2. "nofws"Canonicalizationアルゴリズム
The "No Folding Whitespace" algorithm (nofws) is more complicated than the "simple" algorithm for two reasons; folding whitespace is removed from all lines and header continuation lines are unwrapped.
「いいえの折りたたみの空白」アルゴリズム(nofws)は2つの理由で「簡単な」アルゴリズムより複雑です。 すべての線から折りたたみの空白を取り除きます、そして、ヘッダー継続行を開けます。
o Each line of the email is presented to the signing algorithm in
the order it occurs in the complete email, from the first line
of the headers to the last line of the body.
o メールの各線はオーダーにおける調印アルゴリズムに提示されて、完全なメールに起こります、ヘッダーの最初の線からボディーの最終ラインまでことです。
o Header continuation lines are unwrapped so that header lines
are processed as a single line.
o ヘッダー継続行は、ヘッダー線が単線として処理されるように、開けられます。
o If the "h" tag is used, only those header lines (and their
continuation lines if any) added to the "h" tag list are
included.
o 「h」タグが使用されているなら、「h」タグリストに追加されたそれらのヘッダー線(そして、もしあればそれらの継続行)だけが含まれています。
o The "h" tag only constrains header lines. It has no bearing on
body lines, which are always included.
o 「h」タグはヘッダー線を抑制するだけです。 それはボディー・ラインに堪えることを持っていません。(ボディー・ラインはいつも含まれています)。
Delany Historic [Page 19] RFC 4870 DomainKeys May 2007
[19ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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 メールによる各線に、すべての折りたたみの空白キャラクタを外してください。 折りたたみの空白はRFC2822でASCII値9(HTAB)、10(NL)の小数、13(CR)と32(SP)であると定義されます。
o Append CRLF to the resulting line.
o 結果として起こる線にCRLFを追加してください。
o Trailing empty lines are ignored. An empty line is a line of
zero length after removal of the local line terminator. Note
that the test for an empty line occurs after removing all
folding whitespace characters.
o 引きずっている人影のない線は無視されます。 人影のない線はローカル線ターミネータの取り外しの後のゼロ・レングスの線です。 すべての折りたたみの空白キャラクタを外した後に人影のない線のためのテストが起こることに注意してください。
If the body consists entirely of empty lines, then the
header/body line is similarly ignored.
ボディーが人影のない線から完全に成るなら、ヘッダー/ボディー・ラインは同様に無視されます。
3.5. The Signing Process
3.5. サインアップ過程
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 prependingする、「DomainKey-署名:」 ヘッダー
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email.
ある理由でメールにサインできないなら、メールするのは、処理するべきことに関するローカルの政策決定です。
3.5.1. Identifying the Sending Domain
3.5.1. 送付ドメインを特定します。
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.
Eメールアドレスを見つけることによって送付ドメインが決定している「送付者:」 ヘッダー、「送付者:」 ヘッダーはプレゼント、「From:」の最初のEメールアドレスではありません。 ヘッダーは、送付ドメインを決定するのに使用されます。
Delany Historic [Page 20] RFC 4870 DomainKeys May 2007
[20ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
If the email has an invalid "From:" or an invalid "Sender:" header, it MUST NOT be signed.
メールに無効の「From:」があるなら 病人、「送付者:」 ヘッダー、それにサインしてはいけません。
If the signer adds the "h" tag to the "DomainKey-Signature:" header, that tag MUST include the header that was used to determine the sending domain.
署名者が「h」タグを加える、「DomainKey-署名:」 ヘッダー、そのタグは送付ドメインを決定するのに使用されたヘッダーを含まなければなりません。
3.5.2. Determining Whether an Email Should Be Signed
3.5.2. メールがサインされるべきであるかどうか決定します。
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.
署名者が既にaを含むメールにサインしてはいけない、「DomainKey署名:」 ヘッダー、「送付者:」 オリジナルの署名に含まれていなかったヘッダーは加えられます。 これが起こる最も明白なケースがメーリングリストと共にあります。
A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.
A署名者SHOULD NOTが存在を取り除く、「DomainKey-署名:」 ヘッダー。
3.5.3. Selecting a Private Key and Corresponding Selector Information
3.5.3. 秘密鍵と対応するセレクタ情報を選択します。
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.
この仕様は署名者がどの秘密鍵とセレクタ情報を使用したらよいかを選ぶはずである基礎を定義しません。 現在この仕様に関する限り、すべてのセレクタが等しいので、決定は主に管理便利の問題であるべきです。
3.5.4. Calculating the Signature Value
3.5.4. 署名値について計算します。
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.
署名者は、調印アルゴリズムにメールを提示するのに定義されたcanonicalizationアルゴリズムの1つを使用しなければなりません。 Canonicalizationは、調印のためにメールを準備するのに使用されるだけです。 それは何らかの方法で伝えられたメールに影響しません。
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-状態:」 調印とトランスミッションのための準備の前のメールからのヘッダー。
3.5.5. Prepending the "DomainKey-Signature:" Header
3.5.5. Prependingする、「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.
サインアップ過程における最終的なステップが署名者がprependされなければならないということである、「DomainKey-署名:」 メールを伝える過程を続行する前のヘッダー。
Delany Historic [Page 21] RFC 4870 DomainKeys May 2007
[21ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
3.6. Policy Statement of Sending Domain
3.6. 送付ドメインの施政方針
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「t=y」のdomainkey。 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 = 外国行きのSigning方針(「-」は、このドメインがすべてのメールにサインすることを意味します; 「~」は、デフォルトであり、このドメインが何らかのメールと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は報告Eメールアドレスと等しいです。 存在しているなら、これは無効の検証結果が報告されるEメールアドレスを定義します。 このタグは前のimplementersのために主として意図します--レポートの内容と頻度は別々のドキュメントで定義されるでしょう。
t = a set of flags that define boolean attributes. Valid
attributes are as follows:
tは論理演算子属性を定義する1セットの旗と等しいです。 有効な属性は以下の通りです:
y = testing mode. This domain is testing DomainKeys, and
unverified email MUST NOT be treated differently from
verified email. Recipient systems MAY wish to track
testing mode results to assist the sender).
yはテストモードと等しいです。 このドメインはDomainKeysをテストしています、そして、非検証されたメールは確かめられたメールと異なって扱われてはいけません。 送付者を補助するためにテストモード結果を追跡するという受取人システム5月の願望)
Note that testing mode cannot be turned off by this tag;
thus, policy cannot revert the testing mode setting of a
Selector.
このタグでテストモードを無効にすることができないことに注意してください。 したがって、方針はSelectorのテストモード設定を振り向けることができません。
This tag is optional.
このタグは任意です。
Delany Historic [Page 22] RFC 4870 DomainKeys May 2007
[22ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
(Syntax rules for the tag=value format are discussed in Appendix A.)
(Appendix 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.
署名を確かめるか、またはメールが含んでいないと、受取人システムSHOULDは、方針を決定するためにこの方針TXT記録を検索するだけです。 受取人システムSHOULDはそれが首尾よく確かめるメールのためのこの方針TXT記録を検索しません。 また、ドメイン所有者がDomainKeysテストを走らせているなら「テストモード」SHOULDがSelector TXT記録にあることに注意してください。
If the policy TXT record does not exist, recipient systems MUST assume the default values.
方針TXT記録が存在していないなら、受取人システムはデフォルト値を仮定しなければなりません。
There is an important implication when a domain states that it signs all email with the "o=-" setting, namely that the sending domain prefers that the recipient system treat unsigned mail with a great deal of suspicion. Such suspicion could reasonably extend to rejecting such email. A verifying system MAY reject unverified email if a domain policy indicates that it signs all email.
ドメインが、すべてのメールにサインすると述べるとき、重要な含意がある、「oが等しい、-、」 設定、すなわち、送付ドメインは、受取人システムが多くの容疑がある無記名のメールを扱うのを好みます。 そのような容疑は合理的にそのようなメールを拒絶するのに敷衍されることができました。 ドメイン方針が、すべてのメールにサインするのを示すなら、検証システムは非検証されたメールを拒絶するかもしれません。
Of course, nothing compels a recipient MTA to abide by the policy of the sender. In fact, during the trial, a sending domain would want to be very certain about setting this policy, as processing by recipient MTAs may be unpredictable. Nonetheless, a domain that states that it signs all email MUST expect that unverified email may be rejected by some receiving MTAs.
もちろん、何も受取人MTAが送付者の方針を守るのを強制しません。 事実上、トライアルの間、送付ドメインはこの方針を設定することに関して非常に確かでありたがっているでしょう、受取人MTAsによる処理が予測できないかもしれないので。 それにもかかわらず、メールを非検証したメールが予想しなければならないすべてにサインすると述べるドメインは、MTAsを受けながら、いくつかによって拒絶されるかもしれません。
3.7. The Verification Process
3.7. 検証の過程
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.
これらのステップのどれかが失敗する場合、送付ドメイン方針は、ローカルの方針を適用するのを助けるために確かめられます。
Delany Historic [Page 23] RFC 4870 DomainKeys May 2007
[23ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
3.7.1. Presumption that Headers Are Not Reordered
3.7.1. 推定はそのHeaders Are Not Reorderedです。
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.
この仕様の旧バージョンの展開からの指摘が、「h」に関連したcanonicalizationアルゴリズムがコネにタグ付けをするのを示す、「DomainKey-署名:」 ヘッダーは調印と検証の間で完全な状態でほとんどのメールを暗号で存続させます。
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.
特に複数の面前でこの仮定の2番目の結果、「DomainKey-署名:」 ヘッダー、--、それが1番目である「DomainKey-署名:」 メールによるヘッダーは、メールに追加された最後の署名であり、その結果、確かめられるべきものです。
3.7.2. Verification Should Render a Binary Result
3.7.2. 検証は2進の結果をレンダリングするべきです。
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.
診断目的、検証がSHOULDに失敗する正確な理由で、記録されてください。 しかしながら、エンドユーザへのプレゼンテーションによる結果SHOULD、簡単な2進の結果として、提示されてください: メールが確かめられるか、またはそれは確かめられません。 メールを確かめることができないで、次に、それはSHOULDです。それがサインされたように見えるかどうかにかかわらずすべてがメールを非検証したので、同じようにレンダリングされてください。
3.7.3. Selecting the Most Appropriate "DomainKey-Signature:" Header
3.7.3. 最も好個を選択する、「DomainKey-署名:」 ヘッダー
In most cases, a signed email is expected to have just one signature -- that is, one "DomainKey-Signature:" header. However, it is entirely possible that an email can contain multiple signatures. In such cases, a verifier MUST find the most appropriate signature to use and SHOULD ignore all other signatures.
多くの場合、サインされたメールにはちょうど1つの署名()があると予想される、1つ、「DomainKey-署名:」 ヘッダー。 しかしながら、メールが複数の署名を含むことができるのは、完全に可能です。 ケース、検証がそうしなければならないそのようなものでは、使用する中で最も適切な署名とSHOULDが他のすべての署名を無視すると確かめてください。
Delany Historic [Page 24] RFC 4870 DomainKeys May 2007
[24ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
The process of finding the most appropriate signature consists of the following "best match" rules. The rules are to be evaluated in order.
最も適切な署名を見つける過程は以下の「最も良いマッチ」規則から成ります。 規則はオーダーで評価されることです。
1. Selecting the sending domain
1. 送付ドメインを選択します。
If the email contains a "Sender:" header, the sending domain is
extracted from the "Sender:" address. If this extraction
fails, the email SHALL fail verification.
メールがaを含んでいる、「送付者:」 ヘッダー、ドメインが抽出される発信、「送付者:」 アドレス。 この抽出が失敗するなら、メールSHALLは検証に失敗します。
If no "Sender:" header is present, the sending domain is
extracted from the first address of the "From:" header. If
this extraction fails, the email SHALL fail verification.
いいえ、「送付者:」 ヘッダーが出席している、送付ドメインは「From:」の最初のアドレスから抽出されます。 ヘッダー。 この抽出が失敗するなら、メールSHALLは検証に失敗します。
2. Domain matching
2. ドメインマッチング
A signature can only match if the sending domain matches the
"d" tag domain -- according to the "d" tag subdomain matching
rules.
規則に合っている「d」タグサブドメインによると、送付ドメインが「d」タグドメインに合っている場合にだけ、署名は合うことができます。
3. "h" tag matching
3. 「h」タグマッチング
If the signature contains the "h" tag list of headers, that
list must include the header used to extract the sending domain
in rule 1, above.
署名がヘッダーの「h」タグリストを含んでいるなら、そのリストは規則1で送付ドメインを抽出するのに使用されるヘッダーを含まなければなりません、上です。
4. Most secure signing algorithm
4. 最も安全な調印アルゴリズム
While it is not yet the case, in the event that additional
algorithms are added to this specification, a verifier MUST use
the signature that contains the most secure algorithm as
defined by the future specification. For current
implementations, that means verifiers MUST ignore signatures
that are coded with an unrecognized signing algorithm.
しかし、追加アルゴリズムがこの仕様に追加される場合、それはケースではありませんが、検証は将来の仕様で定義されるように最も安全なアルゴリズムを含む署名を使用しなければなりません。 現在の実現のために、それは、検証が認識されていない調印アルゴリズムでコード化される署名を無視しなければならないことを意味します。
5. Earlier signatures are preferred
5. 以前の署名は好まれます。
If multiple signatures are equal as far as these rules apply,
the signature from the earlier header MUST be used in
preference to later signature headers.
これらの規則が適用される限り、複数の署名が等しいなら、後の署名ヘッダーに優先して以前のヘッダーからの署名を使用しなければなりません。
Implementors MUST meticulously validate the format and values in the "DomainKey-Signature:" header; any inconsistency or unexpected values MUST result in ignoring that header. Being "liberal in what you accept" is definitely a bad strategy in this security context.
作成者が形式と値をきちょうめんに有効にしなければならない、「DomainKey-署名:」 ヘッダー。 どんな矛盾や予期していなかった値もそのヘッダーを無視するのに結果として生じなければなりません。 「あなたが受け入れるもので寛容」であることは、確実にこのセキュリティ文脈の悪い戦略です。
Delany Historic [Page 25] RFC 4870 DomainKeys May 2007
[25ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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は発生して、失敗の理由について説明するのを助けるメッセージを含んでいます。
3.7.4. Retrieve the Public Key Based on the Signature Information
3.7.4. 署名情報に基づく公開鍵を検索してください。
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.
公開鍵が、検証の過程を完了するのに必要です。 公開鍵を検索する過程を中で「q」タグによって定義されるように質問タイプに頼っている、「DomainKey-署名:」 ヘッダー線。 明らかに、署名情報を抜粋する過程が完全にうまくいく場合にだけ、公開鍵は検索されるべきです。
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」タグで定義というセレクタ名を使用する、」 _」 名前空間とドメイン名が「d」タグで定義したdomainkey、DNS TXTの記録的な質問ストリングを構成して、発行してください。
For example, if s=brisbane and d=example.net, the query string
is "brisbane._domainkey.example.net".
例えば、s=brisbaneとd=example.netであるなら、質問ストリングは「. _domainkey.example.netをbrisbaneする」ことです。
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. 公開鍵のための質問が応じないなら、検証SHOULDはこのメールの承認を延期します(通常、これは4XX SMTP応答コードで達成されるでしょう)。
3. If the query for the public key fails because the corresponding
data does not exist, the verifier MUST treat the email as
unverified.
3. 対応するデータが存在していないので公開鍵のための質問が失敗するなら、検証は非検証されるようにメールを扱わなければなりません。
4. If the result returned from the query does not adhere to the
format defined in this specification, the verifier MUST treat
the email as unverified.
4. 質問から返された結果がこの仕様に基づき定義された書式を固く守らないなら、検証は非検証されるようにメールを扱わなければなりません。
5. If the public key data is not suitable for use with the
algorithm type defined by the "a" tag in the "DomainKey-
Signature:" header, the verifier MUST treat the email as
unverified.
5. 中のアルゴリズムタイプが定義されていた状態で公開鍵データが“a"タグで使用に適していない、「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.
SHA-1細切れ肉料理について計算することと平行して潜在の批判的な実現は公開鍵質問を開始したがっているかもしれません、最終的なRSAが計算されるまで公開鍵が必要でないように。
Delany Historic [Page 26] RFC 4870 DomainKeys May 2007
[26ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
3.7.5. Verify the Signature
3.7.5. 署名について確かめてください。
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.
canonicalizationアルゴリズムが中で「c」タグを定義した、「DomainKey-署名:」 ヘッダーはデータが検証アルゴリズムのためにどう準備されるかを定義します、そして、同じヘッダーの“a"タグはどの検証アルゴリズムを使用したらよいかを定義します。
3.7.6. Retrieving Sending Domain Policy
3.7.6. 送付ドメイン方針を検索します。
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
_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.
SHOULDが送付ドメイン施政方針と行為であるとそれに従って、考える検証。 可能性として考えられる範囲は受信機次第ですが、それは、メールを拒絶するのを含むかもしれません。
3.7.7. Applying Local Policy
3.7.7. ローカルの方針を適用します。
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.
逆に、非認証されたメールは信用と評判を割り当てるのに使用できる信頼できる識別子を欠いています。 どんな信用も欠いていて、どんな積極的な評判も持っていないとして非認証されたメールを扱うのは無理ではありません。
3.8. Conveying Verification Results to MUAs
3.8. 検証結果をMUAsに伝えます。
Apart from the application of automated policy, the result of a signature verification should be conveyed to the user reading the email.
自動化された方針の適用は別として、署名照合の結果はメールを読んでいるユーザに伝えられるべきです。
Delany Historic [Page 27] RFC 4870 DomainKeys May 2007
[27ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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.
特定のフォルダーに特定のヘッダーを見分けて、簡単な規則、例えばファイリングを適用するためにほとんどのメールクライアントを構成できます。 初めは境界MTAでDomainKey署名が確かめられると予想されて、検証の結果は、メールクライアントまで運ばれる必要があります。 これが処理される、「DomainKey-状態:」 ヘッダー線はメールにprependedされました。
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.
クライアントSHOULDは、ただ「利益」を探して、他のすべての値が、ある理由で検証を実行できなかったのを含意すると仮定します。 このヘッダーの結果としての政策的措置は完全に地域にかかわる事柄です。
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.
MTAsがMUAsの前で意識しているDomainKeyになると予想されますが、DomainKey意識しているMUAをだますことができるのをaがだまされたのが、それにもかかわらず、可能である、「DomainKey-状態:」 aを通り抜けるヘッダー、非DomainKey意識する、MTA。
If this is perceived to be a serious problem, then it may make sense to preclude the "good" value and only have values that effectively demote the email as far as the UA is concerned. That way successful spoofing attempts can only serve to demote themselves.
これが深刻な問題であると知覚されるなら、それはUAに関する限り、「良い」値を排除して、事実上、メールを格下げする値を持つだけである意味になるかもしれません。 そのようにうまくいっているスプーフィング試みは、自分たちを格下げするのに役立つことができるだけです。
Delany Historic [Page 28] RFC 4870 DomainKeys May 2007
[28ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
4. Example of Use
4. 使用に関する例
This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together.
このセクションは最終的な配送への服従からメールの完全な流れを示しています、様々なコンポーネントがどう一緒に合うかを示して。
4.1. The User Composes an Email
4.1. ユーザはメールを構成します。
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: 「ジョーSixPack、「 <joe@football.example.com 、gt;、To:、」 「スージーQ、「 <suzie@shopping.example.net 、gt;、Subject:、」 夕食は準備ができていますか? 日付: 金曜日、2003年7月11日21:00:37 -0700(太平洋夏時間の)のMessage ID: <20030712040037.46341.5F8J@football.example.com>。
Hi.
こんにちは。
We lost the game. Are you hungry yet?
私たちはゲームに負けました。 あなたはもう、空腹ですか?
Joe.
ジョー。
4.2. The Email Is Signed
4.2. メールはサインされます。
This email is signed by the football.example.com outbound email server and now looks like this:
このメールは、football.example.comの外国行きのEメールサーバによってサインされて、現在、これに似ています:
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>
DomainKey-署名: a=rsa-sha1。 s=brisbane。 d=football.example.com。 c=簡単。 q=dns。 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR。 受け取られている: dsl-10.2.3.4.football.example.com、[10.2 .3 .4] SUBMISSIONとsubmitserver.football.example.com。 金曜日、2003年7月11日21:01:54 -0700(太平洋夏時間の)のFrom: 「ジョーSixPack、「 <joe@football.example.com 、gt;、To:、」 「スージーQ、「 <suzie@shopping.example.net 、gt;、Subject:、」 夕食は準備ができていますか? 日付: 金曜日、2003年7月11日21:00:37 -0700(太平洋夏時間の)の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.
調印Eメールサーバは、"brisbane"セレクタに関連している秘密鍵へのアクセスがこの署名を発生させるのを必要とします。 このドキュメントの範囲の外に秘密鍵の分配と管理があります。
Delany Historic [Page 29] RFC 4870 DomainKeys May 2007
[29ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
4.3. The Email Signature Is Verified
4.3. メール署名は確かめられます。
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サーバーかことによると最終的な新聞販売店によって確かめられます。 しかしながら、また、彼らが、そうするのを選ぶなら、介入しているMTAsはこの検証を実行できます。
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:」から抽出したドメインを使用します。 ヘッダーとセレクタが"brisbaneする"である、「DomainKey-署名:」 以下のためにDNS TXT質問を形成するヘッダー
brisbane._domainkey.football.example.com
brisbane_domainkey.football.example.com
Since there is no "h" tag in the "DomainKey-Signature:" header, signature verification starts with the line following the "DomainKey-Signature:" line. The email is canonically prepared for verifying with the "simple" method.
以来、中に「h」タグが全くない、「DomainKey-署名:」 ヘッダー、線が従っている署名照合始め、「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>
DomainKey-状態: = joe@football.example.com; からいいぞ domainkeys=はReceivedを渡します: mout23.brisbane.football.example.com、(192.168 .1 .1) SMTPとshopping.example.net。 金曜日、2003年7月11日21:01:59 -0700(太平洋夏時間の)のDomainKey-署名: a=rsa-sha1。 s=brisbane。 d=football.example.com。 c=簡単。 q=dns。 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR。 受け取られている: dsl-10.2.3.4.network.example.com、[10.2 .3 .4] SUBMISSIONとsubmitserver.example.com。 金曜日、2003年7月11日21:01:54 -0700(太平洋夏時間の)のFrom: 「ジョーSixPack、「 <joe@football.example.com 、gt;、To:、」 「スージーQ、「 <suzie@shopping.example.net 、gt;、Subject:、」 夕食は準備ができていますか? 日付: 金曜日、2003年7月11日21:00:37 -0700(太平洋夏時間の)のMessage ID: <20030712040037.46341.5F8J@football.example.com>。
Hi.
こんにちは。
We lost the game. Are you hungry yet?
私たちはゲームに負けました。 あなたはもう、空腹ですか?
Joe.
ジョー。
Delany Historic [Page 30] RFC 4870 DomainKeys May 2007
[30ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
5. Association with a Certificate Authority
5. 認証局との協会
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.
DomainKeysの基本的な面は各ドメインでどんな別途費用でも公開鍵の発生して、広告を出さないということです。 このアクセシビリティはそれらの公開鍵を含んでいて、しばしば再発料金で応募者を有効にして、署名入りの証書を発行するCertificate Authority(カリフォルニア)が通常ある伝統的な公開鍵暗号基盤と著しく異なっています。
While CAs do impose costs, they also have the potential to provide additional value as part of their certification process. Consider financial institutions, public utilities, law enforcement agencies, and the like. In many cases, such entities justifiably need to discriminate themselves above and beyond the authentication that DomainKeys offers.
CAsはコストを課しますが、また、それらにはそれらの証明の過程の一部として加算値を提供する可能性があります。 金融機関、公益事業、警察機関、および同様のものを考えてください。 多くの場合、そのような実体は、正当にDomainKeysが提供する認証を超えて自分たちを差別する必要があります。
Creating a link between DomainKeys and CA-issued certificates has the potential to access additional authentication mechanisms that are more authoritative than domain-owner-issued authentication. It is well beyond the scope of this specification to describe such authorities apart from defining how the linkage could be achieved with the "DomainKey-X509:" header.
DomainKeysとカリフォルニアによって発行された証明書とのリンクを作成するのにおいて、発行されたドメイン所有者認証より正式の追加認証機構にアクセスする可能性があります。 かなりそのような当局について説明するこの仕様の範囲を超えてどうリンケージを達成できたかを定義することは別としている、「DomainKey-X509:」 ヘッダー。
5.1. The "DomainKey-X509:" Header
5.1. 「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:」 ヘッダーはメールにサインするのに使用される公開鍵とカリフォルニアによって発行された証明書とのリンクを提供します。
The exact content, syntax, and semantics of this header are yet to be resolved. One possibility is that this header contains an encoding of the certificate issued by a CA. Another possibility is that this header contains a URL that points to a certificate issued by a CA.
このヘッダーの正確な内容、構文、および意味論はまだ決議されていないことです。 1つの可能性はこのヘッダーがカリフォルニアによって発行された証明書のコード化を含んでいるということです。 別の可能性はこのヘッダーがカリフォルニアによって発行された証明書を示す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-署名:」 ヘッダー。 その上、MTAsよりむしろMUAsは、カリフォルニアによって発行された証明書へのリンクが有効であると確認しそうでしょう。 これは多くのMUAsにはSecure/マルチパーパスインターネットメールエクステンション(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.
リンケージの証拠はそれをテストすることによって作られていて、証明書の公開鍵がメールにサインするのに使用される公開鍵に合っているということです。
Delany Historic [Page 31] RFC 4870 DomainKeys May 2007
[31ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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
...
DomainKey-署名: a=rsa-sha1。 sは声明と等しいです。 d=largebank.example.com。 c=簡単。 q=dns。 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR。 DomainKey-X509: https://ca.example.net/largebank.example.com From: 「大手銀行、「 <statements@largebank.example.com 、gt;、To:、」 「スージーQ、「 <suzie@shopping.example.net 、gt;、Subject:、」 アカウントのための声明: 1234-5678 ...
The format of the retrieved value from the URL is not yet defined, nor is the determination of valid CAs.
URLからの検索された価値の形式は、まだ定義されていなくて、有効なCAsの決断です。
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のものと共に決議される必要があるDomainKeysと証明書を発行する実体の1つの局面です。 原生品集産地はリンクが、より高い権威に可能であるということです。
6. Topics for Discussion
6. 議論のための話題
6.1. The Benefits of Selectors
6.1. セレクタの利益
Selectors are at the heart of the flexibility of DomainKeys. A domain administrator is free to use a single DomainKey for all outbound mail. Alternatively, the domain administrator may use many DomainKeys differentiated by selector and assign each key to different servers.
セレクタはDomainKeysの柔軟性の中心です。 ドメイン管理者はすべての外国行きのメールに自由に独身のDomainKeyを使用できます。 あるいはまた、ドメイン管理者は、セレクタによって微分された多くのDomainKeysを使用して、異なったサーバの各キーを割り当てるかもしれません。
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.
別の例はそれぞれの支社Eメールサーバのために別々の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.
本質では、セレクタで、ドメイン所有者はそのドメインを代表して発信する権威を分配できます。 取り外しかTimeでLive(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.
セレクタは特に特定のメールを送るために第三者郵送システムを収縮させたがっているドメイン所有者の役に立ちます。 ドメイン所有者はまさしく外のこのメールのために特別な主要な組とセレクタを発生させることができます。 ドメイン所有者は外のメールの人生のための第三者に秘密鍵とセレクタを提供しなければなりません。
Delany Historic [Page 32] RFC 4870 DomainKeys May 2007
[32ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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からエントリーを取り除く簡単な方法で公開鍵を取り消すことができます。
6.2. Canonicalization of Email
6.2. メールのCanonicalization
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つのcanonicalizationアルゴリズムがこの仕様に基づき定義されている間、"nofws"の第一の目標は「簡単に」変遷経路を提供することです。 「簡単」と"nofws"メールの混合物で、受信機は、どのシステムが署名が変更システムにフィードバックに失敗して、その結果、供給することを引き起こす方法でメールを変更しているかを決定できます。
6.3. Mailing Lists
6.3. メーリングリスト
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.
既存のMailing Listマネージャ(MLMs)をDomainKeys認証システムと統合するのは、複雑な領域です、MLMsの動きが非常に変化しているとき。 本質的には、MLMsの2つのタイプは考慮中であります: メールをオリジナルコンテンツの検証が可能でないくらいの程度まで変更して、最小量かいいえ、変更をするものをメールに変更するそれら。
MLMs that modify email in a way that causes verification to fail MUST prepend a "Sender:" header and SHOULD prepend a "List-ID:" header prior to signing for distribution to list recipients.
検証が失敗される方法でメールを変更するMLMsがaをprependしなければならない、「送付者:」 ヘッダーとSHOULD prepend a、「リスト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.
参加しているSUBMISSIONサーバがaの存在によるそのようなメールを再契約する必要性を推論できる、「送付者:」 または、「リストID:」 認可された服従からのヘッダー。
MLMs that do not modify email in a way that causes verification to fail MAY perform the same actions as a modifying MLM.
検証が失敗される方法でメールを変更しないMLMsは変更MLMと同じ動作を実行するかもしれません。
6.4. Roving Users
6.4. ユーザを流浪させます。
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.
DomainKeysを含むどんな形式のメール認証に関する特定の問題も提示する1つのシナリオが流浪しているユーザです: ユーザの自己のSUBMISSIONサービスに接続できないとき、第三者SUBMISSIONサービスを利用するのを強いられるユーザ。 引用された典型例はメールを送るためにホテルのEメールサーバに向け直される地方回り外交販売員です。
Delany Historic [Page 33] RFC 4870 DomainKeys May 2007
[33ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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に関する限り、この種のメールは販売員のドメインを代表して発信する権威を持っていない、したがって偽造から区別がつかないEメールサーバから明確に発します。 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.
ユーザを流浪させるのに提供された典型的なソリューションは恐らく彼らのドメインVirtual兵士のNetwork(VPN)、ウェブインタフェースまたはSMTP AUTHさえを通して認可されたサーバでSUBMISSIONサーバにメールを提出して戻すことです。
While these are perfectly acceptable solutions for many, they are not necessarily solutions that are available or possible for all such users.
これらは多くのための完全に許容できるソリューションですが、それらは必ずそのようなすべてのユーザにとって、利用可能であるか、または可能なソリューションであるというわけではありません。
One possible way to address the needs of this contingent of potentially disenfranchised users is for the domain to issue per-user DomainKeys. Per-user DomainKeys are identified by a non-empty "g" tag value in the corresponding DNS record.
潜在的に権利を奪われたユーザのこの派遣団の必要性を扱う1つの可能な方法はドメインが1ユーザあたりのDomainKeysを発行することです。 1ユーザあたりのDomainKeysは対応するDNS記録の非空の「g」タグ価値によって特定されます。
7. Security Considerations
7. セキュリティ問題
7.1. DNS
7.1. DNS
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はDNSを当てにします。(DNSはよく知られるセキュリティー・フロー[RFC3833]を持っています)。
7.1.1. The DNS Is Not Currently Secure
7.1.1. 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 Security(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
最終的に、DomainKeysは信憑性を立証する「十分な」メソッドとして意図するだけです。 それが強い状態で提供することを意図しません。
Delany Historic [Page 34] RFC 4870 DomainKeys May 2007
[34ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
cryptographic proof about authorship or contents. Other technologies such as GnuPG and S/MIME address those requirements.
著述業かコンテンツに関する暗号の証拠。 GnuPGやS/MIMEなどの他の技術はそれらの要件を扱います。
7.1.2. DomainKeys Creates Additional DNS Load
7.1.2. DomainKeysは追加DNS荷重を作成します。
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サーバは質問のかなりの増加を見るかもしれません。
7.2. Key Management
7.2. Key Management
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証明書のものと同様です。 不十分なかぎ管理は秘密鍵への不正アクセスをもたらすかもしれません。(本質では、それは、あなたのアイデンティティへの不正アクセスを与えます)。
7.3. Implementation Risks
7.3. 実装リスク
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.
セキュリティアプリケーションをプログラムするのを助ける多数の記事、本、コース、およびコンサルタントがいます。 潜在的作成者が安全な実装を確実にするのにすべての可能なリソースを自分たちに利用するよう強く奨励されます。
7.4. Privacy Assumptions with Forwarding Addresses
7.4. フォーワーディング・アドレスとのプライバシー仮定
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.
人々の中には彼らがEメール転送サービスを使用することによって匿名を達成できると信じている人もいます。 これが特に本当である間、弾み、過剰割当てメッセージ、自動返信用メッセージ、暴露するすべてがIPアドレスを共謀するウェブバグ、および配送経路に関連しているドメイン名として、DomainKeys署名について確かめるのに必要であるDNS質問は追加情報を送付者に決して提供できません。
Delany Historic [Page 35] RFC 4870 DomainKeys May 2007
[35ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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質問は推進と配送MTAsによって使用されたDNSキャッシュを通常特定するでしょう。
7.5. Cryptographic Processing Is Computationally Intensive
7.5. 暗号の処理は計算上徹底的です。
Verifying a signature is computationally significant. Early indications are that a typical mail server can expect to increase CPU demands by 8-15 percent. While this increased demand is modest compared to other common mail processing costs -- such as Bayesian filtering -- any increase in resource requirements can make a denial-of-service attack more effective against a mail system.
署名について確かめるのは計算上重要です。 早めの指摘は典型的なメールサーバが、CPU要求を8-15パーセント増強すると予想できるということです。 ベイズフィルタなどの他の一般的なメール処理コストと比べて、この需要増が穏やかである間、リソース要件のどんな増加でも、サービス不能攻撃はメールシステムに対して、より効果的になる場合があります。
A constraining factor of such attacks is that the net computational cost of verifying is bounded by the maximum key size allowed by this specification and is essentially linear to the rate at which mail is accepted by the verifying system. Consequently, the additional computational cost may augment a denial-of-service attack, but it does not add a non-linear component to such attacks.
そのような攻撃の抑制要素は検証の正味のコンピュータの費用が最大の主要なサイズによってこの仕様で許容されて、境界があって、本質的にはメールが検証システムによって受け入れられるレートに直線的であるということです。 その結果、追加コンピュータの費用はサービス不能攻撃を増大させるかもしれませんが、それはそのような攻撃に非線形のコンポーネントを加えません。
8. The Trial
8. トライアル
The DomainKeys protocol was deployed as a trial to better understand the implications of deploying wide-scale cryptographic email authentication.
DomainKeysプロトコルは、広いスケールの暗号のメールが認証であると配布する含意をより理解するためにトライアルとして配布されました。
Open Source implementations were made available at various places, particularly Source Forge [SOURCEFORGE], which includes links to numerous implementations, both Open Source and commercial.
開いているSource実装を様々な場所、特にSource Forge[SOURCEFORGE]で利用可能にしました。(Source Forgeは多数の実装へのリンク、オープンSourceとコマーシャルの両方を含んでいます)。
8.1. Goals
8.1. 目標
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 canonicalizationアルゴリズムの有効性を測定してください。
o experiment with possible per-user key deployment models
o 1ユーザあたりの可能な主要な展開モデルによる実験
o fully define the semantics of the "DomainKey-X509:" header
o 意味論を完全に定義する、「DomainKey-X509:」 ヘッダー
Delany Historic [Page 36] RFC 4870 DomainKeys May 2007
[36ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
8.2. Results of Trial
8.2. トライアルの結果
The DomainKeys trial ran for approximately 2 years, in which time numerous large ISPs and many thousands of smaller domains participated in signing or verifying with DomainKeys. The low order numbers are that at least one billion DomainKey signed emails transit the Internet each day between some 12,000 participating domains.
DomainKeysトライアルはおよそ2年間上演されました、多数の大きいISPと何千ものより小さいドメインが参加したDomainKeysと共に署名するか、または確かめられるどの時間。 下位の番号は署名される少なくとも10億DomainKeyが毎日およそ1万2000の参加ドメインの間でトランジットにインターネットをメールするということです。
The operational and development experience of that trial was applied to DKIM.
そのトライアルの操作上と開発経験はDKIMに適用されました。
9. Note to Implementors Regarding TXT Records
9. TXTを見なすのが記録することに作成者に注意してください。
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.
ただ一つの名前のための複数のTXT記録を持って、それらのTXT記録が多連を含むのが、可能であるので、DNSは非常にフレキシブルです。
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コマンドラインツールが同じくらい別々に、引用文字列を多連に表すことに注意してください。(初心者作成者にとって、引用文字列は紛らわしい場合があります)。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[BASE64]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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: RFC1421 1993年2月の「メッセージ暗号化と認証手順」
Delany Historic [Page 37] RFC 4870 DomainKeys May 2007
[37ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
10.2. Informative References
10.2. 有益な参照
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[DKIM] オールマン、E.、カラス、J.、ディラニー、M.、リッベイ、M.、フェントン、J.、およびM.トーマス、「DomainKeysはメール(DKIM)署名を特定しました」、RFC4871、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.、エディタ、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、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は仕様を通信する」RFC3851、7月2004日
[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
Delany Historic [Page 38] RFC 4870 DomainKeys May 2007
[38ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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 値はRFC2822ヘッダーとDNS TXT記録で有効であり、SPACE(0×20)からTILDE(0x7E)まで包括的なキャラクタのASCII範囲の中にあるキャラクタから成るだけでよいです。 値はセミコロンを含んではいけませんが、それらは「=」キャラクタを含むかもしれません。
o A tag=value pair MUST be terminated by a semicolon or the end
of the data
o データのセミコロンか終わりまでにタグ=値組を終えなければなりません。
o Values MUST be processed as case sensitive unless the specific
tag description of semantics imply case insensitivity.
o 意味論の明確なタグ記述が大文字小文字の同一視を含意しないなら、大文字と小文字を区別するとして値を処理しなければなりません。
o Values MAY be zero bytes long
o 値はバイト長でないかもしれません。
o Whitespace MAY surround any of the tokens; however, whitespace
within a value MUST be retained unless explicitly excluded by
the specific tag description. Currently, the only tags that
specifically ignore embedded whitespace are the "b" and "h"
tags in the "DomainKey-Signature:" header.
o 空白はトークンのどれかを囲むかもしれません。 しかしながら、明確なタグ記述で明らかに除かれない場合、値の中の空白を保有しなければなりません。 現在明確に埋め込まれた空白を無視する唯一のタグが中の「b」と「h」タグである、「DomainKey-署名:」 ヘッダー。
o Tag=value pairs that represent the default value MAY be
included to aid legibility.
o デフォルト値を表すタグ=値組は、読みやすさを支援するために含まれるかもしれません。
o Unrecognized tags MUST be ignored
o 認識されていないタグを無視しなければなりません。
Delany Historic [Page 39] RFC 4870 DomainKeys May 2007
[39ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
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、スティーブ・アトキンス、ジョン・カラス、デーヴ・クロッカー、マイケル・クダヒーに感謝したがっています、ユッタDegener、ティモシーDer、ジム・フェントン、ダンカン・フィンドレイ、フィリップ・ハラム-ベイカー、マレーS; 彼らの貴重な提案と建設的批判のためのKucherawy、ジョン・レヴィン、Milesリッベイ、デヴィッドMargrave、ジャスティン・メイスン、デヴィッド・メイン、ラッセル・ネルソン、ホアンAltmayer Pizzorno、ブレークRamsdell、スコット・レンフロー、Spamhaus.orgチーム、Malte S.Stretz、ロバートSanders、ブラッドリーのテイラー、およびRandワッカー。
Author's Address
作者のアドレス
Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
マークディラニーYahoo!Inc701First Avenueカリフォルニア95087サニーベル(米国)
EMail: markd+domainkeys@yahoo-inc.com
メール: markd+ domainkeys@yahoo-inc.com
Delany Historic [Page 40] RFC 4870 DomainKeys May 2007
[40ページ]RFC4870DomainKeys2007年5月に歴史的なディラニー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Delany Historic [Page 41]
ディラニーHistoricです。[41ページ]
一覧
スポンサーリンク
