Internet Engineering Task Force (IETF) T. Hansen
Request for Comments: 5863 AT&T Laboratories
Category: Informational E. Siegel
ISSN: 2070-1721 Consultant
P. Hallam-Baker
Default Deny Security, Inc.
D. Crocker
Brandenburg InternetWorking
May 2010
DomainKeys Identified Mail (DKIM)
Development, Deployment, and Operations
Abstract
抽象
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM.
ドメインキー・アイデンティファイド・メール（DKIM）は、組織が受信者によって検証することができるように、メッセージを送信するための責任を主張することを可能にします。組織は著者の、元の送信サイト、仲介者、またはその代理人のいずれかになります。メッセージは、メッセージに関与同一または異なる組織から、複数の署名を含むことができます。 DKIMは、公開鍵暗号方式を使用して、そのキーサーバ技術としてドメインネームサービスを使用して、電子メールのドメインレベルのデジタル署名の認証フレームワークを定義します。これは責任がある組織だけでなく、メッセージの内容の整合性の検証が可能になります。 DKIMはまた、自分の電子メールの署名の慣行についての情報を公開する可能性のある電子メールの署名者を許可するメカニズムを提供します。これは、メッセージに関する追加の評価を行うために、電子メールの受信者を許可します。電子メールのアイデンティティのDKIMの認証は、「スパム」と「フィッシング」のグローバル制御を支援することができます。この文書では、DKIMの実装、導入、運用、および移行に関する考慮事項を提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5863.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5863で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
2. Using DKIM as Part of Trust Assessment ..........................4
2.1. A Systems View of Email Trust Assessment ...................4
2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
2.3. Choosing the Signing Domain Name ...........................8
2.4. Recipient-Based Assessments ...............................10
2.5. Filtering .................................................12
3. DKIM Key Generation, Storage, and Management ...................15
3.1. Private Key Management: Deployment and Ongoing
Operations ................................................16
3.2. Storing Public Keys: DNS Server Software Considerations ...17
3.3. Per-User Signing Key Management Issues ....................18
3.4. Third-Party Signer Key Management and Selector
Administration ............................................19
3.5. Key Pair / Selector Life Cycle Management .................19
4. Signing ........................................................21
4.1. DNS Records ...............................................21
4.2. Signing Module ............................................21
4.3. Signing Policies and Practices ............................22
5. Verifying ......................................................23
5.1. Intended Scope of Use .....................................23
5.2. Signature Scope ...........................................23
5.3. Design Scope of Use .......................................24
5.4. Inbound Mail Filtering ....................................24
5.5. Messages Sent through Mailing Lists and Other
Intermediaries ............................................25
5.6. Generation, Transmission, and Use of Results Headers ......25
6. Taxonomy of Signatures .........................................26
6.1. Single Domain Signature ...................................26
6.2. Parent Domain Signature ...................................27
6.3. Third-Party Signature .....................................27
6.4. Using Trusted Third-Party Senders .........................29
6.5. Multiple Signatures .......................................30
7. Example Usage Scenarios ........................................31
7.1. Author's Organization - Simple ............................32
7.2. Author's Organization - Differentiated Types of Mail ......32
7.3. Author Domain Signing Practices ...........................32
7.4. Delegated Signing .........................................34
7.5. Independent Third-Party Service Providers .................35
7.6. Mail Streams Based on Behavioral Assessment ...............35
7.7. Agent or Mediator Signatures ..............................36
8. Usage Considerations ...........................................36
8.1. Non-Standard Submission and Delivery Scenarios ............36
8.2. Protection of Internal Mail ...............................37
8.3. Signature Granularity .....................................38
8.4. Email Infrastructure Agents ...............................39
8.5. Mail User Agent ...........................................40
9. Security Considerations ........................................41
10. Acknowledgements ..............................................41
11. References ....................................................42
11.1. Normative References .....................................42
11.2. Informative References ...................................42
Appendix A. Migration Strategies .................................43
A.1. Migrating from DomainKeys .................................43
A.2. Migrating Hash Algorithms .................................48
A.3. Migrating Signing Algorithms ..............................49
Appendix B. General Coding Criteria for Cryptographic
Applications .........................................50
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. This document provides practical tips for those who are developing DKIM software, mailing list managers, filtering strategies based on the output from DKIM verification, and DNS servers; those who are deploying DKIM software, keys, mailing list software, and migrating from DomainKeys [RFC4870]; and those who are responsible for the ongoing operations of an email infrastructure that has deployed DKIM.
ドメインキー・アイデンティファイド・メール（DKIM）は、組織が受信者によって検証することができるように、メッセージを送信するための責任を主張することを可能にします。この文書では、DKIMソフトウェア、メーリングリストマネージャ、DKIMの検証からの出力、およびDNSサーバに基づいてフィルタリング戦略を開発している人のための実用的なヒントを提供します。 DKIMソフトウェア、キー、メーリングリストソフトウェアを展開し、DomainKeysのから移行している者として、[RFC4870]。そして、DKIMを展開している電子メールインフラストラクチャの継続的な業務を担当している人。
The reader is encouraged to read the DKIM Service Overview document [RFC5585] before this document. More detailed guidance about DKIM and Author Domain Signing Practices (ADSP) can also be found in the protocol specifications [RFC4871], [RFC5617], and [RFC5672].
読者は、この文書の前にDKIMサービス概要ドキュメント[RFC5585]を読むことをお勧めします。 DKIMと著者ドメイン署名プラクティス（ADSP）に関するより詳細な指針は、プロトコル仕様で、[RFC4871]、[RFC5617]、および[RFC5672]を見つけることができます。
The document is organized around the key concepts related to DKIM. Within each section, additional considerations specific to development, deployment, or ongoing operations are highlighted where appropriate. The possibility of the use of DKIM results as input to a local reputation database is also discussed.
文書は、DKIMに関連する重要な概念を中心に編成されています。各セクション内で、開発、展開、または進行中の動作に特有の追加の考慮事項は、適切な場合に強調されています。ローカル評価データベースへの入力としてDKIM結果の使用の可能性についても議論されています。
DKIM participates in a trust-oriented enhancement to the Internet's email service, to facilitate message handling decisions, such as for delivery and for content display. Trust-oriented message handling has substantial differences from the more established approaches that consider messages in terms of risk and abuse. With trust, there is a collaborative exchange between a willing participant along the sending path and a willing participant at a recipient site. In contrast, the risk model entails independent, unilateral action by the recipient site, in the face of a potentially unknown, hostile, and deceptive sender. This translates into a very basic technical difference: in the face of unilateral action by the recipient and even antagonistic efforts by the sender, risk-oriented mechanisms are based on heuristics, that is, on guessing. Guessing produces statistical results with some false negatives and some false positives. For trust-based exchanges, the goal is the deterministic exchange of information. For DKIM, that information is the one identifier that represents a stream of mail for which an independent assessment is sought (by the signer).
DKIMは、配信のためなどとコンテンツの表示のためのメッセージ処理の決定を容易にするために、インターネットの電子メールサービスへの信頼指向の強化に参加しています。トラスト指向のメッセージ処理は、リスクや虐待の面でメッセージを考えるより確立されたアプローチとはかなりの違いがあります。信頼して、受信者のサイトに送信する経路に沿って、喜んで参加者と喜んで参加者間の共同交換があります。これとは対照的に、リスクモデルは、潜在的に、未知の敵対的、かつ欺瞞送信者の顔には、受信者のサイトによって独立して、一方的な行動を伴います。これは非常に基本的な技術的な違いに翻訳：受信者と送信者にも拮抗努力によって、一方的な行動に直面して、リスク志向のメカニズムを推測する上で、つまり、経験則に基づいています。推測では、いくつかの偽陰性といくつかの偽陽性との統計結果を生成します。信頼ベースの交流のために、目標は、情報の決定論的交換です。 DKIMのために、その情報は、独立した評価は、（署名者によって）求められているメールのストリームを表すつの識別子です。
A trust-based service is built upon a validated Responsible Identifier that labels a stream of mail and is controlled by an identity (role, person, or organization). The identity is acknowledging some degree of responsibility for the message stream. Given a basis for believing that an identifier is being used in an authorized manner, the recipient site can make and use an assessment of the associated identity. An identity can use different identifiers, on the assumption that the different streams might produce different assessments. For example, even the best-run marketing campaigns will tend to produce some complaints that can affect the reputation of the associated identifier, whereas a stream of transactional messages is likely to have a more pristine reputation.
信頼ベースのサービスは、メールの流れをラベルとアイデンティティ（役割、人、または組織）によって制御されている検証責任識別子に基づいて構築されます。アイデンティティは、メッセージストリームの責任をある程度認めています。識別子が正規に使用されていることを信じるの基礎を考えると、受信者のサイトには、関連するアイデンティティの評価を行い、使用することができます。アイデンティティは異なるストリームが異なる評価を生み出す可能性があることを前提に、異なる識別子を使用することができます。トランザクションメッセージの流れは、より原始的な評判を持っている可能性があるのに対し、例えば、でも最高のランマーケティングキャンペーンは、関連する識別子の評判に影響を与えることができ、いくつかの苦情を生成する傾向があります。
Determining that the identifier's use is valid is quite different from determining that the content of a message is valid. The former means only that the identifier for the responsible role, person, or organization has been legitimately associated with a message. The latter means that the content of the message can be believed and, typically, that the claimed author of the content is correct. DKIM validates only the presence of the identifier used to sign the message. Even when this identifier is validated, DKIM carries no implication that any of the message content, including the RFC5322.From field [RFC5322], is valid. Surprisingly, this limit to the semantics of a DKIM signature applies even when the validated signing identifier is the same domain name as is used in the RFC5322.From field! DKIM's only claim about message content is that the content cited in the DKIM-Signature: field's h= tag has been delivered without modification. That is, it asserts message content integrity -- between signing and verifying -- not message content validity.
識別子の使用が有効であることを決定することは、メッセージの内容が有効であると判断するとは全く異なります。かつての手段は責任役割、人、あるいは組織の識別子が合法的メッセージに関連付けされている唯一のこと。後者は、メッセージの内容は、コンテンツの著者主張が正しいことを、典型的には、信じてすることができることを意味します。 DKIMは、メッセージに署名するために使用される識別子の存在のみを検証します。この識別子が検証された場合でも、DKIMはRFC5322.Fromフィールドを含むメッセージの内容のいずれか、[RFC5322]という意味を運ばない、有効です。驚くべきことに、DKIM署名の意味にこの制限は検証署名識別子がRFC5322.From分野で使用されているのと同じドメイン名である場合にも適用されます！メッセージ内容約DKIMの唯一の主張は、コンテンツがDKIM-署名に引用することである：フィールドのH =タグをそのまま配信されています。ないメッセージ内容妥当性 - 署名と検証の間 - すなわち、それは、メッセージ内容の整合性を主張する、です。
As shown in Figure 1, this enhancement is a communication between a responsible role, person, or organization that signs the message and a recipient organization that assesses its trust in the signer. The recipient then makes handling decisions based on a collection of assessments, of which the DKIM mechanism is only a part. In this model, as shown in Figure 1, validation is an intermediary step, having the sole task of passing a validated Responsible Identifier to the Identity Assessor. The communication is of a single Responsible Identifier that the Responsible Identity wishes to have used by the Identity Assessor. The Identifier is the sole, formal input and output value of DKIM signing. The Identity Assessor uses this single, provided Identifier for consulting whatever assessment databases are deemed appropriate by the assessing entity. In turn, output from the Identity Assessor is fed into a Handling Filter engine that considers a range of factors, along with this single output value. The range of factors can include ancillary information from the DKIM validation.
図1に示すように、この拡張は、メッセージおよび署名者における信頼を評価する受信者組織に署名担う役割、個人、または組織との間の通信です。受信者は、DKIMメカニズムは一部のみとなっている評価のコレクションに基づいて取り扱いを決定します。図1に示すように、このモデルでは、検証は、身元評価に検証責任識別子を渡す唯一のタスクを有し、中間工程です。通信は、責任アイデンティティアイデンティティ評価者によって使用されることを望む単一責任の識別子です。識別子は、DKIM署名の唯一の、正式な入力と出力の値です。身元評価は、評価エンティティによって適切であると判断されているものは何でも評価データベースコンサルティングのために、このシングル、提供の識別子を使用しています。次に、身元評価からの出力は、この単一の出力値とともに、要因の範囲を考慮した取り扱いフィルタエンジンに供給されます。要素の範囲は、DKIM検証から補助情報を含むことができます。
Identity Assessment covers a range of possible functions. It can be as simple as determining whether the identifier is a member of some list, such as authorized operators or participants in a group that might be of interest for recipient assessment. Equally, it can indicate a degree of trust (reputation) that is to be afforded the actor using that identifier. The extent to which the assessment affects the handling of the message is, of course, determined later, by the Handling Filter.
アイデンティティ評価は、可能な機能の範囲をカバーしています。これは、識別子は、このような受信者の評価のための関心のかもしれないグループの認可事業者または参加者として、いくつかのリストのメンバーであるかどうかを判断するのと同じくらい簡単です。同様に、それはその識別子を使用して俳優に与えられるべきである信託（評判）の度合いを示すことができます。評価は、メッセージの処理に影響する程度は、もちろん、取扱いフィルターによって、後に決定されます。
+------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+
Figure 1: Actors in a Trust Sequence Using DKIM
図1：DKIMを使用したトラスト・シーケンスで俳優
The signer of a message needs to be able to provide precise data and know what that data will mean upon delivery to the Assessor. If there is ambiguity in the choice that will be made on the recipient side, then the sender cannot know what basis for assessment will be used. DKIM has three values that specify identification information and it is easy to confuse their use, although only one defines the formal input and output of DKIM, with the other two being used for internal protocol functioning and adjunct purposes, such as auditing and debugging.
メッセージの署名者は、正確なデータを提供し、そのデータが評価機関への配送時に意味するかを知ることができる必要があります。受信者側で行われる選択にあいまいさがある場合、送信者が使用される評価のための何の根拠を知ることができません。 DKIMは、識別情報を指定する3つの値を持ち、一つだけは、他の2つは、内部プロトコル機能及びそのような監査やデバッグなどの補助目的で使用されていると、DKIMの正式な入力と出力を定義するが、それらの使用を混同することは容易です。
The salient values include the s=, d= and i= parameters in the DKIM-Signature: header field. In order to achieve the end-to-end determinism needed for this collaborative exchange from the signer to the assessor, the core model needs to specify what the signer is required to provide to the assessor. The update to RFC 4871 [RFC5672] specifies:
ヘッダフィールド：顕著な値は、S = D =私= DKIM-シグネチャでパラメータを含みます。査定への署名者から、この共同の交換に必要なエンドツーエンドの決定論を達成するために、コアモデルは、署名者が審査員に提供するために必要とされるものを指定する必要があります。 RFC 4871 [RFC5672]への更新を指定します：
DKIM's primary task is to communicate from the Signer to a recipient-side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity. DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID)... A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the User Agent Identifier (i=) if present.... To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM's specification and semantics.
DKIMの主な仕事は、責任の同一性をいう受信者側の身元評価単一署名ドメイン識別子（SDID）への署名者から通信することです。 DKIMは、必要に応じて、単一の責任エージェントまたはユーザー識別子（AUID）を提供することができる...かかる身元評価モジュールに署名ドメイン識別子（D =）を通信しなければならないとユーザエージェント識別子を通信することができる受信側DKIM検証（I =）存在する場合....受信機は識別子のいずれかのための任意の構造化された意味を直感しようとする限り、これは、DKIMの仕様及びセマンティクスの範囲外であるヒューリスティック関数です。
The single, mandatory value that DKIM supplies as its output is:
：その出力としてDKIMの供給があることを、単一、必須値
d= This specifies the "domain of the signing entity". It is a domain name and is combined with the selector to form a DNS query. A receive-side DKIM verifier needs to communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and can also communicate the User Agent Identifier (i=) if present.
D =これは、「署名エンティティのドメイン」を指定します。これは、ドメイン名とDNSクエリを形成するために、セレクタと組み合わされます。受信側のDKIM検証は、かかる身元評価モジュールに署名ドメイン識別子（D =）を通信する必要があり、また、ユーザエージェント識別子（I =）存在する場合に通信することができます。
The adjunct values are:
補助値は次のとおりです。
s= This tag specifies the selector. It is used to discriminate among different keys that can be used for the same d= domain name. As discussed in Section 4.3 of [RFC5585], "If verifiers were to employ the selector as part of an assessment mechanism, then there would be no remaining mechanism for making a transition from an old, or compromised, key to a new one". Consequently, the selector is not appropriate for use as part or all of the identifier used to make assessments.
S =このタグは、セレクタを指定します。同じD =ドメイン名のために使用することができる異なる鍵を区別するために使用されます。 [RFC5585]のセクション4.3で議論するように、「検証は、評価機構の一部として、セレクタを使用した場合、新しいものに古い、または損なわれ、キーから遷移するための残りの機構は存在しないであろう」。したがって、セレクタは、一部又は評価を行うために使用される識別子の全てとして使用するのに適切ではありません。
i= This tag is optional and provides the "[t]he Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility" [RFC5672]. The identity can be in the syntax
I =このタグはオプションで、[RFC5672]「SDIDが責任を取っているの代わりに[t]は、彼のエージェントまたはユーザー識別子（AUID）」を提供します。アイデンティティは、構文にすることができ
of an entire email address or only a domain name. The domain name can be the same as for d= or it can be a sub-name of the d= name.
全体の電子メールアドレスまたはドメイン名だけの。ドメイン名は、Dと同じであることができる=または、D =名のサブ名前とすることができます。
NOTE: Although the i= identity has the syntax of an email address, it is not required to have those semantics. That is, "the identity of the user" need not be the same as the user's mailbox. For example, the signer might wish to use i= to encode user-related audit information, such as how they were accessing the service at the time of message posting. Therefore, it is not possible to conclude anything from the i= string's (dis)similarity to email addresses elsewhere in the header.
注：I = IDはメールアドレスの構文がありますが、それはそれらの意味を持っている必要はありません。それは、「ユーザーのIDが」ユーザーのメールボックスと同じである必要はない、です。たとえば、署名者は、このような方法を、彼らはメッセージの投稿時にサービスにアクセスしていたとして、ユーザ関連の監査情報を符号化する= Iを使用したい場合があります。したがって、他の場所でヘッダー内の電子メールアドレスへのI =文字列の（非）類似度から何かを締結することはできません。
So, i= can have any of these properties:
だから、私は=これらのプロパティのいずれかを持つことができます。
* Be a valid domain when it is the same as d=
*それはdと同じであるとき、有効なドメインう=
* Appear to be a subdomain of d= but might not even exist
* Dのサブドメインのように見える=それでも存在しない可能性があります
* Look like a mailbox address but might have different semantics and therefore not function as a valid email address
*メールボックスアドレスのように見えるが、別の意味を持っているので、有効な電子メールアドレスとして機能しない可能性があります
* Be unique for each message, such as indicating access details of the user for the specific posting
*そのような特定の投稿のためのユーザーのアクセスの詳細を示すものとして、メッセージごとに一意です
This underscores why the tag needs to be treated as being opaque, since it can represent any semantics, known only to the signer.
タグは、それが唯一の署名者に知られているいずれかの意味を表すことができるので、不透明なものとして扱われる必要がある理由はここに強調しています。
Hence, i= serves well as a token that is usable like a Web cookie, for return to the signing Administrative Management Domain (ADMD) -- such as for auditing and debugging. Of course in some scenarios the i= string might provide a useful adjunct value for additional (heuristic) processing by the Handling Filter.
このような監査およびデバッグ用として - したがって、私は=署名管理管理ドメイン（ADMD）への復帰のために、ウェブクッキーのような使用可能なトークンとしてよく働きます。もちろん、いくつかのシナリオでは、私=文字列処理フィルタによる追加的（ヒューリスティック）処理のために有用な補助値を提供するかもしれません。
A DKIM signing entity can serve different roles, such as being the author of content, the operator of the mail service, or the operator of a reputation service that also provides signing services on behalf of its customers. In these different roles, the basis for distinguishing among portions of email traffic can vary. For an entity creating DKIM signatures, it is likely that different portions of its mail will warrant different levels of trust. For example:
DKIMの署名エンティティは、そのようなコンテンツの作者、メールサービス、またはまた、顧客に代わって署名サービスを提供して評判サービスの事業者の事業者であることなど、さまざまな役割を果たすことができます。これらの異なる役割では、電子メールトラフィックの部分の間で区別するための根拠は変えることができます。 DKIM署名を作成するエンティティのために、そのメールの異なる部分が信頼の異なるレベルを保証する可能性があります。例えば：
* Mail is sent for different purposes, such as marketing versus transactional, and recipients demonstrate different patterns of acceptance between these.
*メールは、このようなトランザクション対マーケティングなど、さまざまな目的のために送信され、受信者は、これらの間の受け入れの異なるパターンを示しています。
* For an operator of an email service, there often are distinct sub-populations of users warranting different levels of trust or privilege, such as paid versus free users, or users engaged in direct correspondence versus users sending bulk mail.
*電子メールサービスの事業者については、多くの場合、無料ユーザー、またはバルクメールを送信するユーザーに対して直接対応に従事し、ユーザーに対して支払ったとして、信託または特権の異なるレベルを保証するユーザーの個別のサブ集団があります。
* Mail originating outside an operator's system, such as when it is redistributed by a mailing-list service run by the operator, will warrant a different reputation from mail submitted by users authenticated with the operator.
*メールなど、それがオペレータによって実行メーリングリストサービスによって再配布されたときのようにオペレータのシステム、外部から発信、オペレータで認証されたユーザが提出したメールは異なる評判を保証します。
It is therefore likely to be useful for a signer to use different d= subdomain names, for different message traffic streams, so that receivers can make differential assessments. However, too much differentiation -- that is, too fine a granularity of signing domains -- makes it difficult for the receiver to discern a sufficiently stable pattern of traffic for developing an accurate and reliable assessment. So the differentiation needs to achieve a balance. Generally, in a trust system, legitimate signers have an incentive to pick a small stable set of identities, so that recipients and others can attribute reputations to them. The set of these identities a receiver trusts is likely to be quite a bit smaller than the set it views as risky.
受信機は、差動の評価を行うことができるように、署名者は、異なるメッセージトラフィックストリームの異なるD =サブドメイン名を使用するために有用であることが可能性が高いです。しかし、あまりにも多くの分化は - つまり、署名ドメインの粒度が細かすぎる - 受信機が正確で信頼性の高い評価を開発するため、トラフィックの十分に安定したパターンを識別することが困難になります。だから、分化がバランスを達成するために必要です。一般的に、信頼システムで、正当な署名者は、受信者と他の人が彼らに評判の属性ことができるように、アイデンティティの小さな安定したセットを選択するインセンティブを持っています。これらのIDのセットの受信機の信頼関係は、それが危険なようビューセットよりもかなり小さくなる可能性があります。
The challenge in using additional layers of subdomains is whether the extra granularity will be useful for the Assessor. In fact, excessive levels invite ambiguity: if the Assessor does not take advantage of the added granularity in the entire domain name that is provided, they might unilaterally decide to use only some rightmost part of the identifier. The signer cannot know what portion will be used. That ambiguity would move the use of DKIM back to the realm of heuristics, rather than the deterministic processing that is its goal.
サブドメインの追加の層を使用する際の課題は、余分な粒度が査定のために有用であろうかどうかです。実際には、過剰なレベルは、あいまいさを招待：アセッサが提供されるドメイン名全体で追加粒度を利用していない場合、彼らは一方的識別子の一部だけ右端の一部を使用することを決めるかもしれません。署名者は、使用されるどのような部分を知ることができません。その曖昧さは、経験則の領域ではなく、その目標であり、確定処理に戻ってDKIMの使用を移動します。
Hence, the challenge is to determine a useful scheme for labeling different traffic streams. The most obvious choices are among different types of content and/or different types of authors. Although stability is essential, it is likely that the choices will change, over time, so the scheme needs to be flexible.
したがって、課題は、異なるトラフィックストリームを標識するための有益なスキームを決定することです。最も明白な選択肢は、コンテンツおよび/または著者の異なる種類の異なる種類の一つです。安定性が不可欠ですが、時間をかけて、選択肢が変化する可能性があるので、計画は柔軟である必要があります。
For those originating message content, the most likely choice of subdomain naming scheme will by based upon type of content, which can use content-oriented labels or service-oriented labels. For example:
メッセージの内容を元の方のために、最も可能性の高い選択肢サブドメインの命名方式は、コンテンツ指向のラベルやサービス指向のラベルを使用することができ、コンテンツの種類に基づいてによってでしょう。例えば：
transaction.example.com
newsletter.example.com
bugreport.example.com
support.example.com
sales.example.com
marketing.example.com
where the choices are best dictated by whether they provide the Identity Assessor with the ability to discriminate usefully among streams of mail that demonstrate significantly different degrees of recipient acceptance or safety. Again, the danger in providing too fine a granularity is that related message streams that are labeled separately will not benefit from an aggregate reputation.
どこ選択肢が最良の彼らは、受信者の受け入れや安全性の著しく異なる度を実証したメールの流れの中で有効に識別する能力と身元評価を提供するかどうかによって決定されます。ここでも、あまりにも細かい粒度を提供する上での危険は個別にラベル付けされ、関連するメッセージの流れが集約評判の恩恵を受けるないということです。
For those operating messaging services on behalf of a variety of customers, an obvious scheme to use has a different subdomain label for each customer. For example:
顧客の多様に代わってこれらのオペレーティング・メッセージング・サービスの場合、使用する明白なスキームは、顧客ごとに異なるサブドメインラベルを持っています。例えば：
widgetco.example.net
moviestudio.example.net
bigbank.example.net
However, it can also be appropriate to label by the class of service or class of customer, such as:
しかし、またのようなサービスや顧客のクラスのクラスによって標識するのに適切なものとすることができます。
premier.example.net
free.example.net
certified.example.net
Prior to using domain names for distinguishing among sources of data, IP Addresses have been the basis for distinction. Service operators typically have done this by dedicating specific outbound IP Addresses to specific mail streams -- typically to specific customers. For example, a university might want to distinguish mail from the administration, versus mail from the student dorms. In order to make the adoption of a DKIM-based service easier, it can be reasonable to translate the same partitioning of traffic, using domain names in place of the different IP Addresses.
データのソースを区別するためにドメイン名を使用する前に、IPアドレスを区別するための基礎となっています。通常、特定の顧客に - サービス事業者は、通常、特定のメールストリームに特定の送信IPアドレスを専用にすることによって、これを行っています。例えば、大学は学生寮からのメールに対して、行政からのメールを区別することがあります。 DKIMベースのサービスの採用を容易にするためには、異なるIPアドレスの代わりにドメイン名を使用して、トラフィックの同じパーティションを変換するために合理的なことができます。
DKIM gives the recipient site's Identity Assessor a verifiable identifier to use for analysis. Although the mechanism does not make claims that the signer is a Good Actor or a Bad Actor, it does make it possible to know that use of the identifier is valid. This is in marked contrast with schemes that do not have authentication. Without verification, it is not possible to know whether the identifier -- whether taken from the RFC5322.From field, the RFC5321.MailFrom command, or the like -- is being used by an authorized agent. DKIM solves this problem. Hence, with DKIM, the Assessor can know that two messages with the same DKIM d= identifier are, in fact, signed by the same person or organization. This permits a far more stable and accurate assessment of mail traffic using that identifier.
DKIMは、受信者のサイトの身元評価を分析するために使用するための検証可能な識別子を与えます。メカニズムは署名者が良い俳優か悪い俳優であることを主張することはありませんが、それは識別子の使用が有効であることを知っていることを可能にしません。これは、認証を持っていないスキームと著しく対照的です。検証がなければ、それは識別子かどうかを知ることは不可能である - RFC5322.Fromフィールド、RFC5321.MailFromコマンド等から取得したかどうか - 認可エージェントによって使用されています。 DKIMは、この問題を解決します。したがって、DKIMと、アセッサは、実際には、同じ人物または組織が署名し、同じDKIMさd =識別子を持つ2つのメッセージがあることを知ることができます。これは、その識別子を使用してメールトラフィックのはるかに安定して正確な評価が可能となります。
DKIM is distinctive, in that it provides an identifier that is not necessarily related to any other identifier in the message. Hence, the signer might be the author's ADMD, one of the operators along the transit path, or a reputation service being used by one of those handling services. In fact, a message can have multiple signatures, possibly by any number of these actors.
DKIMは、必ずしもメッセージ内の他の識別子に関連していない識別子を提供することで、独特です。したがって、署名者は、作者のADMD、トランジットパス、またはサービスを取り扱い、それらのいずれかで使用されている評判のサービスに沿って事業者の一つであるかもしれません。実際には、メッセージは、おそらくこれらのアクターの任意の数によって、複数の署名を持つことができます。
As discussed above, the choice of identifiers needs to be based on differences that the signer thinks will be useful for the recipient Assessor. Over time, industry practices establish norms for these choices.
上述したように、識別子の選択は、署名者が受信者の査定のために有用であろうと考えて差に基づいてする必要があります。時間が経つにつれて、業界の慣行は、これらの選択肢のための規範を確立します。
Absent such norms, it is best for signers to distinguish among streams that have significant differences, while consuming the smallest number of identifiers possible. This will limit the burden on recipient Assessors.
不在な規範、それは可能な識別子の最小数を消費しながら、有意差を持っているのストリームを区別するために署名者に最適です。これは、受信者の評価者の負担が制限されます。
A common view about a DKIM signature is that it carries a degree of assurance about some or all of the message contents, and in particular, that the RFC5322.From field is likely to be valid. In fact, DKIM makes assurances only about the integrity of the data and not about its validity. Still, presumptions of the RFC5322.From field validity remain a concern. Hence, a signer using a domain name that is unrelated to the domain name in the RFC5322.From field can reasonably expect that the disparity will warrant some curiosity, at least until signing by independent operators has produced some established practice among recipient Assessors.
DKIM署名に関する一般的なビューはRFC5322.Fromフィールドが有効である可能性が高いこと、それは、メッセージの内容の一部またはすべてについて保証の程度を運び、特にことです。実際には、DKIMは、データのみの整合性についてではなく、その有効性についての保証を行います。それでも、RFC5322.Fromフィールドの妥当性の推測が懸念残ります。したがって、RFC5322.Fromフィールドにドメイン名とは無関係なドメイン名を使用して署名者が合理的格差は、少なくとも受信者の評価者の間でいくつかの慣例を生産している独立した事業者によって署名されるまで、いくつかの好奇心を保証することを期待することができます。
With the identifier(s) supplied by DKIM, the Assessor can consult an independent assessment service about the entity associated with the identifier(s). Another possibility is that the Assessor can develop its own reputation rating for the identifier(s). That is, over time, the Assessor can observe the stream of messages associated with the identifier(s) developing a reaction to associated content. For example, if there is a high percentage of user complaints regarding signed mail with a d= value of "widgetco.example.net", the Assessor might include that fact in the vector of data it provides to the Handling Filter. This is also discussed briefly in Section 5.4.
DKIMによって提供された識別子（S）と、査定は、識別子（複数可）に関連したエンティティに関する独立した評価サービスを相談することができます。別の可能性は、アセッサは、識別子（複数可）のために、自身の評判格付けを開発することができるということです。つまり、時間の経過とともに、評価者は、関連コンテンツへの反応を現像識別子（複数可）に関連するメッセージの流れを観察することができます。例えば、場合Dで署名メールに関するユーザーからの苦情の割合が高い=「widgetco.example.net」の値があり、アセッサは、それが処理フィルターに提供するデータのベクトルでその事実が含まれる場合があります。また、これは5.4節で簡単に説明されます。
The assessment of the signing identifier is given to a Handling Filter that is defined by local policies, according to a potentially wide range of different factors and weightings. This section discusses some of the kinds of choices and weightings that are plausible and the differential actions that might be performed. Because authenticated domain names represent a collaborative sequence between signer and Assessor, actions can sometimes reasonably include contacting the signer.
署名識別子の評価は、異なる因子および重み付けの潜在的に広い範囲に応じて、ローカルポリシーによって定義された処理フィルタに与えられます。このセクションでは、もっともらしい選択と重みの種類および実行されることがあります差動アクションのいくつかを説明します。認証されたドメイン名が署名者と評価機関の間の協調シーケンスを表しているので、アクションは時々合理的に署名者を接触させることを含み得ます。
The discussion focuses on variations in Organizational Trust versus Message Stream Risk, that is, the degree of positive assessment of a DKIM-signing organization, and the potential danger present in the message stream signed by that organization. While it might seem that higher trust automatically means lower risk, the experience with real-world operations provides examples of every combination of the two factors, as shown in Figure 2. For each axis, only three levels of granularity are listed, in order to keep discussion manageable. In real-world filtering engines, finer-grained distinctions are typically needed, and there typically are more axes. For example, there are different types of risk, so that an engine might distinguish between spam risk versus virus risk and take different actions based on which type of problematic content is present. For spam, the potential damage from a false negative is small, whereas the damage from a false positive is high. For a virus, the potential danger from a false negative is extremely high, while the likelihood of a false positive when using modern detection tools is extremely low. However, for the discussion here, "risk" is taken as a single construct.
議論は、それは、DKIM署名組織のポジティブな評価、およびその組織によって署名されたメッセージ・ストリームに存在する潜在的な危険度であるメッセージストリームリスク、対組織信頼の変化に焦点を当てています。ために、高い信頼は自動的に低リスクを意味し、実世界の業務経験は二つの要因の全ての組み合わせの例を提供し、各軸について、図2に示すように、粒度の唯一の三つのレベルが表示されているように見えるかもしれませんが管理しやすい議論を続けます。実世界のフィルタリングエンジンでは、よりきめの細かい違いは、一般的に必要であり、一般的に複数の軸がありますされています。エンジンは、ウイルスの危険対スパムリスクを区別して存在している問題のあるコンテンツのタイプに基づいて、異なる行動を取る可能性があるように、例えば、リスクの異なる種類があります。偽陽性からのダメージが高いのに対し、スパムのために、偽陰性の潜在的な被害は、小さいです。現代の検出ツールを使用して偽陽性の可能性は極めて低いが、ウイルスのために、偽陰性の潜在的な危険性は、非常に高いです。しかし、ここでの議論のために、「リスク」とは、単一の構築物として取られます。
The DKIM d= identifier is independent of any other identifier in a message and can be a subdomain of the name owned by the signer. This permits the use of fine-grained and stable distinctions between different types of message streams, such as between transactional messages and marketing messages from the same organization. Hence, the use of DKIM might permit a richer filtering model than has typically been possible for mail-receiving engines.
DKIMさd =識別子は、メッセージ内の任意の他の識別子とは無関係であり、署名者が所有している名前のサブドメインであることができます。これは、同じ組織からのトランザクションメッセージやマーケティングメッセージの間などのメッセージ・ストリームの異なる種類、間、きめの細かい、安定した区別を使用することが可能になります。したがって、DKIMの使用は、典型的には、メール受信のエンジンのために可能であったよりも、より豊かなフィルタリングモデルを許可することがあります。
Note that the realities of today's public Internet Mail environment necessitate having a baseline handling model that is quite suspicious. Hence, "strong" filtering rules really are the starting point, as indicated for the UNKNOWN cell.
今日の公共のインターネットメール環境の現実はかなり疑わしいベースライン処理モデルを持つ必要があります。 UNKNOWNセルに対して示されているように、従って、「強い」フィルタルールは、実際に、出発点です。
The table indicates differential handling for each combination, such as how aggressive or broad-based the filtering could be. Aggressiveness affects the types of incorrect assessments that are likely. So, the table distinguishes various characteristics, including: 1) whether an organization is unknown, known to be good actors, or known to be bad actors; and 2) the assessment of messages. It includes advice about the degree of filtering that might be done, and other message disposition. Perhaps unexpectedly, it also lists a case in which the receiving site might wish to deliver problematic mail, rather than redirecting or deleting it. The site might also wish to contact the signing organization and seek resolution of the problem.
テーブルは、このようなフィルタリングは、可能性がどのように積極的または広域ベースとして、各組み合わせについて処理微分を示しています。攻撃性は可能性があり、誤った評価の種類に影響を与えます。だから、表には含めて様々な特性を、区別する：1）組織は良い俳優、または悪い俳優であることが知らあることが知られている、不明であるかどうか。及び2）メッセージの評価。それは行われるかもしれないフィルタリングの程度、およびその他のメッセージの処分に関するアドバイスを含んでいます。おそらく予想外に、それはまた、受信サイトではなく、それをリダイレクトするか、削除するよりも、問題のメールを配信したいかもしれませんした場合を示しています。サイトでは、署名機関に連絡し、問題の解決を模索したいかもしれません。
+-------------+-----------------------------------------------+
| S T R E A M * O R G A N I Z A T I O N A L T R U S T |
| R I S K * Low Medium High |
| +***************+***************+***************+
| Low * BENIGN: | DILIGENT: | PRISTINE |
| * Moderate | Mild | Accept |
| * filter | filter | |
| +---------------+---------------+---------------+
| Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
| * Strong | Targeted | Accept & |
| * filter | filter | Contact |
| +---------------+---------------+---------------+
| High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
| * Block & | Block | Block & |
| * Counter | | Contact |
+-------------+---------------+---------------+---------------+
Figure 2: Trust versus Risk Handling Tradeoffs Example
図2：リスク対トラストはトレードオフの例を取り扱い
[LEGEND]
[伝説]
AXES
AXES
Stream Risk: This is a measure of the recent history of a message stream and the severity of problems it has presented.
ストリームリスク：これは、メッセージストリームの最近の歴史とそれが提示した問題の深刻さの尺度です。
Organizational Trust: This combines longer-term history about possible stream problems from that organization, and its responsiveness to problem handling.
組織の信頼：これは、その組織から可能なストリームの問題についてのより長期的な歴史を組み合わせて、問題の取り扱いへの応答。
CELLS (indicating reasonable responses)
細胞（合理的な応答を示します）
Labels for the cells are meant as a general assessment of an organization producing that type of mail stream under that circumstance.
細胞のためのラベルは、そのような状況下で、メールストリームの種類を生産する組織の一般的な評価として意図されています。
Benign: There is some history of sending good messages, with very few harmful messages having been received. This stream warrants filtering that does not search for problems very aggressively, in order to reduce the likelihood of false positives.
良性：非常に少数の有害なメッセージが受信されたと、良いメッセージを送信するいくつかの歴史があります。偽陽性の可能性を低減させるために、非常に積極的に問題を検索しません。この流れを保証フィルタリング。
Diligent: The stream has had a limited degree of problems and the organization is consistently successful at controlling their abuse issues and in a timely manner.
勤勉：ストリームが問題の限られた程度を持っていたし、組織が彼らの乱用の問題を制御することをタイムリーに一貫して成功しています。
Pristine: There is a history of a clean message stream with no problems, from an organization with an excellent reputation. So, the filter primarily needs to ensure that messages are delivered; catching stray problem messages is a lesser concern. In other words, the paramount concern, here, is false positives.
プリスティン：問題なくきれいなメッセージストリームの歴史は優秀な評判を持つ組織から、があります。だから、フィルタは、主にメッセージが配信されていることを確認する必要があります。浮遊問題メッセージをキャッチすることはあまり心配です。言い換えれば、最大の関心事は、ここでは、偽陽性です。
-----
Unknown: There is no history with the organization. Apply an aggressive level of "naive" filtering, given the nature of the public email environment.
不明：組織との既往はありません。公共の電子メール環境の性質を考えると「ナイーブ」フィルタリングの積極的なレベルを、適用します。
Typical: The stream suffers significant abuse issues and the organization has demonstrated a record of having difficulties resolving them in a timely manner, in spite of legitimate efforts. Unfortunately, this is the typical case for service providers with an easy and open subscription policy.
典型的な：ストリームは、重大な虐待の問題を受け、組織は、正当な努力にもかかわらず、タイムリーにそれらを解決する難しさを持っていることの記録を実証してきました。残念ながら、これは簡単で、オープンなサブスクリプションポリシーとサービスプロバイダのための典型的なケースです。
Protected: An organization with a good history and/or providing an important message stream for the receiving site is subject to a local policy that messages are not allowed to be blocked, but the stream is producing a problematic stream. The receiver delivers messages, but works quickly with the organization to resolve the matter.
保護：良い歴史を持つ組織および/または受信サイトのための重要なメッセージストリームを提供するには、メッセージがブロックされることが許可されていませんが、流れが問題ストリームを生成しているローカルポリシーが適用されます。受信機は、メッセージを配信しますが、問題を解決するための組織とすぐに動作します。
-----
Malicious: A persistently problematic message stream is coming from an organization that appears to contribute to the problem. The stream will be blocked, but the organization's role is sufficiently troubling to warrant following up with others in the anti-abuse or legal communities, to constrain or end their impact.
悪意のある：永続的に問題のあるメッセージストリームが問題に貢献するように見える組織から来ています。ストリームがブロックされますが、組織の役割は、その影響を制限または終了するには、抗乱用や法曹界で他の人のフォローアップを保証するために十分に厄介です。
Negligent: A persistently problematic message stream is coming from an organization that does not appear to be contributing to the problem, but also does not appear to be working to eliminate it. At the least, the stream needs to be blocked.
過失：永続的に問題のあるメッセージストリームは問題に貢献していないと思われるが、また、それを排除するために作業していないと思われる組織から来ています。少なくとも、ストリームがブロックされる必要があります。
Compromised: An organization with a good history has a stream that changes and becomes too problematic to be delivered. The receiver blocks the stream and works quickly with the organization to resolve the matter.
妥協：良い歴史を持つ組織が変更され、配信されるにはあまりにも問題となるストリームを持っています。受信機のブロックストリームとの問題を解決するために、組織とすぐに動作します。
By itself, verification of a digital signature only allows the verifier to conclude with a very high degree of certainty that the signature was created by a party with access to the corresponding private signing key. It follows that a verifier requires means to (1) obtain the public key for the purpose of verification and (2) infer useful attributes of the key holder.
単独で、デジタル署名の検証は、検証者が署名が対応する秘密署名鍵へのアクセス権を持つ者によって作成された確実性の非常に高いと結論することを可能にします。検証者は、（1）検証の目的のために公開鍵を取得するための手段を必要とし、（2）キーホルダーの有用な属性を推論することになります。
In a traditional Public Key Infrastructure (PKI), the functions of key distribution and key accreditation are separated. In DKIM [RFC4871], these functions are both performed through the DNS.
伝統的な公開鍵基盤（PKI）では、鍵配布とキー認定の機能が分離されています。 DKIM [RFC4871]において、これらの関数は両方のDNSを介して行われます。
In either case, the ability to infer semantics from a digital signature depends on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In a traditional PKI, a Trusted Third Party (TTP) vouches that the key holder has been validated with respect to a specified set of attributes. The range of attributes that can be attested in such a scheme is thus limited only to the type of attributes that a TTP can establish effective processes for validating. In DKIM, TTPs are not employed and the functions of key distribution and accreditation are combined.
いずれの場合も、デジタル署名から意味を推測する能力が対応する秘密鍵は、特定の属性セットを持つ当事者にのみアクセス可能であるという仮定に依存しています。伝統的なPKIでは、信頼できる第三者（TTP）は、鍵の所有者は、指定された属性のセットに関して検証されていることを保証します。このような方式で証明することができる属性の範囲は、このようにのみTTPを検証するための効果的なプロセスを確立することができる属性の種類に限定されます。 DKIMにおいて、TTPsが使用されず、鍵配布及び認定の機能が組み合わされています。
Consequently, there are only two types of inference that a signer can make from a key published in a DKIM key record:
その結果、署名者がDKIMキーレコードに掲載されたキーから作ることができる推論の唯一の2つの種類があります。
1. That a party with the ability to control DNS records within a DNS zone intends to claim responsibility for messages signed using the corresponding private signature key.
DNSゾーン内のDNSレコードを制御する能力を持つ当事者が対応する秘密署名鍵を使って署名されたメッセージの責任を主張しようとしていること1。
2. That use of a specific key is restricted to the particular subset of messages identified by the selector.
特定のキーの利用2.セレクタによって識別されるメッセージの特定のサブセットに制限されています。
The ability to draw any useful conclusion from verification of a digital signature relies on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In the case of DKIM, this means that the party that created the corresponding DKIM key record in the specific zone intended to claim responsibility for the signed message.
デジタル署名の検証から、任意の有用な結論を引き出す能力は、対応する秘密鍵は、特定の属性セットを持つ当事者にのみアクセス可能であるという仮定に依存しています。 DKIMの場合、これは特定のゾーンに対応するDKIMキーレコードを作成した当事者が署名されたメッセージの責任を請求することを意図していることを意味します。
Ideally, we would like to draw a stronger conclusion, that if we obtain a DKIM key record from the DNS zone example.com, that the legitimate holder of the DNS zone example.com claims responsibility for the signed message. In order for this conclusion to be drawn, it is necessary for the verifier to assume that the operational security of the DNS zone and corresponding private key are adequate.
理想的には、我々は、より強力な結論を引き出すしたいと我々はDNSゾーンexample.comの正当な所有者が署名されたメッセージの責任を主張していること、DNSゾーンexample.comからDKIMキーレコードを取得する場合。検証は、DNSゾーンの運用上のセキュリティと対応する秘密鍵が適切であると仮定するために描画されるこの結論ためには、それが必要です。
Access to signing keys needs to be carefully managed to prevent use by unauthorized parties and to minimize the consequences if a compromise were to occur.
署名鍵へのアクセスは慎重に権限のない者による使用を防ぐために妥協が発生した場合の影響を最小限にするために管理する必要があります。
While a DKIM signing key is used to sign messages on behalf of many mail users, the signing key itself needs to be under direct control of as few key holders as possible. If a key holder were to leave the organization, all signing keys held by that key holder need to be withdrawn from service and, if appropriate, replaced.
DKIM署名鍵は、多くのメールユーザーの代わりにメッセージを署名するために使用されますが、署名鍵自体は、できるだけ少ないキー所有者の直接の管理下にあることが必要です。キーホルダーが組織を残していた場合は、その鍵の所有者が保有するすべての署名キーは、サービスから撤退して、適切であれば、交換する必要があります。
If key management hardware support is available, it needs to be used. If keys are stored in software, appropriate file control protections need to be employed, and any location in which the private key is stored in plaintext form needs to be excluded from regular backup processes and is best not accessible through any form of network including private local area networks. Auditing software needs to be used periodically to verify that the permissions on the private key files remain secure.
鍵管理ハードウェアのサポートが利用可能な場合、それを使用する必要があります。キーがソフトウェアに保存されている場合は、適切なファイル管理の保護を採用する必要があり、秘密鍵が平文形式で格納されている任意の場所には、定期的なバックアッププロセスから除外する必要があり、プライベートローカルを含むネットワークの任意のフォームを介してアクセス可能な最善ではありませんエリアネットワーク。監査ソフトウェアは、秘密鍵ファイルのパーミッションが安全なままであることを確認するために定期的に使用する必要があります。
Wherever possible, a signature key needs to exist in exactly one location and be erased when no longer used. Ideally, a signature key pair needs to be generated as close to the signing point as possible, and only the public key component transferred to another party. If this is not possible, the private key needs to be transported in an encrypted format that protects the confidentiality of the signing key. A shared directory on a local file system does not provide adequate security for distribution of signing keys in plaintext form.
可能な限り、署名鍵は、厳密に1つの場所に存在する必要がもはや使用されない場合に消去されます。理想的には、署名鍵ペアは、可能な限り署名点に近く、別のパーティに転送のみ公開鍵成分として生成する必要があります。これが不可能な場合、秘密鍵は署名鍵の機密性を保護し、暗号化された形式で転送する必要があります。ローカルファイルシステム上の共有ディレクトリには、プレーンテキスト形式の署名鍵の配布のための十分なセキュリティを提供しません。
Key escrow schemes are not necessary and are best not used. In the unlikely event of a signing key becoming lost, a new signature key pair can be generated as easily as recovery from a key escrow scheme.
キーエスクロー制度は不要であり、最高使用されていません。署名鍵の万一の紛失になることに、新しい署名鍵ペアは、キーエスクロー制度からの回復と同じように簡単に生成することができます。
To enable accountability and auditing:
説明責任と監査を有効にするには：
o Responsibility for the security of a signing key needs to ultimately vest in a single named individual.
O署名鍵のセキュリティの責任は最終的に単一の名前付き個別に権利が確定する必要があります。
o Where multiple parties are authorized to sign messages, each signer needs to use a different key to enable accountability and auditing.
複数の当事者がメッセージに署名することを許可されている場合は、O、各署名者は説明責任と監査を有効にするために異なる鍵を使用する必要があります。
Best practices for management of cryptographic keying material require keying material to be refreshed at regular intervals, particularly where key management is achieved through software. While this practice is highly desirable, it is of considerably less importance than the requirement to maintain the secrecy of the corresponding private key. An operational practice in which the private key is stored in tamper-proof hardware and changed once a year is considerably more desirable than one in which the signature key is changed on an hourly basis but maintained in software.
暗号化キーイングマテリアルの管理のためのベスト・プラクティスは、鍵管理は、ソフトウェアによって実現され、特に定期的な間隔でリフレッシュするキーイング材料を必要としています。この練習は非常に望ましいが、それは対応する秘密鍵の機密性を維持するための要件よりもかなり少ない重要です。秘密鍵は耐タンパ性のハードウェアに保存され、年に一度変更した操作の練習は、かなり多くの望ましい署名鍵は時間ごとに変化しますが、ソフトウェアで維持されているものよりもあります。
In order to use DKIM, a DNS domain holder requires (1) the ability to create the necessary DKIM DNS records and (2) sufficient operational security controls to prevent insertion of spurious DNS records by an attacker.
DKIMを使用するために、DNSドメインホルダは、攻撃者が偽のDNSレコードの挿入を防止するために、（1）必要なDKIM DNSレコードを作成する機能と、（2）十分な運用上のセキュリティコントロールを必要とします。
DNS record management is often operated by an administrative staff that is different from those who operate an organization's email service. In order to ensure that DKIM DNS records are accurate, this imposes a requirement for careful coordination between the two operations groups. If the best practices for private key management described above are observed, such deployment is not a one-time event; DNS DKIM selectors will be changed over time as signing keys are terminated and replaced.
DNSレコードの管理は、多くの場合、組織の電子メールサービスを運用する人が異なる管理スタッフによって運営されています。 DKIM DNSレコードが正確であることを確実にするために、この2つの操作のグループ間の慎重な調整のための要件を課します。前述した秘密鍵管理のベストプラクティスが認められた場合には、このような展開は、1回限りのイベントではありません。署名鍵が終了し、交換されるDNSのDKIMセレクタは、時間の経過とともに変更されます。
At a minimum, a DNS server that handles queries for DKIM key records needs to allow the server administrators to add free-form TXT records. It would be better if the DKIM records could be entered using a structured form, supporting the DKIM-specific fields.
最低でも、DKIMキーレコードのクエリを処理するDNSサーバーは、サーバー管理者は、自由形式のTXTレコードを追加できるようにする必要があります。 DKIMレコードはDKIM-特定のフィールドをサポートし、構造化された形式を使用して入力することができれば良いだろう。
Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the case that NextSECure version 3 (NSEC3) [RFC5155] records are employed to prevent insertion attack, the OPT-OUT flag needs to be clear. (See [RFC5155] section 6 for details.)
理想的には、DNSセキュリティ（DNSSEC）[RFC4034]は、レコードの挿入攻撃とゾーン列挙に対する保護を提供した構成に採用する必要があります。 NextSECureバージョン3（NSEC3）[RFC5155]のレコードが挿入攻撃を防ぐために使用される場合においては、オプトアウトフラグをクリアする必要があります。 （詳細については[RFC5155]セクション6を参照）。
Selectors are assigned according to the administrative needs of the signing domain, such as for rolling over to a new key or for the delegation of the right to authenticate a portion of the namespace to a TTP. Examples include:
セレクタは、このような新しいキーまたはTTPに名前空間の一部を認証するための権利の委任に寝返り用として署名ドメインの管理上の必要に応じて割り当てられます。例としては、
jun2005.eng._domainkey.example.com
じゅん２００５。えんｇ。＿どまいんけｙ。えぁｍｐぇ。こｍ
widget.promotion._domainkey.example.com
うぃｄげｔ。ｐろもちおん。＿どまいんけｙ。えぁｍｐぇ。こｍ
It is intended that assessments of DKIM identities be based on the domain name, and not include the selector. While past practice of a signer can permit a verifier to infer additional properties of particular messages from the structure DKIM key selector, unannounced administrative changes such as a change of signing software can cause such heuristics to fail at any time.
DKIMのアイデンティティの評価がドメイン名に基づいて、セレクタを含まないことが意図されています。署名者の過去の練習は、構造DKIMキーセレクタから特定のメッセージの追加のプロパティを推測するために検証を許可することができるが、このような署名ソフトウェアの変更など抜き打ち管理上の変更は、そのような経験則は、任意の時点で失敗する可能性があります。
While a signer can establish business rules, such as the issue of individual signature keys for each end-user, DKIM makes no provision for communicating these to other parties. Out-of-band distribution of such business rules is outside the scope of DKIM. Consequently, there is no means by which external parties can make use of such keys to attribute messages with any greater granularity than a DNS domain.
署名者は、ビジネスルールを確立することができますが、このような各エンドユーザーのための個々の署名鍵の問題として、DKIMは、他の当事者にこれらを伝達するための規定を行いません。このようなビジネスルールのアウトオブバンド分布は、DKIMの範囲外です。その結果、外部の関係者は、DNSドメインよりも任意の大きい粒度でメッセージを帰するような鍵を使用することができたことにより、手段がありません。
If per-user signing keys are assigned for internal purposes (e.g., authenticating messages sent to an MTA (Mail Transfer Agent) for distribution), the following issues need to be considered before using such signatures as an alternative to traditional edge signing at the outbound MTA:
ユーザごとの署名キーが（例えば、配布用のMTA（メール転送エージェント）に送信されるメッセージを認証する）内部目的のために割り当てられている場合は、次の問題は、アウトバウンドでの伝統的なエッジの署名に代わるものとして、このような署名を使用する前に検討する必要がありますMTA：
External verifiers will be unable to make use of the additional signature granularity without access to additional information passed out of band with respect to [RFC4871].
外部検証は、[RFC4871]に対して帯域外渡される追加情報にアクセスすることなく、追加の署名粒度を利用することができません。
If the number of user keys is large, the efficiency of local caching of key records by verifiers will be lower.
ユーザーキーの数が多い場合には、検証者がキーレコードのローカルキャッシュの効率は低くなります。
A large number of end users is be less likely to do an adequate job of managing private key data securely on their personal computers than is an administrator running an edge MTA.
エンドユーザーの大多数は、エッジMTAを実行している管理者であるよりも、しっかりと自分のパソコン上の秘密鍵データを管理するのに十分な仕事をする可能性が低いことです。
A DKIM key record only asserts that the holder of the corresponding domain name makes a claim of responsibility for messages signed under the corresponding key. In some applications, such as bulk mail delivery, it is desirable to delegate use of the key. That is, to allow a third party to sign on behalf of the domain holder. The trust relationship is still established between the domain holder and the verifier, but the private signature key is held by a third party.
DKIMキーレコードは、対応するドメイン名の所有者が対応するキーの下に署名されたメッセージに対する責任の請求をすることを主張します。バルクメール配信など一部のアプリケーションでは、キーの使用を委任することが望ましいです。つまり、第三者がドメイン所有者を代表して署名することを可能にします。信頼関係がまだドメインの所有者と検証の間に確立されていますが、秘密署名鍵は、第三者によって保持されています。
Signature keys used by a third-party signer need to be kept entirely separate from those used by the domain holder and other third-party signers. To limit potential exposure of the private key, the signature key pair needs to be generated by the third-party signer and the public component of the key transmitted to the domain holder, rather than have the domain holder generate the key pair and transmit the private component to the third-party signer.
サードパーティの署名者によって使用される署名鍵は、ドメイン所有者と他のサードパーティの署名者によって使用されるものとは完全に別個に維持される必要があります。秘密鍵の潜在的な暴露を制限するために、署名鍵ペアは、サードパーティの署名者とドメインホルダに送信される鍵の公開コンポーネントによって生成される必要はなく、ドメイン・ホルダーは、鍵のペアを生成し、プライベートを送信していますサードパーティの署名者へのコンポーネント。
Domain holders needs to adopt a least-privilege approach and grant third-party signers the minimum access necessary to perform the desired function. Limiting the access granted to third-party signers serves to protect the interests of both parties. The domain holder minimizes its security risk and the TTP signer avoids unnecessary liability.
ドメイン所有者は、最小特権のアプローチを採用し、所望の機能を実行するために、サードパーティの署名者に必要な最小限のアクセス権を付与する必要があります。サードパーティの署名者に許可されるアクセスを制限することは、両当事者の利益を保護するのに役立ちます。ドメインの所有者は、そのセキュリティリスクを最小限に抑え、TTPの署名者は、不要な責任を回避することができます。
In the most restrictive case, domain holders maintain full control over the creation of key records. They can employ appropriate key record restrictions to enforce limits on the messages for which the third-party signer is able to sign. If such restrictions are impractical, the domain holder needs to delegate a DNS subzone for publishing key records to the third-party signer. It is best that the domain holder NOT allow a third-party signer unrestricted access to its DNS service for the purpose of publishing key records.
最も制限の場合には、ドメインの所有者は、キーレコードの作成を完全に制御を維持します。彼らは、サードパーティの署名者が署名することがあるため、メッセージの制限を強制するために、適切なキーレコードの制限を採用することができます。そのような制限は実用的ではない場合は、ドメインの所有者は、サードパーティの署名者にキーレコードを公開するためのDNSサブゾーンを委任する必要があります。これは、ドメインの所有者がキーレコードを公開する目的で、そのDNSサービスへのサードパーティの署名者の無制限のアクセスを許可しないことが最善です。
Deployments need to establish, document, and observe processes for managing the entire life cycle of an asymmetric key pair.
展開は、文書を確立し、非対称鍵ペアのライフサイクル全体を管理するためのプロセスを観察する必要があります。
When it is determined that a new key pair is required:
新しい鍵ペアが必要であると判断された場合：
2. A proposed key selector record is generated and transmitted to the DNS administration infrastructure.
2.提案されたキーセレクターレコードが生成され、DNS管理インフラストラクチャに送信されます。
3. The DNS administration infrastructure verifies the authenticity of the key selector registration request. If accepted:
3. DNS管理インフラストラクチャは、キーセレクタ登録要求の正当性を検証します。受け入れた場合：
6. The signer terminates any private keys that are no longer required due to issue of replacement.
6.署名者は、もはやによる交換の問題に必要とされる任意の秘密鍵を終了します。
When it is determined that a private signature key is no longer required:
秘密署名鍵はもはや必要であると判断されていない場合：
2. The signer deletes all records of the private key, including in-memory copies at the signing device.
2.署名者は、署名装置のメモリ内のコピーを含む、秘密鍵のすべてのレコードを削除します。
3. The signer notifies the DNS administration infrastructure that the signing key is withdrawn from service and that the corresponding key records can be withdrawn from service at a specified future date.
3.署名者は、署名鍵をサービスから、対応するキーのレコードが指定された将来の日付でサービスから引き出すことができることが引き抜かれるDNS管理インフラストラクチャに通知します。
4. The DNS administration infrastructure verifies the authenticity of the key selector termination request. If accepted,
4. DNS管理インフラストラクチャは、キーセレクタ終了要求の正当性を検証します。受け入れた場合、
1. The key selector is scheduled for deletion at a future time
determined by site policy.
3. The signer either publishes a revocation key selector with an empty public-key data (p=) field, or deletes the key selector record entirely.
3.署名者は、空の公開鍵データ（P =）フィールドと失効キーセレクタを発行し、または完全にキーセレクタレコードを削除いずれか。
5. As far as the verifier is concerned, there is no functional difference between verifying against a key selector with an empty p= field, and verifying against a missing key selector: both result in a failed signature and the signature needs to be treated as if it had not been there. However, there is a minor semantic difference: with the empty p= field, the signer is explicitly stating that the key has been revoked. The empty p= record provides a gravestone for an old selector, making it less likely that the selector might be accidentally reused with a different public key.
5.限り検証に関しては、空のP =フィールドを持つキーセレクタに対して検証、および欠落キーセレクタに対して検証の間には機能的な違いは存在しない：失敗署名における結果と署名の両方がとして処理する必要がありますそれはそこにいなかった場合。空のp =フィールドで、署名者が明示的にキーが取り消されたことを知らせるされています。しかし、マイナーなセマンティック違いがあります。空のpは=レコードはセレクタが誤って別の公開鍵で再利用されるかもしれないという可能性が低くなって、昔のセレクタのための墓石を提供します。
Creating messages that have one or more DKIM signatures requires support in only two outbound email service components:
一つ以上のDKIM署名を持つメッセージを作成することは2つだけアウトバウンド電子メールサービスコンポーネントでのサポートが必要です。
o A DNS Administrative interface that can create and maintain the relevant DNS names -- including names with underscores -- and resource records (RR).
Oを作成し、関連するDNS名を維持することができるDNS管理インターフェース - とリソースレコード（RR） - アンダースコアと名前を含みます。
o A trusted module, called the signing module, which is within the organization's outbound email handling service and which creates and adds the DKIM-Signature: header field(s) to the message.
メッセージにヘッダフィールド（複数可）：トラステッドモジュールO、組織のアウトバウンド電子メール処理サービス内にあり、これは、DKIM-署名を作成し、追加署名モジュールと呼ばれます。
If the module creates more than one signature, there needs to be the appropriate means of telling it which one(s) to use. If a large number of names are used for signing, it will help to have the administrative tool support a batch-processing mode.
モジュールは、複数の署名を作成した場合、どちらの（S）を使用するように指示する適切な手段が必要です。名前の多数は署名に使用されている場合は、管理ツールは、バッチ処理モードをサポートして持っているのに役立ちます。
A receiver attempting to verify a DKIM signature obtains the public key that is associated with the signature for that message. The DKIM-Signature: header in the message contains the d= tag with the basic domain name doing the signing and serving as output to the Identity Assessor and the s= tag with the selector that is added to the name, for finding the specific public key. Hence, the relevant <selector>._domainkey.<domain-name> DNS record needs to contain a DKIM-related RR that provides the public key information.
DKIM署名を検証しようとする受信機は、そのメッセージの署名に関連付けられている公開鍵を取得します。 DKIM-署名が：メッセージのヘッダーは、基本的なドメイン名を持つD =タグが署名を行うと、身元評価と名前に追加されるセレクタと、S =タグへの出力として含まれ、特定の公開を求めますキー。したがって、関連する<セレクタ> ._ domainkey。<ドメイン名> [DNSレコードは、公開鍵の情報を提供してDKIM関連RRが含まれている必要があります。
The administrator of the zone containing the relevant domain name adds this information. Initial DKIM DNS information is contained within TXT RRs. DNS administrative software varies considerably in its abilities to support DKIM names, such as with underscores, and to add new types of DNS information.
関連するドメイン名を含むゾーンの管理者は、この情報を追加します。初期DKIM DNS情報は、TXT RRの中に含まれています。 DNS管理ソフトウェアは、アンダースコアと同様にDKIM名を、サポートするために、およびDNS情報の新しいタイプを追加するために、その能力に大きく変化します。
The module doing signing can be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); obvious choices include department-level posting agents, as well as outbound boundary MTAs to the open Internet. However, any other module, including the author's MUA (Mail User Agent), is potentially acceptable, as long as the signature survives any remaining handling within the ADMD. Hence, the choice among the modules depends upon software development, administrative overhead, security exposures, and transit-handling tradeoffs. One perspective that helps to resolve this choice is the difference between the increased flexibility, from placement at (or close to) the MUA, versus the streamlined administration and operation that is more easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure, such as at its boundary MTA.
署名をしているモジュールは、組織の信頼される行政管理ドメイン（ADMD）内の任意の場所に配置することができます。明白な選択肢は、部門レベルの投稿剤としてだけでなく、オープンなインターネットへのアウトバウンド境界のMTAが含まれます。しかし、著者のMUA（メールユーザエージェント）を含む他のモジュールは、限り署名が残っADMD内取り扱い生き残ったように、潜在的に許容可能です。したがって、モジュール間の選択は、ソフトウェア開発、管理オーバーヘッド、セキュリティ・エクスポージャー、およびトランジット取扱トレードオフに依存します。この選択を解決するのに役立ちます一つの視点は、より簡単に、組織の電子メールインフラストラクチャにメカニズム「深い」を実施することによって得られる合理化、管理および操作に対して、MUAで（またはそれに近い）配置から増加した柔軟性の違いであり、 、その境界MTAのような。
Note the discussion in Section 2.2 concerning the use of the i= tag.
I =タグの使用に関するセクション2.2での議論に注意してください。
The signing module uses the appropriate private key to create one or more signatures. (See Section 6.5 for a discussion of multiple signatures.) The means by which the signing module obtains the private key(s) is not specified by DKIM. Given that DKIM is intended for use during email transit, rather than for long-term storage, it is expected that keys will be changed regularly. For administrative convenience, it is best not to hard-code key information into software.
署名モジュールは、1つまたは複数の署名を作成するための適切な秘密鍵を使用しています。 （複数の署名の議論については、セクション6.5を参照。）署名モジュールは、DKIMによって指定されていない秘密鍵（単数または複数）を取得する手段です。 DKIMは、電子メールの輸送時に使うことを意図していることを考えると、むしろ長期保存のためよりも、キーは定期的に変更されることが期待されます。行政便宜上、それがソフトウェアにハードコードキー情報にないことをお勧めします。
Every organization (ADMD) will have its own policies and practices for deciding when to sign messages (message stream) and with what domain name, selector, and key. Examples of particular message streams include all mail sent from the ADMD versus mail from particular types of user accounts versus mail having particular types of content. Given this variability, and the likelihood that signing practices will change over time, it will be useful to have these decisions represented through run-time configuration information, rather than being hard-coded into the signing software.
すべての組織（ADMD）は、メッセージ（メッセージ・ストリーム）とどのようなドメイン名、セレクタ、およびキーでの署名する際に決定するための独自の政策や慣行を持つことになります。特定のメッセージの流れの例としては、コンテンツの特定のタイプを有する電子メールに対してユーザアカウントの特定の種類からのメールに対してADMDから送信されたすべてのメールを含みます。この変動、および署名慣行が時間の経過とともに変化する可能性を考えると、むしろ、署名ソフトウェアにハードコーディングされているよりも、実行時の設定情報によって示され、これらの決定を持つことが有用であろう。
As noted in Section 2.3, the choice of signing name granularity requires balancing administrative convenience and utility for recipients. Too much granularity is higher administrative overhead and might well attempt to impose more differential analysis on the recipient than they wish to support. In such cases, they are likely to use only a super-name -- right-hand substring -- of the signing name. When this occurs, the signer will not know what portion is being used; this then moves DKIM back to the non-deterministic world of heuristics, rather than the mechanistic world of signer/recipient collaboration that DKIM seeks.
2.3節で述べたように、名前の粒度を署名の選択は、受信者の管理の利便性と有用性のバランスをとる必要となります。あまりにも多くの粒度が高く、管理オーバーヘッドで、よく、彼らがサポートしたいよりも、受信者に多くの微分解析を課すことをしようとするかもしれません。右側のサブ - - 署名の名前のような場合には、彼らは唯一の超名を使用する可能性があります。これが発生すると、署名者は、使用されているどの部分を知ることができません。これは、むしろ、DKIMが求める署名者/受信者の協働のメカニズムの世界よりも、ヒューリスティックの非決定論的世界に戻ってDKIMを移動します。
A message recipient can verify a DKIM signature to determine if a claim of responsibility has been made for the message by a trusted domain.
メッセージ受信者は、責任の請求は、信頼できるドメインがメッセージのために作られているかどうかを決定するためにDKIM署名を検証することができます。
Access control requires two components: authentication and authorization. By design, verification of a DKIM signature only provides the authentication component of an access control decision and needs to be combined with additional sources of information such as reputation data to arrive at an access control decision.
認証および承認：アクセス制御は、2つのコンポーネントが必要です。設計により、DKIM署名の検証は、アクセス制御決定の認証コンポーネントを提供し、アクセス制御決定に到達するために、このような評判のデータなどの情報を追加ソースと組み合わせることが必要です。
DKIM requires that a message with a signature that is found to be invalid is to be treated as if the message had not been signed at all.
DKIMは、メッセージがまったく署名されていなかったかのように無効であることが判明した署名付きメッセージを処理すべきであることを必要とします。
If a DKIM signature fails to verify, it is entirely possible that the message is valid and that either there is a configuration error in the signer's system (e.g., a missing key record) or that the message was inadvertently modified in transit. It is thus undesirable for mail infrastructure to treat messages with invalid signatures less favorably than those with no signatures whatsoever. Contrariwise, creation of an invalid signature requires a trivial amount of effort on the part of an attacker. If messages with invalid signatures were to be treated preferentially to messages with no signatures whatsoever, attackers will simply add invalid signature blocks to gain the preferential treatment. It follows that messages with invalid signatures need to be treated no better and no worse than those with no signature at all.
DKIM署名が検証に失敗した場合、そのメッセージが有効であり、いずれの構成の署名者のシステムにエラー（例えば、欠けているキーレコード）またはメッセージが誤って転送中に変更されたことがあることであることが完全に可能です。メールインフラストラクチャはあまり好意的に一切のシグネチャを持つものより無効な署名とメッセージを治療することは好ましくないです。これに反し、無効な署名の作成は、攻撃者の一部に努力の些細な量を必要とします。無効な署名付きのメッセージは一切の署名付きのメッセージに優先的に扱われることをした場合、攻撃者は、単に優遇措置を得るために、無効な署名のブロックを追加します。無効な署名付きのメッセージが何より良い治療する必要はないとまったく署名を持つものよりも悪化していることは以下。
As with any other digital signature scheme, verifiers need to consider only the part of the message that is inside the scope of the message as being authenticated by the signature.
他のデジタル署名方式と同様に、検証者は、署名によって認証されるように、メッセージの範囲内にあるメッセージの一部のみを考慮する必要があります。
For example, if the l= option is employed to specify a content length for the scope of the signature, only the part of the message that is within the scope of the content signature would be considered authentic.
L =オプションは、署名の範囲のコンテンツ長を指定するために使用される場合、例えば、コンテンツの署名の範囲内にあるメッセージの一部のみが本物であると考えられます。
Public key cryptography provides an exceptionally high degree of assurance, bordering on absolute certainty, that the party that created a valid digital signature had access to the private key corresponding to the public key indicated in the signature.
公開鍵暗号方式は、有効なデジタル署名を作成した当事者が署名に示されている公開鍵に対応する秘密鍵へのアクセスを持っていたことを、絶対的な確信を境に、保証の非常に高度を提供します。
In order to make useful conclusions from the verification of a valid digital signature, the verifier is obliged to make assumptions that fall far short of absolute certainty. Consequently, mere validation of a DKIM signature does not represent proof positive that a valid claim of responsibility was made for it by the indicated party, that the message is authentic, or that the message is not abusive. In particular:
有効なデジタル署名の検証に有用な結論を出すために、検証者は、絶対的な確実性のはるかに及ばないの仮定を行うことが義務付けられています。そのため、DKIM署名の単なる検証は、責任の有効な請求は、メッセージが本物であること、またはメッセージが虐待ではないことを、示された当事者によってそれのために作られたという肯定的証拠を示すものではありません。特に：
o The legitimate private key holder might have lost control of its private key.
O正当な秘密鍵の所有者は、その秘密鍵のコントロールを失っているかもしれません。
o The legitimate domain holder might have lost control of the DNS server for the zone from which the key record was retrieved.
O正当なドメイン所有者は、キーレコードが取得されたゾーンのDNSサーバのコントロールを失っているかもしれません。
o The key record might not have been delivered from the legitimate DNS server for the zone from which the key record was retrieved.
Oキーレコードは、キーレコードが取得されたゾーンの正当なDNSサーバから配信されていない可能性があります。
o Ownership of the DNS zone might have changed.
O DNSゾーンの所有権が変更されている場合があります。
In practice, these limitations have little or no impact on the field of use for which DKIM is designed, but they can have a bearing if use is made of the DKIM message signature format or key retrieval mechanism in other specifications.
実際には、これらの制限は、DKIMが設計される用途の分野にほとんど又は全く影響を有するが、使用は、他の仕様のDKIMメッセージ署名フォーマットまたはキー検索機構で構成されている場合、それらは、軸受を有することができます。
In particular, the DKIM key retrieval mechanism is designed for ease of use and deployment rather than to provide a high assurance Public Key Infrastructure suitable for purposes that require robust non-repudiation such as establishing legally binding contracts. Developers seeking to extend DKIM beyond its design application need to consider replacing or supplementing the DNS key retrieval mechanism with one that is designed to meet the intended purposes.
特に、DKIMキーの検索機構は、このような法的拘束力のある契約を確立するよう強固な否認防止を必要とする用途に適した高保証公開鍵インフラストラクチャを提供するのではなく、使用と展開を容易にするために設計されています。その設計アプリケーションを超えてDKIMを拡張しようとしている開発者は、所期の目的を満たすように設計されたものでDNSキー検索機構を交換するか、補完を検討する必要があります。
DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources. Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message.
DKIMは、しばしば、信頼できる送信元からのメールにコンテンツ分析の実行を回避するために、メールのフィルタリング戦略に採用されています。信頼できるソースから有効なDKIM署名を運ぶメッセージは、メッセージの配置を決定するために計算ひいてはエネルギー集約コンテンツ分析を実行する必要性を回避し、ホワイトリストに登録することができます。
Mail sources can be determined to be trusted by means of previously observed behavior and/or reference to external reputation or accreditation services. The precise means by which this is accomplished is outside the scope of DKIM.
メールソースは、以前に観察された行動および/または外部の評判や認定サービスへの参照を用いて、信頼されるように判断することができます。これが達成される正確な手段は、DKIMの範囲外です。
Adaptive (or learning) spam filtering mechanisms that are not capable of verifying DKIM signatures need to, at minimum, be configured to ignore DKIM header data entirely.
DKIM署名を検証することができない適応（または学習）スパムフィルタリング機構は、最低でも、完全にDKIMヘッダデータを無視するように構成する必要があります。
Intermediaries, such as mailing lists, pose a particular challenge for DKIM implementations, as the message processing steps performed by the intermediary can cause the message content to change in ways that prevent the signature passing verification.
仲介によって行われるメッセージ処理ステップが検証を通過署名を防ぐ方法で変更するためにメッセージコンテンツを引き起こすことができるようなメーリングリストなどの仲介が、DKIMの実装のための特定の課題をもたらします。
Such intermediaries are strongly encouraged to deploy DKIM signing so that a verifiable claim of responsibility remains available to parties attempting to verify the modified message.
このような仲介を強く責任の検証可能な請求が変更されたメッセージを確認しようとする者に利用可能のままであるようにDKIM署名を展開することをお勧めします。
In many deployments, it is desirable to separate signature verification from the application relying on the verification. A system can choose to relay information indicating the results of its message authentication efforts using various means; adding a "results header" to the message is one such mechanism [RFC5451]. For example, consider the cases where:
多くの展開では、検証に依存するアプリケーションの署名検証を分離することが望ましいです。システムは、様々な手段を使用してメッセージ認証の努力の結果を示す情報を中継することを選択できます。メッセージに「結果ヘッダ」を追加することは、1つのそのようなメカニズム[RFC5451]です。例えば、どこのケースを考えてみます。
o The application relying on DKIM signature verification is not capable of performing the verification.
O DKIM署名の検証に依存するアプリケーションは、検証を行うことができません。
o The message can be modified after the signature verification is performed.
署名検証が実行された後、Oメッセージを修正することができます。
o The signature key cannot be available by the time that the message is read.
O署名鍵は、メッセージが読み取られる時点で利用可能にすることはできません。
In such cases, it is important that the communication link between the signature verifier and the relying application be sufficiently secure to prevent insertion of a message that carries a bogus results header.
このような場合には、署名検証と依存するアプリケーションとの間の通信リンクは、偽の結果のヘッダを運ぶメッセージの挿入を防止するために十分に安全であることが重要です。
An intermediary that generates results headers need to ensure that relying applications are able to distinguish valid results headers issued by the intermediary from those introduced by an attacker. For example, this can be accomplished by signing the results header. At a minimum, results headers on incoming messages need to be removed if they purport to have been issued by the intermediary but cannot be verified as authentic.
結果ヘッダを生成し、仲介を頼って、アプリケーションが攻撃者によって導入されたものからの仲介によって発行された有効な結果ヘッダを区別することができることを確認する必要があります。例えば、これは、結果のヘッダに署名することによって達成することができます。最低でも、彼らは仲介によって発行されたと主張するが、本物と確認できない場合は、受信メッセージのヘッダを除去する必要がある結果。
Further discussion on trusting the results as relayed from a verifier to something downstream can be found in [RFC5451].
下流[RFC5451]に見出すことができるものにベリファイアから中継されたような結果を信頼するにさらに議論。
As described in Section 2.1, a DKIM signature tells the signature verifier that the owner of a particular domain name accepts some responsibility for the message. It does not, in and of itself, provide any information about the trustworthiness or behavior of that identity. What it does provide is a verified identity to which such behavioral information can be associated, so that those who collect and use such information can be assured that it truly pertains to the identity in question.
セクション2.1で説明したように、DKIM署名は、特定のドメイン名の所有者がメッセージのためのいくつかの責任を負い、署名検証者に通知します。それは、それ自体が、そのアイデンティティの信頼性や動作に関する情報を提供していません。収集し、これらの情報を利用する人は、それは本当に問題のアイデンティティに関係することを保証することができますように、それは何を提供することはない、そのような行動情報が関連付け可能な検証のアイデンティティです。
This section lays out a taxonomy of some of the different identities, or combinations of identities, that might usefully be represented by a DKIM signature.
このセクションでは、有用DKIM署名で表されるかもしれない異なる同一、または同一の組み合わせのいくつかの分類をレイアウト。
Perhaps the simplest case is when an organization signs its own outbound email using its own domain in the SDID [RFC5672] of the signature. For example, Company A would sign the outbound mail from its employees with d=companyA.example.
組織は、署名のSDID [RFC5672]で独自のドメインを使用して、自身の送信メールに署名する際におそらく最も単純なケースです。例えば、A社がD = companyA.exampleとその従業員からの送信メールに署名するだろう。
In the most straightforward configuration, the addresses in the RFC5322.From field would also be in the companyA.example domain, but that direct correlation is not required.
最も単純な構成では、RFC5322.FromフィールドのアドレスもcompanyA.exampleドメインに存在するだろうが、その直接的な相関関係は必要ありません。
A special case of the single domain signature is an author signature as defined by the Author Domain Signing Practices specification [RFC5617]. Author signatures are signatures from an author's organization that have an SDID value that matches that of an RFC5322.From address of the signed message.
著者ドメイン署名プラクティス仕様[RFC5617]で定義されるような単一ドメイン署名の特別な場合は、作成者の署名です。著者の署名は、署名されたメッセージのRFC5322.Fromアドレスのことと一致するSDID値を持つ著者の組織から署名されています。
Although an author signature might, in some cases, be proof against spoofing the domain name of the RFC5322.From address, it is important to note that the DKIM and ADSP validation apply only to the exact address string and not to look-alike addresses or to the human-friendly "display-name" or names and addresses used within the body of the message. That is, it only protects against the misuse of a precise address string within the RFC5322.From field and nothing else. For example, a message from bob@domain.example with a valid signature where d=d0main.example would fail an ADSP check because the signature domain, however similar, is distinct; however, a message from bob@d0main.example with a valid signature where d=d0main.example would pass an ADSP check, even though to a human it might be obvious that d0main.example is likely a malicious attempt to spoof the domain domain.example. This example highlights that ADSP, like DKIM, is only able to validate a signing identifier: it still requires some external process to attach a meaningful reputation to that identifier.
著者署名は、いくつかのケースでは、RFC5322.Fromアドレスのドメイン名をスプーフィングに対する証拠かもしれませんが、それはDKIMとADSP検証が正確なアドレス文字列にのみ適用されることに注意することが重要であるとしないそっくりアドレスまたは人間に優しい「表示名」またはメッセージの本文内で使用される名前とアドレスへ。それはそれだけでRFC5322.Fromフィールドと他には何も内の正確なアドレス文字列の悪用に対する保護、です。例えば、しかし同様の署名ドメインは、別個のものであるので、D = d0main.exampleはADSPチェックに失敗する有効な署名付きbob@domain.exampleからのメッセージ。ただし、D = d0main.exampleは人間にd0main.example可能性が高いドメインドメインを偽装する悪質な試みであることは明らかであるかもしれないにもかかわらず、ADSPチェックを通過する有効な署名とbob@d0main.exampleからのメッセージ。例。この例ではADSPは、DKIMのように、唯一の署名識別子を検証することが可能であることを強調して：それはまだその識別子に意味の評判を接続するために、いくつかの外部プロセスが必要です。
Another approach that might be taken by an organization with multiple active subdomains is to apply the same (single) signature domain to mail from all subdomains. In this case, the signature chosen would usually be the signature of a parent domain common to all subdomains. For example, mail from marketing.domain.example, sales.domain.example, and engineering.domain.example might all use a signature where d=domain.example.
複数のアクティブなサブドメインを持つ組織によって取られるかもしれない別のアプローチは、すべてのサブドメインから郵送する同じ（単一）ドメイン署名を適用することです。この場合、選ばれた署名は、通常、すべてのサブドメインに共通の親ドメインの署名になります。例えば、marketing.domain.exampleからメール、sales.domain.example、及びengineering.domain.exampleすべてD = domain.example署名を使用するかもしれません。
This approach has the virtue of simplicity, but it is important to consider the implications of such a choice. As discussed in Section 2.3, if the type of mail sent from the different subdomains is significantly different or if there is reason to believe that the reputation of the subdomains would differ, then it can be a good idea to acknowledge this and provide distinct signatures for each of the subdomains (d=marketing.domain.example, sales.domain.example, etc.). However, if the mail and reputations are likely to be similar, then the simpler approach of using a single common parent domain in the signature can work well.
このアプローチは、シンプルさの美徳を持っていますが、そのような選択の影響を考慮することが重要です。 2.3節で述べたように異なるサブドメインから送信されたメールの種類が大幅に異なる場合、またはサブドメインの評判が異なるだろうと信じる理由がある場合、このことを認識し、ための明確なシグネチャを提供することをお勧めすることができサブドメイン（D = marketing.domain.example、sales.domain.example、等）のそれぞれ。メールや評判が同様である可能性が高い場合には、その後、署名に単一の共通の親ドメインを使用しての簡単な方法はうまく機能することができます。
Another approach to distinguishing the streams using a single DKIM key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM signature to differentiate the mail streams. For example, marketing email would be signed with i=@marketing.domain.example and d=domain.example.
単一DKIMキーを使用してストリームを区別するための別のアプローチは、メールストリームを区別するためにDKIM署名にAUID [RFC5672]（I =タグ）を活用することであろう。例えば、マーケティングメールはi=@marketing.domain.exampleと、d = domain.exampleで署名されるだろう。
It's important to remember, however, that under core DKIM semantics, the AUID is opaque to receivers. That means that it will only be an effective differentiator if there is an out-of-band agreement about the i= semantics.
これは、コアDKIMセマンティクスの下で、AUIDは、受信機に不透明であること、しかし、覚えておくことが重要です。それは私=セマンティクスについてのアウトオブバンド合意がある場合にのみ有効に差別することを意味します。
A signature whose domain does not match the domain of the RFC5322.From address is sometimes referred to as a third-party signature. In certain cases, even the parent domain signature described above would be considered a third-party signature because it would not be an exact match for the domain in the RFC5322.From address.
そのドメインRFC5322.Fromアドレスのドメインと一致しない署名は、時々、サードパーティの署名と呼ばれます。それはRFC5322.Fromアドレスのドメインの完全一致ではないので、ある場合には、上述も親ドメイン署名は、サードパーティの署名と考えられます。
Although there is often heated debate about the value of third party signatures, it is important to note that the DKIM specification attaches no particular significance to the identity in a DKIM signature ([RFC4871], [RFC5672]). The identity specified within the signature is the identity that is taking responsibility for the message, and it is only the interpretation of a given receiver that gives one identity more or less significance than another. In particular, most independent reputation services assign trust based on the specific identifier string, not its "role": in general they make no distinction between, for example, an author signature and a third-party signature.
多くの場合、サードパーティ署名の値についての議論が加熱されるが、それはDKIM仕様はDKIM署名で識別には特に意味を付加しないことに留意することが重要である（[RFC4871]、[RFC5672]）。署名内に指定されたIDは、メッセージのための責任を取って同一であり、これは、1個の以上の同一又は別未満の意味を与える所与の受信機の唯一の解釈です。具体的には、ほとんどの独立したレピュテーションサービスは、特定の識別子の文字列ではなく、その「役割」に基づく信頼を割り当てる：一般的に、彼らは、例えば、著者の署名およびサードパーティの署名、を区別しません。
For some, a signature unrelated to the author domain (the domain in the RFC5322.From address) is less valuable because there is an assumption that the presence of an author signature guarantees that the use of the address in the RFC5322.From header is authorized.
作成者署名の存在はRFC5322.Fromヘッダ内のアドレスの使用が許可されていることを保証するという前提があるため、いくつかのために、著者ドメインとは無関係署名（RFC5322.Fromアドレスのドメイン）が少なく貴重です。
For others, that relevance is tied strictly to the recorded behavioral data assigned to the identity in question, i.e., its trust assessment or reputation. The reasoning here is that an identity with a good reputation is unlikely to maintain that good reputation if it is in the habit of vouching for messages that are unwanted or abusive; in fact, doing so will rapidly degrade its reputation so that future messages will no longer benefit from it. It is therefore low risk to facilitate the delivery of messages that contain a valid signature of a domain with a strong positive reputation, independent of whether or not that domain is associated with the address in the RFC5322.From header field of the message.
他の人のために、その関連性は、問題のアイデンティティ、すなわち、その信頼性評価や評判に割り当てられた記録の行動データに厳密に結びついています。ここでの推論は良い評判とアイデンティティは、それが不要か、虐待されているメッセージについてバウチングの習慣である場合には良い評判を維持する可能性は低いということです。今後のメッセージは、もはやそこから利益を得ないだろうように、実際には、そうすることは、急速にその評判を低下させます。したがって、そのドメインがメッセージのRFC5322.Fromヘッダフィールドのアドレスに関連付けられているか否かとは無関係に強い正の定評のあるドメインの有効な署名を含むメッセージの配信を容易にするための低リスクです。
Third-party signatures encompass a wide range of identities. Some of the more common are:
サードパーティの署名は、アイデンティティの広い範囲を包含する。より一般的なのいくつかは、次のとおりです。
Service Provider: In cases where email is outsourced to an Email Service Provider (ESP), Internet Service Provider (ISP), or other type of service provider, that service provider can choose to DKIM-sign outbound mail with either its own identifier -- relying on its own, aggregate reputation -- or with a subdomain of the provider that is unique to the message author but still part of the provider's aggregate reputation. Such service providers can also encompass delegated business functions such as benefit management, although these will more often be treated as trusted third-party senders (see below).
サービスプロバイダーは：電子メールがメールサービスプロバイダ（ESP）に委託された場合、インターネットサービスプロバイダ（ISP）、またはサービスプロバイダの他のタイプでは、そのサービスプロバイダは、自身の識別子のいずれかとDKIM-記号アウトバウンドメールに選択することができます - またはメッセージの作成者が、まだプロバイダの集約評判の一部に固有のプロバイダのサブドメインで - 独自の、集計評判に頼ります。これらは、より頻繁に、信頼できるサードパーティの送信者（下記参照）として扱われますが、このようなサービスプロバイダーはまた、利益管理などの委任ビジネス機能を包含することができます。
Parent Domain: As discussed above, organizations choosing to apply a parent-domain signature to mail originating from subdomains can have their signatures treated as third party by some verifiers, depending on whether or not the "t=s" tag is used to constrain the parent signature to apply only to its own specific domain. The default is to consider a parent-domain signature valid for its subdomains.
親ドメイン：上記で考察したように、サブドメインから発信メールに親ドメインの署名を適用することを選択組織が署名が「T = S」タグを制約するために使用されているか否かに応じて、いくつかの検証により、第三者として処理していることができます親の署名は、独自の特定のドメインに適用します。デフォルトでは、そのサブドメインの親ドメインの署名が有効検討することです。
Reputation Provider: Another possible category of third-party signature would be the identity of a third-party reputation provider. Such a signature would indicate to receivers that the message was being vouched for by that third party.
評判プロバイダ：サードパーティ製の署名の別の可能なカテゴリは、サードパーティの評判プロバイダのIDとなります。そのような署名は、メッセージがその第三者によってためvouchedされたことを受信機に示すことになります。
For most of the cases described so far, there has been an assumption that the signing agent was responsible for creating and maintaining its own DKIM signing infrastructure, including its own keys, and signing with its own identity.
ほとんどの場合は、これまで説明してきたために、署名エージェントが作成し、独自のキーを含む、独自のDKIM署名インフラを維持し、独自のアイデンティティと契約を担当したという仮定がありました。
A different model arises when an organization uses a trusted third-party sender for certain key business functions, but still wants that email to benefit from the organization's own identity and reputation. In other words, the mail would come out of the trusted third party's mail servers, but the signature applied would be that of the controlling organization.
組織が特定の主要なビジネス機能のための信頼できるサードパーティの送信者を使用していますが、それでも電子メールが組織独自のアイデンティティと評判の恩恵を受けることを望んでいるときに、異なるモデルが生じます。言い換えれば、メールは、信頼できる第三者のメールサーバから出てくるだろうが、適用される署名は、制御組織のことだろう。
This can be done by having the third party generate a key pair that is designated uniquely for use by that trusted third party and publishing the public key in the controlling organization's DNS domain, thus enabling the third party to sign mail using the signature of the controlling organization. For example, if Company A outsources its employee benefits to a third party, it can use a special key pair that enables the benefits company to sign mail as "companyA.example". Because the key pair is unique to that trusted third party, it is easy for Company A to revoke the authorization if necessary by simply removing the public key from the companyA.example DNS.
これは、このように制御するための署名を使用してメールに署名する第三者を有効にする、第三者がその信頼できる第三者による使用を一意に指定されている鍵ペアを生成したと制御組織のDNSドメイン内の公開鍵を公開することによって行うことができます会社。 A社は、第三者にその従業員給付を委託た場合、それは「companyA.example」としてメールに署名するメリット会社を可能にし、特殊なキーのペアを使用することができます。鍵のペアは、その信頼できる第三者に一意であるため、必要に応じてA社は単にcompanyA.example DNSから公開鍵を削除することで、許可を取り消すために、それは簡単です。
A more cautious approach would be to create a dedicated subdomain (e.g., benefits.companyA.example) to segment the outsourced mail stream, and to publish the public key there; the signature would then use d=benefits.companyA.example.
より慎重なアプローチは、セグメントに委託メールストリームを専用のサブドメイン（例えば、benefits.companyA.example）を作成し、そこに公開鍵を公開することであろう。署名は、次にD = benefits.companyA.exampleを使用します。
Another possibility for configuring trusted third-party access, as discussed in Section 3.4, is to have Company A use DNS delegation and have the designated subdomain managed directly by the trusted third party. In this case, Company A would create a subdomain benefits.companya.example, and delegate the DNS management of that subdomain to the benefits company so it could maintain its own key records. When revocation becomes necessary, Company A could simply remove the DNS delegation record.
3.4節で述べたように、信頼できるサードパーティのアクセスを設定するための別の可能性は、A社は、DNSの委任を使用して、信頼できる第三者によって直接管理指定されたサブドメインを持っていることです。この場合、A社は、サブドメインbenefits.companya.exampleを作成し、そしてそれは、独自のキーレコードを維持できるような利点会社にそのサブドメインのDNS管理を委任します。失効が必要になった場合、A社は、単にDNS委任レコードを削除することができます。
A simple configuration for DKIM-signed mail is to have a single signature on a given message. This works well for domains that manage and send all of their own email from single sources, or for cases where multiple email streams exist but each has its own unique key pair. It also represents the case in which only one of the participants in an email sequence is able to sign, no matter whether it represents the author or one of the operators.
DKIM署名付きメールの簡単な構成は、所与のメッセージに単一の署名を有することです。これは、管理し、単一のソースから、または複数の電子メールストリームが存在するが、それぞれが独自の鍵のペアを持っている場合のために、自分の電子メールのすべてを送信するドメインに適しています。また、電子メールのシーケンスの参加者の一方のみが関係なく、それは作者や演算子のいずれかを表しているかどうか、署名していないことが可能である場合を表しています。
The examples thus far have considered the implications of using different identities in DKIM signatures, but have used only one such identity for any given message. In some cases, it can make sense to have more than one identity claiming responsibility for the same message.
例としては、これまでにDKIM署名に異なるIDを使用することの意味を考えているが、任意の与えられたメッセージのための唯一のそのようなアイデンティティを使用しています。いくつかのケースでは、それは同じメッセージの責任を主張し、複数のIDを持っていることに意味を作ることができます。
There are a number of situations where applying more than one DKIM signature to the same message might make sense. A few examples are:
同じメッセージに複数のDKIM署名を適用することが意味をなす可能性がある状況がいくつかあります。いくつかの例は以下のとおりです。
Companies with multiple subdomain identities: A company that has multiple subdomains sending distinct categories of mail might choose to sign with distinct subdomain identities to enable each subdomain to manage its own identity. However, it might also want to provide a common identity that cuts across all of the distinct subdomains. For example, Company A can sign mail for its sales department with a signature where d=sales.companya.example and a second signature where d=companya.example
複数のサブドメインのアイデンティティを持つ企業：メールの別個のカテゴリーを送信する複数のサブドメインを持っている企業は、独自のアイデンティティを管理するために、各サブドメインを有効にするために別々のサブドメインのアイデンティティで署名することを選択するかもしれません。しかし、それはまた、個別のサブドメインのすべてを横断する共通のアイデンティティを提供する場合があります。例えば、会社Aは、署名D = sales.companya.example及び第2の署名D = companya.exampleとの営業部門のメールに署名することができ
Service Providers: A service provider can, as described above, choose to sign outbound messages with either its own identity or an identity unique to each of its clients (possibly delegated). However, it can also do both: sign each outbound message with its own identity as well as with the identity of each individual client. For example, ESP A might sign mail for its client Company B with its service provider signature d=espa.example, and a second client-specific signature where d= either companyb.example or companyb.espa.example. The existence of the service provider signature could, for example, help cover a new client while it establishes its own reputation, or help a very small volume client who might never reach a volume threshold sufficient to establish an individual reputation.
サービスプロバイダ：サービスプロバイダは、上述したように、独自のアイデンティティやそのクライアントのそれぞれに固有のID（おそらく委任）のいずれかで送信メッセージに署名することを選択できます。しかし、それはまた、両方の操作を行うことができます独自のアイデンティティと同様に、個々のクライアントのIDを使用して、各送信メッセージに署名します。例えば、ESP Aは、そのサービスプロバイダ署名D = espa.example、およびd = companyb.example又はcompanyb.espa.exampleいずれかの第2のクライアント固有の署名とそのクライアントB社のメールに署名するかもしれません。サービスプロバイダの署名の存在は、例えば、それは自身の評判を確立しながら、新しいクライアントをカバー助ける、または個々の評判を確立するのに十分な量のしきい値に達したことがないかもしれない非常に少量のクライアントを助けることができます。
Forwarders: Forwarded mail poses a number of challenges to email authentication. DKIM is relatively robust in the presence of forwarders as long as the signature is designed to avoid message parts that are likely to be modified; however, some forwarders do make modifications that can invalidate a DKIM signature.
フォワーダ：転送されたメールは、電子メール認証に多くの課題を提起します。 DKIMであれば、署名が変更される可能性があるメッセージ部分を回避するように設計されるフォワーダの存在下で比較的ロバストです。しかし、いくつかのフォワーダーは、DKIM署名を無効にすることができる修正を行いません。
Some forwarders such as mailing lists or "forward article to a friend" services might choose to add their own signatures to outbound messages to vouch for them having legitimately originated from the designated service. In this case, the signature would be added even in the presence of a preexisting signature, and both signatures would be relevant to the verifier.
そのようなメーリングリストやサービス「をメールで前方の記事」などの一部のフォワーダーは、彼らが合法的に持つ指定されたサービスから発信さを保証するために、送信メッセージに、自分の署名を追加することもできます。この場合には、署名があっても、既存の署名の存在下で添加されるであろう、との両方の署名が検証者に関連するであろう。
Any forwarder that modifies messages in ways that will break preexisting DKIM signatures needs to sign its forwarded messages.
DKIM署名を既存の壊れます方法でメッセージを変更し、任意のフォワーダは、その転送メッセージに署名する必要があります。
Reputation Providers: Although third-party reputation providers today use a variety of protocols to communicate their information to receivers, it is possible that they, or other organizations willing to put their "seal of approval" on an email stream, might choose to use a DKIM signature to do it. In nearly all cases, this "reputation" signature would be in addition to the author or originator signature.
評判プロバイダ：サードパーティの評判プロバイダは本日、受信者にその情報を伝達するためのさまざまなプロトコルを使用していますが、彼ら、または電子メールストリーム上で彼らの「承認の印鑑を」入れて喜んで他の組織は、使用することを選択するかもしれないことがありますそれを行うにはDKIM署名。ほぼすべてのケースでは、この「評判」の署名は、著者や発信元の署名に加えだろう。
One important caveat to the use of multiple signatures is that there is currently no clear consensus among receivers on how they plan to handle them. The opinions range from ignoring all but one signature (and the specification of which of them is verified differs from receiver to receiver), to verifying all signatures present and applying a weighted blend of the trust assessments for those identifiers, to verifying all signatures present and simply using the identifier that represents the most positive trust assessment. It is likely that the industry will evolve to accept multiple signatures using either the second or third of these, but it can take some time before one approach becomes pervasive.
複数の署名を使用する1つの重要な注意点は、彼らがそれらを処理する計画方法については受信機の間には明確なコンセンサスが現在存在しないことです。意見が存在するすべての署名を検証し、存在するすべての署名を検証し、それらの識別子の信頼性評価の加重ブレンドを適用する、すべてが、1人の署名（及び受信機に受信機と異なるが確認され、それらのうち指定）を無視範囲及び単に最も肯定的な信頼性評価を表す識別子を使用。業界が第二またはこれらの第三のいずれかを使用して複数の署名を受け入れるように進化していく可能性が高いですが、一つのアプローチが普及になる前に、それは時間がかかることがあります。
Signatures are created by different types of email actors, based on different criteria, such as where the actor operates in the sequence from author to recipient, whether they want different messages to be evaluated under the same reputation or a different one, and so on.
署名は、そのような俳優はそうで、彼らは異なるメッセージが同じ評判または別のもので評価するかどうかを、受信者に著者から順番に動作し、どこなど、さまざまな基準に基づいて、電子メール俳優の異なる種類によって作成されます。
This section provides some examples of usage scenarios for DKIM deployments; the selection is not intended to be exhaustive but to illustrate a set of key deployment considerations.
このセクションでは、DKIMの導入のための使用シナリオの例をいくつか提供します。選択は網羅的であることが、キーの配置の考慮事項のセットを説明することを意図していません。
The simplest DKIM configuration is to have some mail from a given organization (Company A) be signed with the same d= value (e.g., d=companya.example). If there is a desire to associate additional information, the AUID [RFC5672] value can become uniqueID@companya.example, or @uniqueID.companya.example.
最も単純なDKIM構成は同じD =値（例えば、D = companya.example）で署名され、所与の組織（A社）からいくつかのメールを持っていることです。追加情報を関連付ける要望がある場合は、AUID [RFC5672]の値はuniqueID@companya.exampleになる、またはuniqueID.companya.example @ことができます。
In this scenario, Company A need only generate a single signing key and publish it under their top-level domain (companya.example); the signing module would then tailor the AUID value as needed at signing time.
このシナリオでは、A社は、単一の署名鍵を生成し、そのトップレベルドメイン（companya.example）の下でそれを公開するだけで済みます。署名時に、必要に応じて署名モジュールは、AUID値を調整します。
A slight variation of the one signature case is where Company A signs some of its mail, but it wants to differentiate among categories of its outbound mail by using different identifiers. For example, it might choose to distinguish marketing, billing or transactional, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, respectively, where each category is assigned a unique subdomain and unique signing keys.
A社は、そのメールの一部に署名する場所1人の署名例わずかなばらつきがあるが、それは異なる識別子を使用することによって、その送信メールのカテゴリを区別するために望んでいます。例えば、それは各カテゴリが独自のサブドメインとユニークな署名キーが割り当てられている場合、それぞれ、marketing.companya.example、billing.companya.example、およびcompanya.exampleにマーケティング、請求書またはトランザクション、および個々の企業の電子メールを区別することを選択するかもしれません。
Some domains might decide to sign all of their outgoing mail. If all of the legitimate mail for a domain is signed, recipients can be more aggressive in their filtering of mail that uses the domain but does not have a valid signature from the domain; in such a configuration, the absence of a signature would be more significant than for the general case. It might be desirable for such domains to be able to advertise their intent to other receivers: this is the topic of Author Domain Signing Practices (ADSP).
いくつかのドメインは、その送信メールのすべてに署名することを決めるかもしれません。ドメインのための正当なメールの全てが署名されている場合、受信者がドメインを使用していますが、ドメインから有効な署名を持っていないメールの彼らのフィルタリングで、より積極的なことができます。このような構成では、署名が存在しないことは、一般的な場合よりもより重要であろう。そのようなドメインが他の受信者に自分の意図を宣伝できるようにすることが望ましいかもしれない：これは著者ドメイン署名プラクティス（ADSP）の話題です。
Note that ADSP is not for everyone. Sending domains that do not control all legitimate outbound mail purporting to be from their domain (i.e., with an RFC5322.From address in their domain) are likely to experience delivery problems with some percentage of that mail. Administrators evaluating ADSP for their domains needs to carefully weigh the risk of phishing attacks against the likelihood of undelivered mail.
ADSPは皆のためではないことに注意してください。自分のドメインからのものであると主張するすべての正当な送信メールをコントロールしていないドメインを送信する（すなわち、そのドメイン内RFC5322.Fromアドレスを持つ）そのメールのいくつかの割合で配信問題が発生する可能性があります。そのドメインのADSPを評価する管理者は、慎重に未配信のメールの可能性に対するフィッシング攻撃のリスクを比較検討する必要があります。
This section covers some examples of ADSP usage. For the complete specification, see [RFC5617].
このセクションでは、ADSPの使用のいくつかの例をカバーしています。完全な仕様については、[RFC5617]を参照してください。
In the ADSP specification, an address in the RFC5322.From header field of a message is defined as an "Author Address", and an "Author Domain" is defined as anything to the right of the '@' in an author address.
ADSP仕様では、メッセージのRFC5322.Fromヘッダフィールド内のアドレスは、「著者住所」として定義され、「著者ドメインは、」著者アドレスの「@」の右にあるものとして定義されます。
An "Author Signature" is thus any valid signature where the value of the SDID matches an author domain in the message.
「著者署名」こうしてSDIDの値は、メッセージ内の著者のドメインと一致する任意の有効な署名です。
It is important to note that unlike the DKIM specification, which makes no correlation between the signature domain and any message headers, the ADSP specification applies only to the author domain. In essence, under ADSP, any non-author signatures are ignored (treated as if they are not present).
署名ドメインと任意のメッセージヘッダとの間に相関を行いませんDKIM仕様とは異なり、ADSP仕様は唯一の著者のドメインに適用されることに注意することが重要です。本質的には、ADSPの下で、任意の非作者の署名は、（彼らが存在しないかのように扱われる）は無視されます。
Signers wishing to publish an Author Domain Signing Practices (ADSP) [RFC5617] record describing their signing practices will thus want to include an author signature on their outbound mail to avoid ADSP verification failures.
彼らの署名プラクティスを記述する著者ドメイン署名プラクティス（ADSP）[RFC5617]レコードを公開したい署名者は、このようにADSP検証の失敗を避けるために、彼らのアウトバウンドメールに作者の署名を含めることになるでしょう。
An organization (Company A) can specify its signing practices by publishing an ADSP record with "dkim=all" or "dkim=discardable". In order to avoid misdelivery of its mail at receivers that are validating ADSP, Company A needs to first have done an exhaustive analysis to determine all sources of outbound mail from its domain (companyA.example) and ensure that they all have valid author signatures from that domain.
組織（A社）は、「DKIM =すべて」または「DKIM =廃棄」とADSPレコードを公開することにより、その署名プラクティスを指定することができます。 ADSPを検証する受信機においてそのメールの誤配信を避けるために、A社は、最初にそのドメイン（companyA.example）からの送信メールのすべてのソースを決定し、それらはすべてから有効な作者の署名を持っていることを確認するために、徹底的な分析を行っている必要がありますそのドメイン。
For example, email with an RFC5322.From address of bob@ companyA.example needs to have an author signature where the SDID value is "companyA.example" or it will fail an ADSP validation.
例えば、ボブの@ companyA.exampleのRFC5322.Fromアドレスを持つ電子メールはSDID値は「companyA.example」であるか、それがADSPの検証を失敗する作成者の署名を持っている必要があります。
Note that once an organization publishes an ADSP record using dkim=all or dkim=discardable, any email with an RFC5322.From address that uses the domain where the ADSP record is published that does not have a valid author signature is at risk of being misdelivered or discarded. For example, if a message with an RFC5322.From address of newsletter@companyA.example has a signature with d=marketing.companyA.example, that message will fail the ADSP check because the signature would not be considered a valid author signature.
すべてまたは有効な作者の署名が誤配信されているの危険にさらされている必要はありませんADSPレコードが公開されているドメインを使用していますRFC5322.Fromアドレスを持つDKIM =廃棄、任意の電子メール=一度組織がDKIMを使用してADSPレコードを公開することに注意してくださいまたは廃棄されました。 newsletter@companyA.exampleのRFC5322.Fromアドレスを持つメッセージは、D = marketing.companyA.exampleとの署名を持っている場合、署名が有効作成者の署名は考えられないので、例えば、そのメッセージは、ADSPチェックに失敗します。
Because the semantics of an ADSP author signature are more constrained than the semantics of a "pure" DKIM signature, it is important to make sure the nuances are well understood before deploying an ADSP record. The ADSP specification [RFC5617] provides some fairly extensive lookup examples (in Appendix A) and usage examples (in Appendix B).
ADSP作成者署名の意味は、「純粋な」DKIM署名の意味よりも拘束されているので、ニュアンスがよくADSPレコードを展開する前に理解していることを確認することが重要です。 ADSP仕様[RFC5617]は（付録B）は、いくつかのかなり広範囲（付録A）参照例および使用例を提供します。
In particular, in order to prevent mail from being negatively impacted or even discarded at the receiver, it is essential to perform a thorough survey of outbound mail from a domain before publishing an ADSP policy of anything stronger than "unknown". This includes mail that might be sent from external sources that might not be authorized to use the domain signature, as well as mail that risks modification in transit that might invalidate an otherwise valid author signature (e.g., mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body).
具体的には、受信機に悪影響を与えたり、廃棄されることからメールを防止するためには、「不明」よりも強いもののADSPポリシーを公開する前に、ドメインから送信メールの徹底的な調査を行うことが必須です。これは、そうでない場合は、有効な作成者の署名（例えば、メーリングリスト、礼儀フォワーダ、および他のパスを無効にする可能性があるトランジットで変更をリスクドメインの署名を使用することが許可されていない可能性があります外部ソースから送信されるかもしれないメールと同様にメールを含みそれは）追加またはヘッダを変更したり、メッセージ本文を修正することができます。
An organization might choose to outsource certain key services to an independent company. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email.
組織は、独立した会社に一定の主要なサービスを外部委託することを選択するかもしれません。例えば、A社は、その利益の管理をアウトソーシング可能性がある、または組織Bは、そのマーケティングの電子メールを外部委託することがあります。
If Company A wants to ensure that all of the mail sent on its behalf through the benefits providers email servers shares the Company A reputation, as discussed in Section 6.4, it can either publish keys designated for the use of the benefits provider under companyA.example (preferably under a designated subdomain of companyA.example), or it can delegate a subdomain (e.g., benefits.companyA.example) to the provider and enable the provider to generate the keys and manage the DNS for the designated subdomain.
A社は、6.4節で述べたように、メールの全てが、メリットプロバイダのメールサーバの株式会社の評判を通じて、代わって送信されていることを確認したい場合は、そのどちらかcompanyA.exampleに基づく給付プロバイダの使用のために指定されたキーを公開（好ましくはcompanyA.exampleの指定されたサブドメイン下）、またはそれはプロバイダにサブドメイン（例えば、benefits.companyA.example）を委任し、キーを生成し、指定されたサブドメインのDNSを管理するプロバイダを可能にすることができます。
In both of these cases, mail would be physically going out of the benefit provider's mail servers with a signature of, e.g., d=benefits.companya.example. Note that the RFC5322.From address is not constrained: it could be affiliated with either the benefits company (e.g., benefits-admin@benefitprovider.example, or benefits-provider@benefits.companya.example) or the companyA domain.
いずれの場合も、メールは物理的に、例えば、D = benefits.companya.exampleの署名と給付プロバイダのメールサーバから出て行くことになります。 RFC5322.Fromアドレスが制約されていないことに注意してください：それはメリット会社（例えば、benefits-admin@benefitprovider.example、またはbenefits-provider@benefits.companya.example）またはA社のドメインのいずれかに所属することができます。
Note that in both of the above scenarios, as discussed in Section 3.4, security concerns dictate that the keys be generated by the organization that plans to do the signing so that there is no need to transfer the private key. In other words, the benefits provider would generate keys for both of the above scenarios.
3.4節で述べたように、上記のシナリオの両方でなお、セキュリティ上の懸念は、キーは、秘密鍵を転送する必要がないように署名を行うことを計画し、組織によって生成されることを指示します。言い換えれば、メリット・プロバイダは、上記のシナリオの両方のためのキーを生成します。
Another way to manage the service provider configuration would be to have the service provider sign the outgoing mail on behalf of its client, Company A, with its own (provider) identifier. For example, an Email Service Provider (ESP A) might want to share its own mailing reputation with its clients, and might sign all outgoing mail from its clients with its own d= domain (e.g., d=espa.example).
サービス・プロバイダーの構成を管理する別の方法は、サービスプロバイダが独自の（プロバイダ）の識別子と、そのクライアント、A社に代わって送信メールに署名を持っているだろう。たとえば、メールサービスプロバイダ（ESP A）は、その顧客との独自のメーリング評判を共有したいかもしれませんし、独自のD =ドメイン（例えば、D = espa.example）とそのクライアントからのすべての送信メールに署名することがあります。
When the ESP wants to distinguish among its clients, it has two options:
ESPは、そのクライアントの間で区別したいときは、2つのオプションがあります。
o Share the SDID domain and use the AUID value to distinguish among the clients, e.g., a signature on behalf of client A would have d=espa.example and i=@clienta.espa.example (or i=clienta@espa.example).
O SDIDドメインを共有し、クライアント間で区別するためにAUID値を使用して、例えば、クライアントAに代わって署名は= espa.exampleとi=@clienta.espa.example（またはi=clienta@espa.example dはいるだろう）。
o Extend the SDID domain, so there is a unique value (and subdomain) for each client, e.g., a signature on behalf of client A would have d=clienta.espa.example.
O SDIDドメインを拡張するため、各クライアント、例えばためのユニークな値（及びサブドメイン）がある、クライアントAに代わって署名は、D = clienta.espa.exampleを有するであろう。
Note that this scenario and the delegation scenario are not mutually exclusive. In some cases, it can be desirable to sign the same message with both the ESP and the ESP client identities.
このシナリオと委任のシナリオは、相互に排他的ではないことに注意してください。いくつかのケースでは、ESPとESPのクライアントIDの両方で同じメッセージに署名することが望ましいです。
An ISP (ISP A) might want to assign signatures to outbound mail from its users according to each user's past sending behavior (reputation). In other words, the ISP would segment its outbound traffic according to its own assessment of message quality, to aid recipients in differentiating among these different streams. Since the semantics of behavioral assessments are not valid AUID values, ISP A (ispa.example) can configure subdomains corresponding to the assessment categories (e.g., good.ispa.example, neutral.ispa.example, bad.ispa.example), and use these subdomains in the d= value of the signature.
ISP（ISP A）は、各ユーザの過去の送信動作（評判）に応じてそのユーザーからの送信メールに署名を割り当てることができます。言い換えれば、ISPは、セグメントのメッセージ品質の独自の評価に応じてアウトバウンドトラフィックは、これらの異なるストリーム間差別に受信者を支援するためでしょう。行動評価のセマンティクスが有効なAUID値ではありませんので、ISP A（ispa.example）は、評価カテゴリに対応したサブドメインを設定する（例えば、good.ispa.example、neutral.ispa.example、bad.ispa.example）、およびすることができます署名のD =値でこれらのサブドメインを使用します。
The signing module can also set the AUID value to have a unique user ID (distinct from the local-part of the user's email address), for example, user3456@neutral.domain.example. Using a user ID that is distinct from a given email alias is useful in environments where a single user might register multiple email aliases.
署名モジュールはまた、（ユーザの電子メールアドレスのローカル部分とは異なる）固有のユーザーID、例えば、user3456@neutral.domain.exampleを有することAUID値を設定することができます。指定したメールエイリアスとは区別されるユーザーIDを使用すると、1人のユーザーが複数の電子メールエイリアスを登録する可能性がある環境で有用です。
Note that in this case, the AUID values are only partially stable. They are stable in the sense that a given i= value will always represent the same identity, but they are unstable in the sense that a given user can migrate among the assessment subdomains depending on their sending behavior (i.e., the same user might have multiple AUID values over the lifetime of a single account).
この場合には、AUID値が部分的にしか安定していることに注意してください。彼らは私が=値は常に同じIDを表します与えられたという意味で安定しているが、彼らは、特定のユーザーが自分の送信の挙動に応じて査定サブドメイン間で移行することができるという意味で不安定である（すなわち、同じユーザが複数の場合があります単一のアカウントの寿命にわたってAUID値）。
In this scenario, ISP A can generate as many keys as there are assessment subdomains (SDID values), so that each assessment subdomain has its own key. The signing module would then choose its signing key based on the assessment of the user whose mail was being signed, and if desired, include the user ID in the AUID of the signature. As discussed earlier, the per-user granularity of the AUID can be ignored by verifiers; so organizations choosing to use it ought not rely on its use for receiver side filtering results. However, some organizations might also find the information useful for their own purposes in processing bounces or abuse reports.
アセスメントのサブドメイン（SDID値）があるとして、各評価サブドメインは、独自のキーを持っているように、このシナリオでは、ISP Aは、できるだけ多くのキーを生成することができます。署名モジュールは、メール署名されたユーザの評価に基づいて、その署名鍵を選択し、所望であれば、署名のAUIDにユーザIDが含まれます。前述したように、AUIDのユーザごとの粒度は、検証者によって無視することができます。ので、それを使用することを選択する組織は、受信側のフィルタリングの結果のためのその使用に頼るべきではありません。ただし、一部の組織では、処理バウンスまたは乱用報告書で、自分の目的のために有用な情報を見つけることがあります。
Another scenario is that of an agent, usually a re-mailer of some kind, that signs on behalf of the service or organization that it represents. Some examples of agents might be a mailing list manager, or the "forward article to a friend" service that many online publications offer. In most of these cases, the signature is asserting that the message originated with, or was relayed by, the service asserting responsibility. In general, if the service is configured in such a way that its forwarding would break existing DKIM signatures, it needs to always add its own signature.
別のシナリオでは、エージェント、いくつかの種類の通常再メーラーのそれは、それが表すサービスまたは組織に代わってサインということです。薬のいくつかの例には、メーリングリストマネージャ、または多くのオンライン出版が提供するサービス「をメールで前方の記事」あるかもしれません。これらのケースのほとんどでは、署名は、メッセージがで起源と主張している、または責任をアサートするサービスによって中継されました。サービスは、その転送は、既存のDKIM署名を壊すように構成されている場合、一般的に、それは常に独自の署名を追加する必要があります。
The robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules have access to the designated private key. This has the side effect that email submission and delivery scenarios that originate or relay messages from outside the domain of the authorized signing module will not have access to that protected private key, and thus will be unable to attach the expected domain signature to those messages. Such scenarios include mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by traveling users, and other paths that could add or modify headers, or modify the message body.
DKIMの検証メカニズムのロバスト性のみ許可署名モジュールは、指定された秘密鍵へのアクセス権を持っているという事実に基づいています。これは、認可署名モジュールのドメイン外からのメッセージを発信または中継するメールの提出および配信のシナリオは、その保護された秘密鍵にアクセスすることはできませんという副作用があり、したがって、それらのメッセージに期待されるドメインの署名を添付することができません。このようなシナリオはメーリングリスト、礼儀フォワーダー、ホテルでのMTA、旅のユーザによって使用されるホットスポットネットワーク、および追加またはヘッダを変更、またはメッセージ本文を修正することができる他のパスが含まれています。
For example, assume Joe works for Company A and has an email address joe@companya.example. Joe also has an ISP-1 account joe@isp1.example.com, and he uses ISP-1's multiple address feature to attach his work email address, joe@companya.example, to email from his ISP-1 account. When Joe sends email from his ISP-1 account and uses joe@companya.example as his designated RFC5322.From address,
たとえば、JoeがA社のために働くと電子メールアドレスjoe@companya.exampleを持っていると仮定します。ジョーはまた、ISP-1アカウントjoe@isp1.example.comを持っている、と彼は彼のISP-1アカウントから電子メールで送信するために、彼の仕事用メールアドレス、joe@companya.exampleを添付するISP-1の複数のアドレス機能を使用しています。ジョーは彼のISP-1アカウントからメールを送信し、彼の指定RFC5322.Fromアドレスとしてjoe@companya.example使用する場合、
that email cannot have a signature with d=companya.example because the ISP-1 servers have no access to Company A's private key. In ISP-1's case, it will have an ISP-1 signature, but for some other mail clients offering the same multiple address feature there might be no signature at all on the message.
ISP-1サーバはA社の秘密鍵にアクセスできないので、その電子メールは、D = companya.exampleと署名を持つことはできません。 ISP-1のケースでは、ISP-1の署名を持っていますが、同じ複数のアドレス機能を提供するいくつかの他のメールクライアントのメッセージには全く署名がないかもしれません。
Another example might be the use of a forward article to a friend service. Most instances of these services today allow someone to send an article with their email address in the RFC5322.From to their designated recipient. If Joe used either of his two addresses (joe@companya.example or joe@isp1.example.com), the forwarder would be equally unable to sign with a corresponding domain. As in the mail client case, the forwarder can either sign as its own domain or put no signature on the message.
別の例は、友人サービスへの前方物品の使用であるかもしれません。今日、これらのサービスのほとんどの場合は、誰かが自分の指定した受信者にRFC5322.Fromに自分のメールアドレスを使用して記事を送信することができます。ジョーは彼の二つのアドレス（joe@companya.exampleまたはjoe@isp1.example.com）のいずれかを使用した場合、フォワーダは、対応するドメインで署名することも同様にできないであろう。メールクライアントの場合と同様に、フォワーダは、独自のドメインとして署名するか、またはメッセージに対して何の署名を入れていません。
A third example is the use of privately configured forwarding. Assume that Joe has another account at ISP-2, joe@isp-2.example.com, but he'd prefer to read his ISP-2 mail from his ISP-1 account. He sets up his ISP-2 account to forward all incoming mail to joe@isp1.example.com. Assume alice@companyb.example sends joe@isp-2.example.com an email. Depending on how companyb.example configured its signature, and depending on whether or not ISP-2 modifies messages that it forwards, it is possible that when Alice's message is received in Joe's ISP-1 account, the original signature will fail verification.
第3の例は、個人設定された転送を使用することです。ジョーはISP-2、joe@isp-2.example.comで別のアカウントを持っていることを前提としていたが、彼は彼のISP-1口座から自分のISP-2のメールを読むことを好むだろう。彼はjoe@isp1.example.comにすべての受信メールを転送するために彼のISP-2のアカウントを設定します。 alice@companyb.exampleが電子メールを送信しjoe@isp-2.example.comと仮定します。 companyb.exampleがその署名を構成する方法に応じて、か否かISP-2に依存することは、転送、それはアリスのメッセージがジョーのISP-1アカウントで受信されたときに、元の署名が検証に失敗する可能性があるメッセージを修正します。
One identity is particularly amenable to easy and accurate assessment: the organization's own identity. Members of an organization tend to trust messages that purport to be from within that organization. However, Internet Mail does not provide a straightforward means of determining whether such mail is, in fact, from within the organization. DKIM can be used to remedy this exposure. If the organization signs all of its mail, then its boundary MTAs can look for mail purporting to be from the organization that does not contain a verifiable signature.
1つのIDは、簡単かつ正確な評価に特に適している：組織独自のアイデンティティ。組織のメンバーは、その組織内からという趣旨のメッセージを信頼する傾向があります。ただし、インターネットメールは、組織内から、実際には、そのようなメールがあるかどうかを判断する簡単な手段を提供していません。 DKIMは、この露出を改善するために使用することができます。組織は、そのメールのすべてに署名した場合は、その境界MTAが検証可能な署名が含まれていない組織からのものであると主張するメールを探すことができます。
Such mail can, in most cases, be presumed to be spurious. However, domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g., MTAs at hotels, hotspot networks used by traveling users, and other scenarios described in the previous section). Such breakage is particularly relevant in the presence of Author Domain Signing Practices.
このようなメールは、ほとんどの場合、偽であると推定することができます。メーリングリスト、礼儀フォワーダ、および追加または変更するヘッダーまたはメッセージ本文を修正することができる他の経路（例えば、のMTA：ただし、ドメイン管理者は、メール処理は、既存のDKIM署名を無効にする方法でメッセージを変更することができる方法を検討することをお勧めしますホテル、旅行するユーザによって使用されるホットスポットネットワーク、前のセクションで説明した他のシナリオで）。このような破損は、著者ドメイン署名慣行の存在下で、特に関連します。
Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer subdomains or otherwise adjust signatures in a way that supports per-user identification. This user-level granularity can be specified in two ways: either by sharing the signing identity and specifying an extension to the i= value that has a per-user granularity or by creating and signing with unique per-user keys.
ドメイン名のDKIMの使用は、組織レベルの署名の範囲のために最適化されていますが、サブドメインを管理するか、そうでない場合は、ユーザーごとの識別をサポートしていた方法で署名を調整することが可能です。このユーザーレベルの細分性は、2つの方法で指定することができる：署名の同一性を共有し、ユーザーごとの粒度を有するか、または作成してユニークユーザごとのキーで署名することにより、I =値に拡張子を指定することによってのいずれか。
A subdomain or local part in the i= tag needs to be treated as an opaque identifier and thus need not correspond directly to a DNS subdomain or be a specific user address.
I =タグ内のサブドメインまたはローカル部分は、不透明な識別子として扱われ、従って、DNSサブドメインに直接対応し、または特定のユーザアドレスである必要はないことが必要です。
The primary way to sign with per-user keys requires each user to have a distinct DNS (sub)domain, where each distinct d= value has a key published. (It is possible, although not advised, to publish the same key in more than one distinct domain.)
ユーザーごとのキーで署名する主な方法は、それぞれ別個D =値が公開鍵を有する別個のDNS（サブ）ドメインを有するように各ユーザに要求します。 （、助言つ以上の異なるドメインで同じキーを公開していないが、それは可能です。）
It is technically possible to publish per-user keys within a single domain or subdomain by utilizing different selector values. This is not advised and is unlikely to be treated uniquely by Assessors: the primary purpose of selectors is to facilitate key management, and the DKIM specification recommends against using them in determining or assessing identities.
異なるセレクタ値を利用することにより、単一のドメインまたはサブドメイン内のユーザごとの鍵を公開することは技術的に可能です。これは、助言や査定によって独自に扱われることはほとんどありませんされていません：セレクタの主な目的は、鍵管理を容易にすることである、とDKIMの仕様が決定またはアイデンティティを評価する際にそれらを使用しないことをお薦めします。
In most cases, it would be impractical to sign email on a per-user granularity. Such an approach would be
ほとんどの場合、ユーザごとの細かさで、電子メールに署名することは非現実的です。このようなアプローチは次のようになります
likely to be ignored: In most cases today, if receivers are verifying DKIM signatures, they are in general taking the simplest possible approach. In many cases, maintaining reputation information at a per-user granularity is not interesting to them, in large part because the per-user volume is too small to be useful or interesting. So even if senders take on the complexity necessary to support per-user signatures, receivers are unlikely to retain anything more than the base domain reputation.
無視される可能性：ほとんどの場合、今日、レシーバはDKIM署名を検証している場合、彼らは可能な限り単純なアプローチを取って、一般的にあります。ユーザごとのボリュームが有用か興味深いものにするには小さすぎるので、多くのケースでは、ユーザごとの細かさで評判情報を維持することが大部分で、それらに興味深いものではありません。だから、送信者は、ユーザーごとの署名をサポートするために必要な複雑さを取る場合でも、受信機は、基本ドメインの評判以上のものを保持する可能性は低いです。
difficult to manage: Any scheme that involves maintenance of a significant number of public keys might require infrastructure enhancements or extensive administrative expertise. For domains of any size, maintaining a valid per-user keypair, knowing when keys need to be revoked or added due to user attrition or onboarding, and the overhead of having the signing engine constantly swapping keys can create significant and often unnecessary management complexity. It is also important to note that there is no way within the scope of the DKIM specification for a receiver to infer that a sender intends a per-user granularity.
公開鍵のかなりの数の維持を必要とする任意のスキームは、インフラストラクチャの拡張や大規模な管理の専門知識が必要になることがあります：管理が難しいです。任意のサイズのドメインの場合、キーが原因のユーザー消耗またはオンボーディング、常に鍵を交換する署名エンジンが重要と、多くの場合、不要な管理の複雑さを作成することができたのオーバーヘッドを取り消さまたは追加する必要があるときに知って、有効なユーザごとの鍵ペアを維持します。受信機は、送信者は、ユーザーごとの粒度を意図していると推測するためのDKIM仕様の範囲内に方法がないことに注意することも重要です。
As mentioned before, what might make sense, however, is to use the infrastructure that enables finer granularity in signatures to identify segments smaller than a domain but much larger than a per-user segmentation. For example, a university might want to segment student, staff, and faculty mail into three distinct streams with differing reputations. This can be done by creating separate subdomains for the desired segments, and either specifying the subdomains in the i= tag of the DKIM Signature or by adding subdomains to the d= tag and assigning and signing with different keys for each subdomain.
前述のように、意味をなすかもしれないもの、しかし、ドメインよりも小さいが、ユーザー単位のセグメンテーションよりもはるかに大きいセグメントを識別するためのシグネチャに細かい粒度を可能にするインフラストラクチャを使用することです。例えば、大学が異なる評判を持つ三つの異なるストリームにセグメントの学生、職員、教員のメールにお勧めします。これは、所望のセグメントに別個のサブドメインを作成し、いずれかのDKIM署名のI =タグ内のサブドメインを指定することによって、またはd =タグにサブドメインを追加して割り当て、各サブドメインの異なる鍵で署名することによって行うことができます。
For those who choose to represent user-level granularity in signatures, the performance and management considerations above suggest that it would be more effective to do so by specifying a local part or subdomain extension in the i= tag rather than by extending the d= domain and publishing individual keys.
署名にユーザレベルの細かさを表現することを選択した人のために、パフォーマンスと管理の考慮事項は上記の私=タグ内のローカル部分またはサブドメイン拡張子を指定することではなく、D =ドメインを拡張することによってそうするように、より有効であろうことを示唆していますそして個々のキーを公開。
It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service, such as a department or a boundary MTA. What follows are some general recommendations for the Email Infrastructure.
DKIMを実装するための最も一般的な会場は、部門や境界MTAとして、組織の電子メールサービスのインフラストラクチャ内であることが期待されます。以下は、電子メールインフラストラクチャのためのいくつかの一般的な推奨事項です。
Outbound: An MSA (Mail Submission Agent) or an outbound MTA used for mail submission needs to ensure that the message sent is in compliance with the advertised email sending policy. It needs to also be able to generate an operator alert if it determines that the email messages do not comply with the published DKIM sending policy.
アウトバウンド：MSA（メール発信エージェント）またはメール送信で使用されるアウトバウンドMTAは、送信されたメッセージは広告を出して、電子メールの送信ポリシーに準拠していることを確認する必要があります。それはまた、電子メールメッセージが公開DKIM送信ポリシーに準拠していないと判断した場合、オペレータのアラートを生成できるようにする必要があります。
An MSA needs to be aware that some MUAs might add their own signatures. If the MSA needs to perform operations on a message to make it comply with its email sending policy, if at all possible, it needs to do so in a way that would not break those signatures.
MSAは、いくつかのMUAが自分の署名を追加するかもしれないことに注意する必要があります。 MSAは、その電子メールの送信ポリシーに準拠するためにメッセージに対して操作を実行する必要がある場合、すべての可能なであれば、それはそれらの署名を壊さないような方法でそうする必要があります。
MUAs equipped with the ability to sign ought not to be encouraged. In terms of security, MUAs are generally not under the direct control of those in responsible roles within an organization and are thus more vulnerable to attack and compromise, which would expose private signing keys to intruders and thus jeopardize the integrity and reputation of the organization.
奨励されるべきではないに署名する機能を搭載したのMUA。セキュリティの面では、MUAには、侵入者に秘密署名鍵を公開するため、組織の整合性と評判を危険にさらすことになる、組織内の責任者の役割のそれらの直接の管理下に一般的ではありませんので、攻撃と妥協に対してより脆弱です。
Inbound: When an organization deploys DKIM, it needs to make sure that its email infrastructure components that do not have primary roles in DKIM handling do not modify message in ways that prevent subsequent verification.
インバウンド：組織はDKIMを展開すると、それは、DKIMの取り扱いに主要な役割を持っていないその電子メールインフラストラクチャコンポーネントは、その後の検証を防ぐ方法でメッセージを変更しないことを確認する必要があります。
An inbound MTA or an MDA can incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].
インバウンドMTAまたはMDAは、認証、結果ヘッダフィールド[RFC5451]を使用するなど、メッセージに検証結果の表示を組み込むことができます。
Intermediaries: An email intermediary is both an inbound and outbound MTA. Each of the requirements outlined in the sections relating to MTAs apply. If the intermediary modifies a message in a way that breaks the signature, the intermediary.
仲介：電子メールの仲介は、インバウンドとアウトバウンドMTAの両方です。 MTAのに関連するセクションで説明した要件のそれぞれが適用されます。仲介者は、署名、仲介を壊す方法でメッセージを変更した場合。
+ needs to deploy abuse filtering measures on the inbound mail, and
+受信メールの乱用フィルタリング対策を展開する必要があり、
+ probably also needs to remove all signatures that will be broken.
+おそらく破られるすべての署名を削除する必要があります。
In addition, the intermediary can:
また、仲介することができます：
+ verify the message signature prior to modification.
+変更前のメッセージの署名を検証します。
+ incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].
+、認証、結果ヘッダフィールド[RFC5451]を使用するなど、メッセージに検証結果の表示を組み込みます。
+ sign the modified message including the verification results (e.g., the Authentication-Results header field).
+は、検証結果（例えば、認証、結果ヘッダフィールド）を含む修正されたメッセージに署名します。
The DKIM specification is expected to be used primarily between Boundary MTAs, or other infrastructure components of the originating and receiving ADMDs. However, there is nothing in DKIM that is specific to those venues. In particular, MUAs can also support DKIM signing and verifying directly.
DKIM仕様は、境界のMTA、または元の他のインフラストラクチャコンポーネントと受信ADMDs間に主に使用されることが期待されます。しかし、これらの施設に特有であるDKIMには何もありません。具体的には、MUAにもDKIMの署名と直接検証をサポートすることができます。
Outbound: An MUA can support signing even if mail is to be relayed through an outbound MSA. In this case, the signature applied by the MUA will be in addition to any signature added by the MSA. However, the warnings in the previous section need to be taken into consideration.
アウトバウンド：メールが発信MSAを通じて中継される場合でも、MUAは署名をサポートすることができます。この場合、MUAによって適用される署名はMSAによって追加された署名に加えて、あろう。しかし、前節の警告を考慮する必要があります。
Some user software goes beyond simple user functionality and also performs MSA and MTA functions. When this is employed for sending directly to a receiving ADMD, the user software needs to be considered an outbound MTA.
一部のユーザーのソフトウェアは、シンプルなユーザー機能を超えて、また、MSAとMTAの機能を実行します。これは受信ADMDに直接送信するために使用されている場合、ユーザー・ソフトウェアは、アウトバウンドMTAを検討する必要があります。
Inbound: An MUA can rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/ MDA path (e.g., an Authentication-Results header field), or an MUA can perform DKIM signature verification directly. A verifying MUA needs to allow for the case where mail has been modified in the inbound MTA path; if a signature fails, the message is to be treated the same as a message that does not have a signature.
インバウンド：MUAインバウンドMTA / MDA経路（例えば、認証、結果ヘッダフィールド）にある時点で行われたDKIM署名検証の報告に依存することができ、またはMUA直接DKIM署名の検証を行うことができます。検証MUAは、電子メールが着信MTAパスに変更されている場合を可能にする必要があります。署名が失敗した場合、メッセージは、署名を持っていないメッセージと同じように扱われるべきです。
An MUA that looks for an Authentication-Results header field needs to be configurable to choose which Authentication-Results header fields are considered trustable. The MUA developer is encouraged to re-read the Security Considerations of [RFC5451].
認証-結果ヘッダフィールドを探しMUAは認証-結果のヘッダフィールドが信頼できると考えられているかを選択するように設定する必要があります。 MUAの開発者は、[RFC5451]のセキュリティの考慮事項を再読み込みすることが奨励されます。
DKIM requires that all verifiers treat messages with signatures that do not verify as if they are unsigned.
DKIMは、すべての検証は、彼らが符号なしであるかのように検証していない署名付きのメッセージを処理することが必要です。
If verification in the client is to be acceptable to users, it is essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned. The mere presence of a verified DKIM signature cannot be used by itself by an MUA to indicate that a message is to be treated better than a message without a verified DKIM signature. However, the fact that a DKIM signature was verified can be used as input into a reputation system (i.e., a whitelist of domains and users) for presentation of such indicators.
クライアントでの検証がユーザーに受け入れられるのであれば、署名の検証が成功したが、未署名のメッセージを残すことに比べて、満足未満のユーザーエクスペリエンスが得られないことが不可欠です。検証DKIM署名の単なる存在は、メッセージが検証DKIM署名なしでメッセージよりも良好な治療すべきであることを示すために、MUAによって単独で使用することができません。しかし、DKIM署名が検証されたという事実は、そのような指標の提示のために評判システム（ドメインとユーザーの、すなわち、ホワイトリスト）への入力として使用することができます。
It is common for components of an ADMD's email infrastructure to do violence to a message, such that a DKIM signature might be rendered invalid. Hence, users of MUAs that support DKIM signing and/or verifying need a basis for knowing that their associated email infrastructure will not break a signature.
ADMDの電子メールインフラストラクチャのコンポーネントは、メッセージへの暴力を行うことがDKIM署名が無効とされる可能性がありますように、一般的です。したがって、DKIM署名および/または、検証をサポートするのMUAのユーザーがそれに関連付けられた電子メールインフラストラクチャは、署名を壊さないであろうことを知るための基礎を必要とします。
The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871].
DKIMプロトコルのセキュリティ問題は、DKIMベース仕様[RFC4871]に記載されています。
The effort of the DKIM Working Group is gratefully acknowledged.
DKIMワーキンググループの努力は感謝して認められています。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキーを識別メール（DKIM）署名"、RFC 4871、2007年5月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5451] Kucherawy、M.、 "メッセージヘッダーフィールドのメッセージ認証ステータスを示すため"、RFC 5451、2009年4月。
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[RFC5585]ハンセン、T.、クロッカー、D.、およびP.ハラム - ベイカー、RFC 5585の "メール（DKIM）サービスの概要を特定されたのDomainKeys"、2009年7月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617]オールマン、E.、フェントン、J.、デラニー、M.、およびJ.レヴァイン、 "ドメインキー・アイデンティファイド・メール（DKIM）著ドメイン署名プラクティス（ADSP）"、RFC 5617、2009年8月。
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.
[RFC5672]クロッカー、D.、 "RFC 4871ドメインキー・アイデンティファイド・メール（DKIM）署名 - アップデート"、RFC 5672、2009年8月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[RFC4870]デラニー、M.、 "DNS（ドメインキー）で公開鍵アドバタイズを使用したドメインベースの電子メール認証"、RFC 4870、2007年5月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]ローリー、B.、シッソン、G.、アレンズ、R.、およびD. Blacka、 "DNSセキュリティ（DNSSEC）存在のハッシュ認証拒否"、RFC 5155、2008年3月。
Appendix A. Migration Strategies
付録A.移行方針
There are three migration occasions worth noting in particular for DKIM:
DKIMのために特に注目すべき3つの移行の機会があります。
2. Migrating from a current hash algorithm to a new standardized hash algorithm.
2.現在のハッシュ・アルゴリズムから、新しい標準化されたハッシュアルゴリズムへの移行。
3. Migrating from a current signing algorithm to a new standardized signing algorithm.
3.現在の署名アルゴリズムから、新しい標準化された署名アルゴリズムへの移行。
The case of deploying a new key selector record is described elsewhere (Section 3.5).
新しいキーセレクターレコードを展開する場合は（セクション3.5）の他の箇所に記載されています。
As with any migration, the steps required will be determined by who is doing the migration and their assessment of:
任意の移行と同じように、必要な手順は、移行との彼らの評価を行っている者によって決定されます。
o the users of what they are generating, or
O、彼らが生成されているもののユーザー、または
o the providers of what they are consuming.
彼らが消費しているかのプロバイダO。
Signers and verifiers have different considerations.
署名者と検証者は、異なる考慮事項があります。
A.1. Migrating from DomainKeys
A.1。 DomainKeysのからの移行
DKIM replaces the earlier DomainKeys (DK) specification. Selector files are mostly compatible between the two specifications.
DKIMは、以前のDomainKeys（DK）の仕様を置き換えます。セレクタファイルは、2つの仕様の間でほとんど互換性があります。
A.1.1. Signers
A.1.1。署名者
A signer that currently signs with DK will go through various stages as it migrates to using DKIM, not all of which are required for all signers. The real questions that a signer needs to ask are:
それは、すべての署名者のために必要とされていないすべてがDKIMを使用してに移行すると、現在DKに署名し、署名者は、様々な段階を通過します。署名者が依頼する必要があります実際の質問は以下のとおりです。
1. how many receivers or what types of receivers are *only* looking at the DK signatures and not the DKIM signatures, and
1.どのように多くの受信機や受信機の種類*のみ* DK署名を見ていませんDKIM署名、および
If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if all "large players" are looking at DKIM in addition to or instead of DK, a signer can choose to stop signing with DK.
誰もが任意のより多くのDK署名を見ていない場合、それはDKで署名する必要がなくなりました。すべての「大選手は」DKまたは代わりに加えて、DKIMを見ている場合や、署名者は、DKと契約を停止することを選択できます。
With respect to signing policies, a reasonable, initial approach is to use DKIM signatures in the same way that DomainKeys signatures are already being used. In particular, the same selectors and DNS key records can be used for both, after verifying that they are compatible as discussed below.
署名ポリシーに関しては、合理的な、最初のアプローチは、DomainKeysの署名がすでに使用されているのと同じようにDKIM署名を使用することです。具体的には、同じセレクタとDNSキーレコードは後述するように、それらが互換性があることを確認した後、両方のために使用することができます。
Each secondary step in all of the following scenarios is to be prefaced with the gating factor "test, then when comfortable with the previous step's results, continue".
次のシナリオの全ての各二次のステップは、「その後、テスト、継続前のステップの結果とするとき、快適な」ゲーティング要因と前置きします。
One migration strategy is to:
一つの移行戦略は、以下のとおりです。
o ensure that the current selector DNS key record is compatible with both DK and DKIM
O現在の選択DNSキーレコードがDKとDKIMの両方と互換性があることを確認
o sign messages with both DK and DKIM signatures
Oの両方DKとDKIM署名付きのメッセージに署名
o when it's decided that DK signatures are no longer necessary, stop signing with DK
DK署名はもはや必要であることを決めたんだときO、DKと契約を停止
Another migration strategy is to:
別の移行戦略は、以下のとおりです。
o add a new selector DNS key record only for DKIM signatures
OのみDKIM署名のための新しいセレクタDNSキーレコードを追加
o sign messages with both DK (using the old DNS key record) and DKIM signatures (using the new DNS key record)
O（新しいDNSキーレコードを使用して）DK（旧DNSキーレコードを使用）、DKIM署名の両方でメッセージに署名
o when it's decided that DK signatures are no longer necessary, stop signing with DK
DK署名はもはや必要であることを決めたんだときO、DKと契約を停止
o eventually remove the old DK selector DNS record
O最終的に古いDKセレクタDNSレコードを削除
A combined migration strategy is to:
組み合わせ移行戦略は、以下のとおりです。
o ensure that the current selector DNS key record is compatible with both DK and DKIM
O現在の選択DNSキーレコードがDKとDKIMの両方と互換性があることを確認
o start signing messages with both DK and DKIM signatures
Oの両方DKとDKIM署名付きのメッセージに署名を開始
o add a new selector DNS key record for DKIM signatures
O DKIM署名のための新しいセレクタDNSキーレコードを追加
o switch the DKIM signatures to use the new selector
O新しいセレクタを使用するDKIM署名を切り替えます
o when it's decided that DK signatures are no longer necessary, stop signing with DK
DK署名はもはや必要であることを決めたんだときO、DKと契約を停止
o eventually remove the old DK selector DNS record
O最終的に古いDKセレクタDNSレコードを削除
Another migration strategy is to:
別の移行戦略は、以下のとおりです。
o add a new selector DNS key record for DKIM signatures
O DKIM署名のための新しいセレクタDNSキーレコードを追加
o do a flash cut and replace the DK signatures with DKIM signatures
Oフラッシュカットを行い、DKIM署名付きDK署名を置き換えます
o eventually remove the old DK selector DNS record
O最終的に古いDKセレクタDNSレコードを削除
Another migration strategy is to:
別の移行戦略は、以下のとおりです。
o ensure that the current selector DNS key record is compatible with both DK and DKIM
O現在の選択DNSキーレコードがDKとDKIMの両方と互換性があることを確認
o do a flash cut and replace the DK signatures with DKIM signatures
Oフラッシュカットを行い、DKIM署名付きDK署名を置き換えます
Note that when you have separate key records for DK and DKIM, you can use the same public key for both.
あなたはDKとDKIMのための独立したキーレコードを持っている場合、あなたは両方に同じ公開鍵を使用することができます。
A.1.1.1. DNS Selector Key Records
A.1.1.1。 DNSセレクターキーレコード
The first step in some of the above scenarios is ensuring that the selector DNS key records are compatible for both DK and DKIM. The format of the DNS key record was intentionally meant to be backwardly compatible between the two systems, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one critical difference between DK and DKIM DNS key records. The definitions of the "g" fields:
上記のシナリオのいくつかの最初のステップは、選択キーレコードはDKとDKIMの両方に対して互換性があるDNSことを保証されます。 DNSキーレコードのフォーマットは、意図的に2つのシステム間の後方互換性があることを意味し、必ずしも上位互換性がなかったです。 DKIMは、DKが無視する必要のあるいくつかのオプションのパラメータを追加することにより、DK DNSキーレコード形式を、強化しました。しかし、DKとDKIM DNSキーレコードの間に1つの重要な違いがあります。 「G」フィールドの定義：
g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. DKIM allows wildcards where DK does not. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. In DKIM, both a missing value and "g=*;" mean to allow any sending address.
G =キーの粒度：DKとDKIMの両方で、このアドレスを送信した制約するために使用されるオプションのフィールドである（ES）は合法的このセレクタを使用することができます。残念ながら、空のフィールドの処理は、（「G =;」）が異なります。 DKIMは、DKにはないワイルドカードを可能にします。 DKのために、空のフィールドは、欠損値と同じであり、任意の送信アドレスを可能として扱われます。 DKIMの場合は、空のフィールドは空のローカル部分と一致します。 DKIM、欠損値と「G = *;」の両方で任意の送信アドレスを許可する意味。
Also, in DomainKeys, the "g" field is required to match the address in "From:"/"Sender:", while in DKIM, it is required to match i=. This might or might not affect transition.
= DKIMで、私を一致させるために必要とされている間、：/「送信者」：また、DomainKeysの中で、「G」欄は、「差出人」のアドレスを一致させるために必要とされます。これは、または遷移に影響を与えない場合があります。
If your DK DNS key record has an empty "g" field in it ("g=;"), your best course of action is to modify the record to remove the empty field. In that way, the DK semantics will remain the same, and the DKIM semantics will match.
あなたのDK DNSキーのレコードが（「G =;」）、その中に空の「G」のフィールドを持っている場合は、アクションのあなたの最高のコースは、空のフィールドを削除するには、レコードを変更することです。このように、DKセマンティクスは同じままになります、とDKIMセマンティクスが一致します。
If your DNS key record does not have an empty "g" field in it ("g=;"), it's probable that the record can be left alone. But the best course of action would still be to make sure that it has a "v" field. When the decision is made to stop supporting DomainKeys and to only support DKIM, it is important to verify that the "g" field is compatible with DKIM, and typically having "v=DKIM1;" in it. It is strongly encouraged that if use of an empty "g" field in the DKIM selector, include the "v" field.
あなたのDNSキーレコードが、その中に空の「G」のフィールドを持っていない場合（「G =;」）、それはレコードが一人で残すことができている可能性です。しかし、最善の行動はまだそれが「V」のフィールドを持っていることを確認することです。決定がドメインキーをサポート停止するのみDKIMをサポートするように構成されている場合、「G」フィールドは、DKIMと互換性があることを確認することが重要であり、典型的に有する「V = DKIM1と、」初期化。強くDKIMセレクタで空の「G」フィールドを使用する場合は、「V」のフィールドが含まれていることを奨励しています。
A.1.1.2. Removing DomainKeys Signatures
A.1.1.2。 DomainKeysの署名を削除します
The principal use of DomainKeys is at boundary MTAs. Because no operational transition is ever instantaneous, it is advisable to continue performing DomainKeys signing until it is determined that DomainKeys receive-side support is no longer used, or is sufficiently reduced. That is, a signer needs to add a DKIM signature to a message that also has a DomainKeys signature and keep it there until they decide it is deemed no longer useful. The signer can do its transitions in a straightforward manner, or more gradually. Note that because digital signatures are not free, there is a cost to performing both signing algorithms, so signing with both algorithms ought not be needlessly prolonged.
DomainKeysとの主な用途は、境界のMTAです。何の操作遷移は、これまで瞬時ではありませんので、DomainKeysと受信側のサポートがもはや使用されている、または十分に低減されていると判定されなくなるまでDomainKeysの署名を行い続けることをお勧めします。つまり、署名者はまた、DomainKeysの署名を持っているメッセージにDKIM署名を追加し、彼らはそれはもはや有用であると考えている決定しなくなるまでそこにそれを維持する必要があります。署名者は、より緩やかに直接的な方法でその遷移を行う、またはすることができます。デジタル署名がないわけではないので、それほど不延ばすことはないはず両方のアルゴリズムを用いて署名、両方の署名アルゴリズムを実行するコストがあることに留意されたいです。
The tricky part is deciding when DK signatures are no longer necessary. The real questions are: how many DomainKeys verifiers are there that do *not* also do DKIM verification, which of those are important, and how can you track their usage? Most of the early adopters of DK verification have added DKIM verification, but not all yet. If a verifier finds a message with both DK and DKIM, it can choose to verify both signatures, or just one or the other.
DK署名は、もはや必要な場合トリッキーな部分が決定されていません。実際の質問は以下のとおりです。DomainKeysの検証方法があること* *も重要であるそれらのどの、DKIMの検証をしないと、どのように自分の使用状況を追跡することができますどのように多くの？ DK検証の早期導入の大半は、DKIM検証を追加しましたが、すべてではない、まだしています。検証は、DKとDKIMの両方でメッセージを見つけた場合、それは両方の署名を検証することを選択することも、1つまたは他のことができます。
Many DNS services offer tracking statistics so it can be determined how often a DNS record has been accessed. By using separate DNS selector key records for your signatures, you can chart the use of your records over time, and watch the trends. An additional distinguishing factor to track would take into account the verifiers that verify both the DK and DKIM signatures, and discount those from counts of DK selector usage. When the number for DK selector access reaches a low-enough level, that's the time to consider discontinuing signing with DK.
DNSレコードがアクセスされた頻度を測定することができるので、多くのDNSサービスは、トラッキング統計情報を提供します。あなたの署名のために別々のDNS選択キーレコードを使用することで、時間をかけてあなたの記録の使用をグラフ化し、傾向を見ることができます。追跡するために、追加の特徴的な要因を考慮に両方DKとDKIM署名を検証する検証を取り、DKセレクタの使用状況のカウントからのものを割り引くでしょう。 DKセレクタにアクセスするための番号は、低十分なレベルに達すると、それは、DKと契約中止を検討する時間です。
Note, this level of rigor is not required. It is perfectly reasonable for a DK signer to decide to follow the "flash cut" scenario described above.
注は、厳格さのこのレベルは必要ありません。 DKの署名者は、上記の「フラッシュカット」のシナリオに従うことを決定することは完全に合理的です。
A.1.2. Verifiers
A.1.2。検証者
As a verifier, several issues need to be considered:
検証として、いくつかの問題を考慮する必要があります。
A.1.2.1. Ought DK signature verification be performed?
A.1.2.1。 DKの署名検証を実行するべき？
At the time of writing, there is still a significant number of sites that are only producing DK signatures. Over time, it is expected that this number will go to zero, but it might take several years. So it would be prudent for the foreseeable future for a verifier to look for and verify both DKIM and DK signatures.
執筆の時点では、唯一のDK署名を生産しているサイトのかなりの数が依然としてあります。時間が経つにつれて、この数がゼロになりますが、それは数年かかるかもしれないと期待されています。だから、探し、両方DKIMおよびDK署名を検証する検証のための予見可能な将来のために賢明だろう。
A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single message?
A.1.2.2。 DKとDKIMの両方の署名が単一のメッセージに評価されるべき？
For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message that has both types of signatures can verify both signatures, or just one. One disadvantage of verifying both signatures is that signers will have a more difficult time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails.
一定の期間については、DKとDKIMの両方で署名のサイトが存在します。署名の両方のタイプを有するメッセージを受信した検証者は、両方の署名、又は一つだけを検証することができます。両方の署名を検証する一つの欠点は、署名者がまだ彼らのDKセレクタを使用しているどのように多くの検証を決定する多くの困難な時期を持っているということです。一つの移行戦略は、DKIM署名を検証するDKIM検証が失敗した場合にのみDK署名を検証することです。
A.1.2.3. DNS Selector Key Records
A.1.2.3。 DNSセレクターキーレコード
The format of the DNS key record was intentionally meant to be backwardly compatible between DK and DKIM, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one key difference between DK and DKIM DNS key records. The definitions of the g fields:
DNSキーレコードのフォーマットは、意図的にDKとDKIMの間の後方互換性があることを意味し、必ずしも上位互換性がなかったです。 DKIMは、DKが無視する必要のあるいくつかのオプションのパラメータを追加することにより、DK DNSキーレコード形式を、強化しました。しかし、DKとDKIM DNSキーレコードの間に1つの重要な違いがあります。グラムのフィールドの定義：
g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part.
G =キーの粒度：DKとDKIMの両方で、このアドレスを送信した制約するために使用されるオプションのフィールドである（ES）は合法的このセレクタを使用することができます。残念ながら、空のフィールドの処理は、（「G =;」）が異なります。 DKのために、空のフィールドは、欠損値と同じであり、任意の送信アドレスを可能として扱われます。 DKIMの場合は、空のフィールドは空のローカル部分と一致します。
v= version of the selector It is advised that a DKIM selector have "v=DKIM1;" at its beginning, but it is not required.
DKIMセレクタが持っていることをお勧めしセレクターのV =バージョン「V = DKIM1を;」その冒頭で、これは必須ではありません。
If a DKIM verifier finds a selector record that has an empty "g" field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its beginning, it is faced with deciding if this record was:
DKIM検証は、空の「G」フィールド（「G =;」を）持っているセレクタレコードを見つけた場合、それが「V」フィールド（「V = DKIM1を;」）を持っていないその冒頭で、それが決定に直面していますこのレコードだった場合：
1. from a DK signer that transitioned to supporting DKIM but forgot to remove the "g" field (so that it could be used by both DK and DKIM verifiers); or
DKIMをサポートするに遷移が、（それがDKとDKIMの両方の検証で使用することができるように）「G」フィールドを削除するのを忘れDK署名者から1。または
2. from a DKIM signer that truly meant to use the empty "g" field but forgot to put in the "v" field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a "g" field in the record.
本当に空の「G」フィールドを使用することを意図したが、「V」のフィールドに置くのを忘れDKIM署名者から2。あなたが最初の解釈を使用して、このようなレコードを扱い、署名者は、レコードに「G」フィールドを持っていなかったかのようなレコードを扱うことをお勧めします。
A.2. Migrating Hash Algorithms
A.2。移行ハッシュアルゴリズム
[RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256. The security of all hash algorithms is constantly under attack, and SHA-1 has already shown weaknesses as of this writing. Migrating from SHA-1 to SHA-256 is not an issue, because all verifiers are already required to support SHA-256. But when it becomes necessary to replace SHA-256 with a more secure algorithm, there will be a migratory period. In the following, "NEWHASH" is used to represent a new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this scenario.
SHA-1、SHA-256：[RFC4871]は2つのハッシュアルゴリズムの使用を規定します。すべてのハッシュアルゴリズムのセキュリティは常に攻撃を受けている、とSHA-1は既にこの書き込みのような弱点を示しています。すべての検証はすでにSHA-256をサポートするために必要とされるので、SHA-1からSHA-256に移行することは、問題ではありません。それはより安全なアルゴリズムでSHA-256を交換することが必要になった場合でも、回遊期間があるでしょう。以下、「NEWHASH」では、新たなハッシュアルゴリズムを表すために使用されます。 [RFC4871]のセクション4.1には、簡単に、このシナリオについて説明します。
A.2.1. Signers
A.2.1。署名者
As with migrating from DK to DKIM, migrating hash algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing hash algorithms are considered and how important that is to the signers.
DKからDKIMへの移行と同様に、ハッシュアルゴリズムの移行は、古いアルゴリズムおよび検証することにより、新しいアルゴリズムの予想サポートして署名することを続けるの有用性についての署名者の最良の推測に依存しています。古いアルゴリズムで署名を続けるのユーティリティは、既存のハッシュアルゴリズムを考慮し、署名者にどのように重要なことされて壊れたかに基づいています。
One strategy is to wait until it's determined that there is a large enough base of verifiers available that support NEWHASH, and then flash cut to the new algorithm.
1つの戦略は、そこNEWHASHをサポート可能な検証者の十分な大きさのベースがあり、その後、新しいアルゴリズムにカット点滅していると判断されるまで待つことです。
Another strategy is to sign with both the old and new hash algorithms for a period of time. This is particularly useful for testing the new code to support the new hash algorithm, as verifiers will continue to accept the signature for the older hash algorithm and ought to ignore any signature that fails because the code is slightly wrong. Once the signer has determined that the new code is correct AND it's determined that there is a large enough base of verifiers available that support NEWHASH, the signer can flash cut to the new algorithm.
別の戦略は、しばらくの間、新旧両方のハッシュアルゴリズムに署名することです。これは、検証者は、古いハッシュアルゴリズムのための署名を受け入れ続け、コードは少し間違っているので、失敗した任意の署名を無視するべきだろうとして、新しいハッシュアルゴリズムをサポートする新しいコードをテストするために特に有用です。署名者は、新しいコードが正しいと判断しており、それがNEWHASHをサポート可能な検証者の十分な大きさのベースがあると判断しています後は、署名者は、新しいアルゴリズムにカット点滅することができます。
One advantage migrating hash algorithms has is that the selector can be completely compatible for all hash algorithms. The key selector has an optional "h=" field that can be used to list the hash algorithms being used; it also is used to limit the algorithms that a verifier will accept. If the signer is not currently using the key selector "h=" field, no change is required. If the signer is currently using the key selector "h=" field, NEWHASH will need to be added to the list, as in "h=sha256:NEWHASH;". (When the signer is no longer using SHA-256, it can be removed from the "h=" list.)
ハッシュアルゴリズムを移行する一つの利点は、セレクタは、すべてのハッシュアルゴリズムのために完全に適合することができることであるています。キーセレクタは、使用されるハッシュアルゴリズムをリストするために使用することができるオプションの「H =」フィールドを有しています。また、検証者が受け入れるアルゴリズムを制限するために使用されます。署名者が現在キーセレクタ「H =」フィールドを使用していない場合は、変更は必要とされません。署名者が現在キーセレクタ「H =」フィールドを使用している場合、NEWHASHは同様に、リストに追加する必要があります「H = SHA256：NEWHASH;」。 （署名者は、SHA-256を使用しなくなった場合、それは「H =」リストから削除することはできません。）
A.2.2. Verifiers
A.2.2。検証者
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.
新しいハッシュアルゴリズムが標準化になると、それは可能な限り迅速に、それを支える開始するための検証に最適です。
A.3. Migrating Signing Algorithms
A.3。署名アルゴリズムの移行
[RFC4871] defines the use of the RSA signing algorithm. Similar to hashes, signing algorithms are constantly under attack, and when it becomes necessary to replace RSA with a newer signing algorithm, there will be a migratory period. In the following, "NEWALG" is used to represent a new signing algorithm.
[RFC4871]はRSA署名アルゴリズムの使用を規定します。ハッシュと同様に、署名アルゴリズムは、攻撃を受けて常にあり、それが新しい署名アルゴリズムとRSAの交換が必要になった場合、回遊期間があるでしょう。以下では、「NEWALGは」新しい署名アルゴリズムを表すために使用されます。
A.3.1. Signers
A.3.1。署名者
As with the other migration issues discussed above, migrating signing algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing signing algorithms are considered and how important that is to the signers.
上記の他の移行の問題と同じように、署名アルゴリズムを移行することは、古いアルゴリズムおよび検証することにより、新しいアルゴリズムの予想サポートして署名することを続けるの有用性についての署名者の最良の推測に依存しています。古いアルゴリズムで署名を続けるのユーティリティは、署名者にある既存のアルゴリズムが考慮されている署名とどのように重要なの壊れた方法に基づいています。
As before, the two basic strategies are to 1) wait until there is sufficient base of verifiers available that support NEWALG and then do a flash cut to NEWALG, and 2) use a phased approach by signing with both the old and new algorithms before removing support for the old algorithm.
前と同じように、二つの基本的な戦略は1にある）NEWALGをサポート可能な検証の十分な塩基があるまで待機してからNEWALGにフラッシュカットを行い、そして2）取り外す前に、新旧両方のアルゴリズムで署名することにより、段階的なアプローチを使用します古いアルゴリズムのサポート。
It is unlikely that a new algorithm would be able to use the same public key as "rsa", so using the same selector DNS record for both algorithms' keys is ruled out. Therefore, in order to use the new algorithm, a new DNS selector record would need to be deployed in parallel with the existing DNS selector record for the existing algorithm. The new DNS selector record would specify a different "k=" value to reflect the use of NEWALG.
新しいアルゴリズムはそれほど除外される両アルゴリズムキーの同じセレクタDNSレコードを使用して、「RSA」と同じ公開鍵を使用することができるだろうということはほとんどありません。したがって、新しいアルゴリズムを使用するために、新しいDNSセレクタレコードは、既存のアルゴリズムのための既存のDNSセレクタ記録と並行して展開される必要があるであろう。新しいDNSセレクタレコードはNEWALGの使用を反映するために、異なる「K =」値を指定することになります。
A.3.2. Verifiers
A.3.2。検証者
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.
新しいハッシュアルゴリズムが標準化になると、それは可能な限り迅速に、それを支える開始するための検証に最適です。
Appendix B. General Coding Criteria for Cryptographic Applications
付録B.一般的には、暗号アプリケーションのための基準をコーディング
NOTE: This section could possibly be changed into a reference to something else, such as another RFC.
注：このセクションでは、おそらく、そのような別のRFCとして、何か他のものへの参照に変更することができます。
Correct implementation of a cryptographic algorithm is a necessary but not a sufficient condition for the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications.
暗号アルゴリズムの正しい実装は、暗号アプリケーションのコーディングのための十分条件必要はありませんです。暗号化ライブラリのコード化は、暗号アプリケーションに固有なセキュリティ上の考慮事項に細心の注意が必要です。
In addition to the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers need to pay close attention to management of cryptographic private keys and session keys, ensuring that these are correctly initialized and disposed of.
そのようなバッファまたは整数オーバーフローやアンダーフローを避けるなどの通常のセキュリティコーディングの考慮に加えて、実装者は、これらが正しく初期化され、処分されることを確実にすること、暗号化秘密鍵とセッション鍵の管理に細心の注意を払う必要があります。
Operating system mechanisms that permit the confidentiality of private keys to be protected against other processes ought to be used when available. In particular, great care needs to be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes.
秘密鍵の機密性を許可するオペレーティングシステムのメカニズムは、他のプロセスから保護するためには、利用可能なときに使用されるべきです。具体的には、細心の注意は、秘密鍵の情報が他のプロセスに開示されていないことを確認するために、オペレーティング・システムにメモリページを解放する際に注意が必要です。
Certain implementations of public key algorithms such as RSA can be vulnerable to a timing analysis attack.
RSAなどの公開鍵アルゴリズムの特定の実装では、タイミング解析攻撃に対して脆弱であることができます。
Support for cryptographic hardware providing key management capabilities is strongly encouraged. In addition to offering performance benefits, many cryptographic hardware devices provide robust and verifiable management of private keys.
鍵管理機能を提供する暗号化ハードウェアのサポートが強く推奨されます。パフォーマンス上の利点を提供することに加えて、多くの暗号化ハードウェア・デバイスは、秘密鍵の堅牢かつ検証可能な管理機能を提供します。
Fortunately, appropriately designed and coded cryptographic libraries are available for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic libraries is strongly encouraged. These have been extensively tested, reduce development time and support a wide range of cryptographic hardware.
幸いなことに、適切に設計されており、コード化された暗号化ライブラリは、商用、オープンソースとフリーソフトウェアライセンス条項と互換性のある許諾条件の下で、ほとんどのオペレーティング・システム・プラットフォームで利用可能です。標準の暗号化ライブラリを使用することが強く推奨されます。これらは、広範囲に開発時間を短縮し、暗号化ハードウェアの広い範囲をサポートし、テストされています。
Authors' Addresses
著者のアドレス
Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA
トニー・ハンセンAT＆T研究所200ローレルアベニュー。南ミドルタウン、NJ 07748 USA
EMail: tony+dkimov@maillennium.att.com
メールアドレス：tony+dkimov@maillennium.att.com
Ellen Siegel Consultant
エレンシーゲルコンサルタント
EMail: dkim@esiegel.net
メールアドレス：dkim@esiegel.net
Phillip Hallam-Baker Default Deny Security, Inc.
フィリップハラム - ベイカーデフォルト拒否Security社
EMail: phillip@hallambaker.com
メールアドレス：phillip@hallambaker.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
デイブ・クロッカーブランデンブルクインターネットワーキング675スプルース博士はカリフォルニア州サニーベール94086 USA
EMail: dcrocker@bbiw.net
メールアドレス：dcrocker@bbiw.net