[要約] RFC 5016は、DKIM署名の実践プロトコルに関する要件を定義しています。その目的は、DKIM署名の実装と運用に関するガイドラインを提供することです。
Network Working Group M. Thomas
Request for Comments: 5016 Cisco Systems
Category: Informational October 2007
Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
domainkeys識別されたメール（DKIM）署名プラクティスプロトコルの要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD).
Domainkeys Idefied Mail（DKIM）は、ドメインが処理するメッセージに対する責任を主張する暗号化メカニズムを提供します。関連するメカニズムにより、管理者はDKIMの署名慣行に関するさまざまなステートメントを公開できます。このドキュメントでは、このメカニズムの要件を定義し、満たさなければならない（必須）と非常に望ましい（すべき）要件を区別します。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions and Requirements Language ...........................3
3. SSP Problem Scenarios ...........................................4
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
4. SSP Deployment Considerations ...................................6
4.1. Deployment Consideration 1: Outsourced Signing .............6
4.2. Deployment Consideration 2: Subdomain Coverage .............6
4.3. Deployment Consideration 3: Resent Original Mail ...........7
4.4. Deployment Consideration 4: Incremental Deployment
of Signing .................................................7
4.5. Deployment Consideration 5: Performance and Caching ........8
4.6. Deployment Consideration 6: Human Legibility of Practices ..8
4.7. Deployment Consideration 7: Extensibility ..................8
4.8. Deployment Consideration 8: Security .......................8
5. Requirements ....................................................9
5.1. Discovery Requirements .....................................9
5.2. SSP Transport Requirements ................................10
5.3. Practice and Expectation Requirements .....................10
5.4. Extensibility and Forward Compatibility Requirements ......13
6. Requirements for SSP Security ..................................13
7. Security Considerations ........................................13
8. Acknowledgments ................................................13
9. References .....................................................14
9.1. Normative References ......................................14
DomainKeys Identified Mail [RFC4871] defines a message level signing and verification mechanism for email. While a DKIM signed message speaks for itself, there is ambiguity if a message doesn't have a valid first party signature (i.e., on behalf of the [RFC2822].From address): is this to be expected or not? For email, this is an especially difficult problem since there is no expectation of a priori knowledge of a sending domain's practices. This ambiguity can be used to mount a bid down attack that is inherent with systems like email that allow optional authentication: if a receiver doesn't know otherwise, it should not assume that the lack of a valid signature is exceptional without other information. Thus, an attacker can take advantage of the ambiguity and simply not sign messages. If a protocol could be developed for a domain to publish its DKIM signing practices, a message verifier could take that into account when it receives an unsigned piece of email.
domainkeys識別されたメール[RFC4871]は、電子メールのメッセージレベルの署名と検証メカニズムを定義します。DKIM署名されたメッセージはそれ自体を物語っていますが、メッセージに有効なファーストパーティの署名がない場合（つまり、[RFC2822]。アドレスから）：これは予想されるかどうか？電子メールの場合、これは特に困難な問題です。なぜなら、送信ドメインの実践に関する先験的な知識に期待されていないからです。このあいまいさは、オプションの認証を許可する電子メールなどのシステムに固有の入札攻撃を取り付けるために使用できます。レシーバーがそうでないことを知らない場合、有効な署名の欠如が他の情報なしで例外的であると仮定すべきではありません。したがって、攻撃者はあいまいさを利用して、単にメッセージに署名しないことができます。ドメインがDKIMの署名プラクティスを公開するためにプロトコルを開発できる場合、メッセージ検証者は、署名されていない電子メールを受信したときにそれを考慮することができます。
This document defines the requirements for a mechanism that permits the publication of Sender Signing Practices (SSP). The document is organized into two main sections: first, a Problem and Deployment Scenario section that describes the problems that SSP is intended to address as well as the deployment issues surrounding the base problems, and the second section is the Requirements that arise because of those scenarios.
このドキュメントでは、送信者署名プラクティス（SSP）の公開を許可するメカニズムの要件を定義します。ドキュメントは2つの主要なセクションに編成されています。1つ目は、SSPが対処することを意図している問題と基本問題を取り巻く展開の問題を説明する問題と展開シナリオセクションのセクションであり、2番目のセクションは、それらのために発生する要件です。シナリオ。
o Domain Holder: the entity that controls the contents of the DNS subtree starting at the domain, either directly or by delegation via NS records it controls.
o ドメインホルダー：DNSサブツリーの内容を制御するエンティティは、ドメインから直接またはNSレコードを介して委任します。
o First Party Address: for DKIM, a first party address is defined to be the [RFC2822].From address in the message header; a first party address is also known as an Author address.
o ファーストパーティアドレス：dkimの場合、ファーストパーティアドレスは[RFC2822]であると定義されています。メッセージヘッダーのアドレスから。ファーストパーティアドレスは、著者アドレスとしても知られています。
o First Party Signature: a first party signature is a valid signature where the signing identity (the d= tag or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [RFC4871].
o ファーストパーティの署名：ファーストパーティの署名は、署名ID（D =タグまたはより具体的なID I =タグ）がファーストパーティアドレスと一致する有効な署名です。このコンテキストの「一致」は[RFC4871]で定義されています。
o Third Party Signature: a third party signature is a valid signature that does not qualify as a first party signature. Note that a DKIM third party signature is not required to correspond to a header field address such as the contents of Sender or List-Id, etc.
o サードパーティの署名：サードパーティの署名は、ファーストパーティの署名として資格がない有効な署名です。DKIMのサードパーティの署名は、送信者の内容やList-IDなどのヘッダーフィールドアドレスに対応する必要はないことに注意してください。
o Practice: a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends.
o 実践：[RFC2822]に従ってのステートメント。送信する電子メールメッセージの外部的に検証可能な動作のドメインホルダーから。
o Expectation: an expectation combines with a practice to convey what the domain holder considers the likely survivability of the practice for a receiver, in particular receivers that may be more than one SMTP hop away.
o 期待：期待は、ドメインホルダーがレシーバー、特に1つ以上のSMTPが飛び回る可能性のあるレシーバーのプラクティスの生存性の可能性を考慮するものを伝えるために、実践と組み合わされます。
o DKIM Signing Complete: a practice where the domain holder asserts that all legitimate mail will be sent with a valid first party signature.
o DKIM署名完全：ドメインホルダーがすべての正当なメールが有効なファーストパーティの署名で送信されると主張するプラクティス。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The email world is a diverse place with many deployment considerations. This section outlines expected usage scenarios where DKIM signing/verifying will take place, and how a new protocol might help to clarify the relevance of DKIM-signed mail.
電子メールの世界は、多くの展開に関する考慮事項がある多様な場所です。このセクションでは、DKIMの署名/検証が行われる予定の使用シナリオと、新しいプロトコルがDKIMに署名したメールの関連性を明確にするのにどのように役立つかを概説します。
After auditing their outgoing mail and deploying DKIM signing for all of their legitimate outgoing mail, a domain could be said to be DKIM signing complete. That is, the domain has, to the best of its ability, ensured that all legitimate mail purporting to have come from that domain contains a valid DKIM signature.
発信郵便を監査し、すべての正当な発信メールのためにDKIMの署名を展開した後、ドメインはDKIMの完全な署名であると言えます。つまり、ドメインは、その能力を最大限に活用して、そのドメインから来たと主張するすべての正当なメールに有効なDKIM署名が含まれていることを保証しました。
A receiver in the general case doesn't know what the practices are for a given domain. Thus, the receiver is at a disadvantage in not knowing whether or not it should expect all mail to be signed from a given domain. This knowledge gap leads to a trivially exploitable bid-down attack where the attacker merely sends unsigned mail; since the receiver doesn't know the practices of the signing domain, it cannot treat the message any more harshly for lack of a valid signature.
一般的なケースのレシーバーは、特定のドメインのプラクティスが何であるかを知りません。したがって、受信者は、すべてのメールが特定のドメインから署名されることを期待すべきかどうかを知らないという点で不利です。この知識のギャップは、攻撃者が単に署名のないメールを送信するだけで、些細な悪用可能な入札攻撃につながります。受信者は、署名ドメインのプラクティスを知らないため、有効な署名がないためにメッセージを厳しく扱うことはできません。
An information service that allows a receiver to query for the practices and expectations of the first party domain when no valid first party signature is found could be useful in closing this gap. A receiver could use this information to treat such questionable mail with varying degrees of prejudice.
有効なファーストパーティの署名が見つからない場合、レシーバーがファーストパーティドメインの実践と期待を照会できるようにする情報サービスは、このギャップを埋めるのに役立ちます。受信者は、この情報を使用して、さまざまな程度の偏見でそのような疑わしいメールを扱うことができます。
Note that, for the foreseeable future, unrestricted use patterns of mail (e.g., where users may be members of mailing lists, etc.) will likely suffer occasional, non-malicious signature failure in transit. While probably not a large percentage of total traffic, this kind of breakage may be a significant concern for those usage patterns. This scenario defines where the sender cannot set any expectation as to whether an individual message will arrive intact.
予見可能な将来、無制限の使用パターンの郵便（例えば、ユーザーがメーリングリストのメンバーである可能性がある場合など）は、輸送中に時折、非悪質な署名の障害に苦しむ可能性が高いことに注意してください。おそらく総トラフィックの大部分はありませんが、この種の破損は、これらの使用パターンにとって大きな懸念事項になる可能性があります。このシナリオでは、個々のメッセージがそのまま到着するかどうかについて、送信者が期待を設定できない場所を定義します。
Even without that expectation, a receiver may be able to take advantage of the knowledge that the domain's practice is to sign all mail and bias its filters against unsigned or damaged in transit mail. This information should not be expected to be used in a binary yes/no fashion, but instead as a data point among others in a filtering system.
その予想がなくても、レシーバーは、ドメインの練習がすべてのメールに署名し、輸送メールでの符号なしまたは損傷を受けてフィルターをバイアスすることであるという知識を利用できる場合があります。この情報は、バイナリのはい/いいえの方法で使用されることは期待されませんが、代わりにフィルタリングシステムのデータポイントとして使用することが期待されるべきです。
The following exchange illustrates problem scenario 1.
次の交換は、問題のシナリオ1を示しています。
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken DKIM first party signature from Alice.
1. [RFC2822]を備えたメールドメインからアリスは、アリスからのDKIMの第一党の署名が欠落している、または壊れたDKIMの署名でドメインボブに送られます。
2. Domain Bob would like to know whether that is an expected state of affairs.
2. ドメインボブは、それが予想される状況であるかどうかを知りたいと思います。
3. Domain Alice provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature.
3. Domain Aliceは、すべての発信郵便に署名するという情報を提供しますが、無傷のファーストパーティの署名で到着するかどうかには期待していません。
4. Domain Bob could use this information to bias its filters to examine the message with some suspicion.
4. Domain Bobは、この情報を使用してフィルターをバイアスして、疑いのあるメッセージを調べることができます。
A class of mail typified by transactional mail from high-value domains is currently the target of phishing attacks. In particular, many phishing scams forge the [RFC2822].From address in addition to spoofing much of the content to trick unsuspecting users into revealing sensitive information. Domain holders sending this mail would like the ability to give an enhanced guarantee that mail sent with their domain name should always arrive with the proof that the domain holder consented to its transmission. That is, the message should contain a valid first party signature as defined above.
高価値ドメインからのトランザクションメールに代表される郵便のクラスは、現在、フィッシング攻撃の目標です。特に、多くのフィッシング詐欺は、[RFC2822]を偽造します。アドレスから、コンテンツの多くをスプーフィングして、疑いを持たないユーザーをだまして機密情報を明らかにします。このメールを送信するドメインホルダーは、ドメイン名で送信されたメールが送信されるメールが常にその送信に同意したことを証明して、常に届くように強化された保証を与える機能を希望します。つまり、メッセージには、上記で定義されている有効なファーストパーティ署名を含める必要があります。
From a receiver's standpoint, knowing that a domain not only signs all of its mail, but places a very high value on the receipt of a valid first party signature from that domain is helpful. Hence, a receiver knows that the sending domain signs all its mail, and that the sending domain considers mail from this domain particularly sensitive in some sense, and is asking the receiver to be more suspicious than it otherwise might be of a broken or missing first-party signature. A receiver with the knowledge of the sender's expectations in hand might choose to process messages not conforming to the published practices in a special manner. Note that the ability to state an enhanced guarantee of a valid signature means that senders should expect mail that traverses modifying intermediaries (e.g., mailing lists, etc.) will likely be quarantined or deleted; thus, this scenario is more narrow than problem scenario 1.
レシーバーの立場から、ドメインがすべてのメールに署名するだけでなく、そのドメインから有効なファーストパーティの署名の受領に非常に高い値を置くことが役立つことを知っています。したがって、受信者は、送信ドメインがすべてのメールに署名し、送信ドメインがこのドメインからのメールを何らかの意味で特に敏感であると見なしていることを知っています。 - パーティ署名。送信者の期待を手にした知識を持つ受信者は、公開されたプラクティスに準拠していないメッセージを特別な方法で処理することを選択する場合があります。有効な署名の強化された保証を述べる能力は、送信者が移動中の仲介者（メーリングリストなど）を移動するメールを期待する必要があることを意味することに注意してください。したがって、このシナリオは問題シナリオ1よりも狭いです。
Informative Note: a receiving filter may choose to treat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is very wrong.
有益なメモ：受信フィルターは、シナリオ2をシナリオ1よりもはるかに厳しく扱うことを選択できます。シナリオ1が奇妙に見える場合、シナリオ2は何かが非常に間違っているように見えます。
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken first party DKIM signature from domain Alice.
1. [RFC2822]を備えたメールドメインからアリスは、ドメインアリスから欠落または壊れたファーストパーティのsignatureでドメインボブに送られます。
2. Domain Bob would like to know whether that is an expected state of affairs.
2. ドメインボブは、それが予想される状況であるかどうかを知りたいと思います。
3. Domain Alice provides information that it signs all outgoing mail, and furthermore places an expectation that it should arrive with an intact first party signature, and that the receiver should be much more wary if it does not.
3. Domain Aliceは、すべての発信郵便に署名し、さらに、無傷のファーストパーティの署名で到着する必要があること、および受信者がそうでない場合ははるかに警戒する必要があることを期待する情報を提供します。
4. Domain Bob could use this information to bias its filters such that it examines the message with great suspicion.
4. ドメインボブは、この情報を使用してフィルターをバイアスして、メッセージを非常に疑いのあるものに調べることができます。
Given the problems enumerated above for which we'd like SSP to provide information to recipients, there are a number of scenarios that are not related to the problems that are to be solved, per se, but the actual mechanics of implementing/deploying the information service that SSP would provide.
SSPに受信者に情報を提供したい上記の上記の問題を考えると、解決すべき問題に関連していない多くのシナリオがありますが、情報を実装/展開する実際のメカニズムがあります。SSPが提供するサービス。
Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable for a domain holder to have the ability to delegate to other entities the ability to sign for the domain holder. One obvious use scenario is a domain holder from a small domain that needs to have the ability for their outgoing ISP to sign all of their mail on behalf of the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions, such as insurance benefits, etc.
多くのドメインは、独自のメールインフラストラクチャを実行していないか、その一部を第三者に外注する場合があります。ドメインホルダーが他のエンティティにドメインホルダーに署名する機能を委任する機能を持つことが望ましいです。明らかな使用シナリオの1つは、小規模ドメインのドメインホルダーであり、発信ISPがドメインホルダーに代わってすべてのメールに署名する機能を備えている必要があります。その他の使用シナリオには、マーケティングキャンペーン用のアウトソーシングバルクメール、および保険給付などのさまざまなビジネス機能のアウトソーシングが含まれます。
An SSP client will perform lookups on incoming mail streams to provide the information as proposed in the problem scenarios. The domain part of the first address of the [RFC2822].From will form the basis to fetch the published information. A trivial attack to circumvent finding the published information can be mounted by simply using a subdomain of the parent domain that doesn't have published information. This attack is called the subdomain attack: that is, a domain wants to not only publish a policy for a given DNS label it controls, but it would also like to protect all subdomains of that label as well. If this characteristic is not met, an attacker would need only create a possibly fictitious subdomain that was not covered by the SSP's information service. Thus, it would be advantageous for SSP to not only cover a given domain, but all subdomains of that domain as well.
SSPクライアントは、入ってくるメールストリームの検索を実行して、問題シナリオで提案されている情報を提供します。[RFC2822]の最初のアドレスのドメイン部分は、公開された情報を取得するための基礎を形成します。公開された情報を見つけることを回避するための些細な攻撃は、公開されていない親ドメインのサブドメインを使用するだけで取り付けることができます。この攻撃はサブドメイン攻撃と呼ばれます。つまり、ドメインは、制御する特定のDNSラベルのポリシーを公開するだけでなく、そのラベルのすべてのサブドメインも保護したいと考えています。この特性が満たされていない場合、攻撃者はSSPの情報サービスでカバーされていない架空のサブドメインを作成するだけです。したがって、SSPが特定のドメインをカバーするだけでなく、そのドメインのすべてのサブドメインもカバーすることが有利です。
Resent mail is a common occurrence in many scenarios in the email world of today. For example, domain Alice sends a DKIM-signed message with a published practice of signing all messages to domain Bob's mailing list. Bob, being a good net citizen, wants to be able to take his part of the responsibility of the message in question, so he DKIM signs the message, perhaps corresponding to the Sender address.
Resent Mailは、今日の電子メールの世界では多くのシナリオで一般的な発生です。たとえば、ドメインアリスは、すべてのメッセージに署名するという公開されたプラクティスをドメインボブのメーリングリストに送信して、DKIMに署名したメッセージを送信します。良い純市民であるボブは、問題のメッセージの責任の一部を取ることができることを望んでいるので、彼はおそらく送信者アドレスに対応するメッセージに署名します。
Note that this scenario is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wants to assert his part in the chain of accountability for the benefit of the ultimate receivers. It would be useful for this practice to be encouraged as it gives a more accurate view of who handled the message. It also has the side benefit that remailers that break DKIM first party signatures can be potentially assessed by the receiver based on the receiver's opinion of the signing domains that actually survived.
このシナリオは、アリスの署名がボブのメーリングリストを生き延びたかどうかに完全に直交していることに注意してください。ボブは、究極のレシーバーの利益のために説明責任のチェーンに彼の役割を主張したいだけです。このプラクティスは、メッセージを処理した人のより正確な見方を提供するため、奨励されるのに役立ちます。また、DKIMのファーストパーティの署名を破るリメイラーが、実際に生き残った署名ドメインの受信者の意見に基づいて、受信機によって潜在的に評価される可能性があるという側面の利点もあります。
As a practical matter, it may be difficult for a domain to roll out DKIM signing such that they can publish the DKIM Signing Complete practice given the complexities of the user population, the outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail, such as in Problem Scenario 2, must be classified to the least common denominator of the published practices. It would be desirable to allow a domain holder to publish a list of exceptions that would have a more restrictive practices statement. NB: this consideration has been deemed met by the mechanisms provided by the base DKIM signing mechanism; it is merely documented here as having been an issue.
実用的な問題として、ドメインがDKIMの署名を展開することは困難な場合があります。これにより、ユーザー母集団の複雑さ、アウトソーシングベンダーがその代わりに送信するなど、完全な練習を公開することができます。問題シナリオ2などの価値の高いメールは、公開されているプラクティスの最も一般的ではない分母に分類する必要があります。ドメインホルダーが、より制限的なプラクティスステートメントを持つ例外のリストを公開できるようにすることが望ましいでしょう。NB：この考慮事項は、DKIMの署名メカニズムによって提供されるメカニズムによって満たされていると見なされています。ここでは問題であると単に文書化されています。
For example, bigbank.example.com might be ready to say that statements@bigbank.example.com is always signed, but the rest of the domain, say, is not. Another situation is that the practices of some address local parts in a given domain are not the same as practices of other local parts. Using the same example of statements@bigbank.example.com being a transactional kind of email that would like to publish very strong practices, mixed in with the rest of the user population local parts, which may go through mailing lists, etc., for which a less strong statement is appropriate.
たとえば、bigbank.example.comは、statements@bigbank.example.comが常に署名されていると言う準備ができているかもしれませんが、たとえば残りのドメインはそうではありません。別の状況は、特定のドメイン内の一部の地元の部分に対処することが、他のローカルパーツの実践と同じではないことです。statements@bigbank.example.comの同じ例を使用して、非常に強力なプラクティスを公開したいトランザクションの電子メールであり、他のユーザー母集団のローカルパーツと混ざり合い、メーリングリストなどを通過する可能性があります。それほど強くない声明が適切です。
It should be said that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in order to publish a strong practice, one only has to segregate those cases into different subdomains. For example: accounts.bigbank.example.com would publish constrained practices, while corporateusers.bigbank.example.com might publish more permissive practices.
DKIMは、サブドメインを使用することにより、この種の差別化をすでにサポートできると言われるべきです。つまり、強力なプラクティスを公開するためには、これらのケースを異なるサブドメインに分離する必要があります。たとえば、accounts.bigbank.example.comは制約されたプラクティスを公開しますが、CorporateUsers.bigbank.example.comはより寛容なプラクティスを公開する可能性があります。
Email service provides an any-any mesh of potential connections: all that is required is the publication of an MX record and an SMTP listener to receive mail. Thus, the use of SSP is likely to fall into two main scenarios, the first of which are large, well-known domains that are in constant contact with one another. In this case, caching of records is essential for performance, including the caching of the non-existence of records (i.e., negative caching).
電子メールサービスは、潜在的な接続の任意のメッシュを提供します。必要なのは、MXレコードとSMTPリスナーの公開とメールを受信することだけです。したがって、SSPの使用は2つの主要なシナリオに分類される可能性があります。最初のシナリオは、互いに絶えず接触している大きくてよく知られているドメインです。この場合、レコードのキャッシュが不可欠であり、レコードの非存在のキャッシュ（つまり、ネガティブキャッシュ）が含まれます。
The second main scenario is when a domain exchanges mail with a much smaller volume domain. This scenario can be both perfectly normal as with the case of vanity domains, and unfortunately, a vector for those sending mail for anti-social reasons. In this case, we'd like the message exchange burden to SSP querier to be low, since many of the lookups will not provide a useful answer. Likewise, it would be advantageous to have upstream caching here as well so that, say, a mailing list exploder on a small domain does not result in an explosion of queries back at the root and authoritative server for the small domain.
2番目の主なシナリオは、ドメインがはるかに小さなボリュームドメインとメールを交換する場合です。このシナリオは、虚栄心ドメインの場合と同様に完全に正常である可能性があり、残念ながら、反社会的理由でメールを送信する人のためのベクトルです。この場合、SSP Querierへのメッセージ交換の負担は低くなります。多くの検索は有用な答えを提供しないからです。同様に、ここでも上流のキャッシュを持つことは有利です。たとえば、小さなドメインのメーリングリスト爆発物は、小さなドメインのルートと権威のあるサーバーでのクエリの爆発をもたらさないでしょう。
While SSP records are likely to be primarily consumed by an automaton, for the foreseeable future they are also likely to be inspected by hand. It would be nice to have the practices stated in a fashion that is also intuitive to the human inspectors.
SSPレコードは主にオートマトンによって消費される可能性がありますが、近い将来、手作業で検査される可能性もあります。人間の検査官にも直感的な方法で慣行を述べることは素晴らしいことです。
While this document pertains only to requirements surrounding DKIM signing practices, it would be beneficial for the protocol to be able to extend to other protocols.
このドキュメントは、DKIMの署名プラクティスを取り巻く要件のみに関係していますが、プロトコルが他のプロトコルに拡張できることは有益です。
SSP must be able to withstand life in a hostile, open-Internet environment. These include DoS attacks, and especially DoS attacks that leverage themselves through amplification inherent in the protocol. In addition, while a useful protocol may be built without strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols.
SSPは、敵対的なオープンインターネット環境で生活に耐えることができなければなりません。これらには、DOS攻撃、特にプロトコルに固有の増幅を通じて自分自身を活用するDOS攻撃が含まれます。さらに、情報サービスが提供する強力なソース認証なしで有用なプロトコルを構築することができますが、プロトコルまたは基礎となるプロトコルによって強力なソース認証へのパスを提供する必要があります。
This section defines the requirements for SSP. As with most requirements documents, these requirements define the MINIMUM requirements that a candidate protocol must provide. It should also be noted that SSP must fulfill all of the requirements.
このセクションでは、SSPの要件を定義します。ほとんどの要件文書と同様に、これらの要件は、候補プロトコルが提供する必要がある最小要件を定義します。また、SSPはすべての要件を満たす必要があることにも注意する必要があります。
Receivers need a means of obtaining information about a sender's DKIM practices. This requires a means of discovering where the information is and what it contains.
受信者には、送信者のDKIMプラクティスに関する情報を取得する手段が必要です。これには、情報がどこにあり、何が含まれているかを発見する手段が必要です。
1. The author is the first-party sender of a message, as specified in the [RFC2822].From field. SSP's information is associated with the author's domain name, and is published subordinate to that domain name.
1. 著者は、[RFC2822]で指定されているように、フィールドから指定されているメッセージのファーストパーティの送信者です。SSPの情報は著者のドメイン名に関連付けられており、そのドメイン名に従属する公開されています。
2. In order to limit the cost of its use, any query service supplying SSP's information MUST provide a definitive response within a small, deterministic number of message exchanges under normal operational conditions.
2. 使用のコストを制限するために、SSPの情報を提供するクエリサービスは、通常の運用条件下で少数の決定的な数のメッセージ交換内で決定的な応答を提供する必要があります。
Informative Note: this, for all intents and purposes is a prohibition on anything that might produce loops or result in extended delays and overhead; also though "deterministic" doesn't specify how many exchanges, the expectation is "few".
有益なメモ：これは、すべての意図と目的のために、ループを生成したり、遅延とオーバーヘッドを引き起こす可能性のあるものを禁止することです。また、「決定論的」は交換の数を指定していませんが、期待は「少ない」です。
Refs: Deployment Considerations, Sections 4.2 and 4.5.
参照：展開に関する考慮事項、セクション4.2および4.5。
3. SSP's publishing mechanism MUST be defined such that it does not lead to multiple resource records of the same type for different protocols residing at the same location.
3. SSPの公開メカニズムは、同じ場所に居住する異なるプロトコルについて、同じタイプの複数のリソースレコードにつながらないように定義する必要があります。
Informative note: an example is multiple resource record of the same type within a common DNS leaf. Hence, uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous referencing.
有益なメモ：例は、一般的なDNSリーフ内の同じタイプの複数のリソースレコードです。したがって、一意に定義された葉の名前または一意に定義されたリソースレコードタイプにより、明確な参照が保証されます。
Refs: Deployment Consideration, Section 4.2.
参照：展開の考慮、セクション4.2。
4. SSP retrieval SHOULD provide coverage for not only a given domain but all of its subdomains as well. It is recognized that there is some reasonable doubt about the feasibility of a widely accepted solution to this requirement. If the working group does not achieve rough consensus on a solution, it MUST document the relevant security considerations in the protocol specification.
4. SSP検索は、特定のドメインだけでなく、そのすべてのサブドメインもカバレッジを提供する必要があります。この要件に対する広く受け入れられているソリューションの実現可能性については、合理的な疑いがあることが認識されています。ワーキンググループがソリューションに関する大まかなコンセンサスを達成していない場合、プロトコル仕様に関連するセキュリティに関する考慮事項を文書化する必要があります。
Refs: Deployment Considerations, Sections 4.2 and 4.5.
参照：展開に関する考慮事項、セクション4.2および4.5。
The publication and query mechanism will operate as an internet-based message exchange. There are multiple requirements for this lower-layer service:
公開およびクエリメカニズムは、インターネットベースのメッセージ交換として動作します。この低層サービスには複数の要件があります。
1. The exchange SHOULD have existing widespread deployment of the transport layer, especially if riding on top of a true transport layer (e.g., TCP, UDP).
1. 交換には、特に真の輸送層（TCP、UDPなど）の上に乗っている場合、輸送層の既存の広範な展開が必要です。
Refs: Deployment Considerations, Sections 4.5 and 4.7.
参照：展開に関する考慮事項、セクション4.5および4.7。
2. The query/response in terms of latency time and the number of messages involved MUST be low (less than three message exchanges not counting retransmissions or other exceptional conditions).
2. 遅延時間と関連するメッセージの数の観点からのクエリ/応答は低い必要があります（再送信またはその他の例外的な条件をカウントしない3つのメッセージ交換）。
Refs: Deployment Consideration, Section 4.5.
参照：展開考慮事項、セクション4.5。
3. If the infrastructure doesn't provide caching (a la DNS), the records retrieved MUST provide initiators the ability to maintain their own cache. The existing caching infrastructure is, however, highly desirable.
3. インフラストラクチャがキャッシュ（a la dns）を提供しない場合、取得されたレコードは、イニシエーターに独自のキャッシュを維持する能力を提供する必要があります。ただし、既存のキャッシュインフラストラクチャは非常に望ましいです。
Refs: Deployment Consideration, Section 4.5.
参照：展開考慮事項、セクション4.5。
4. Multiple geographically and topologically diverse servers MUST be supported for high availability.
4. 地理的およびトポロジー的に多様なサーバーを高可用性のためにサポートする必要があります。
Refs: Deployment Considerations, Sections 4.5 and 4.7.
参照：展開に関する考慮事項、セクション4.5および4.7。
As stated in the definitions section, a practice is a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. As an example, a practice might be defined such that all email messages will contain a DKIM signature corresponding to the [RFC2822].From address. Since there is a possibility of alteration between what a sender sends and a receiver examines, an expectation combines with a practice to convey what the [RFC2822].From domain considers the likely outcome of the survivability of the practice at a receiver. For example, a practice that a valid DKIM for the [RFC2822].From address is present when it is sent from the domain, and an expectation that it will remain present and valid for all receivers whether topologically adjacent or not.
定義セクションに記載されているように、プラクティスは[RFC2822]によると、送信される電子メールメッセージの外部的に検証可能な動作のドメインホルダーからのステートメントです。例として、すべての電子メールメッセージに[RFC2822]に対応するDKIM署名が含まれるように、プラクティスが定義される場合があります。アドレスから。送信者が送信するものと受信者が調べるものとの間に変更が変更される可能性があるため、期待は、[RFC2822]を伝えるための実践と組み合わされます。たとえば、[RFC2822]の有効なDKIMがドメインから送信されると、アドレスから有効なDKIMが存在すること、およびトポロジカルに隣接するかどうかにかかわらず、すべての受信機に有効なままであることを期待しています。
1. SSP MUST be able to make practices and expectation assertions about the domain part of a [RFC2822].From address in the context of DKIM. SSP will not make assertions about other addresses for DKIM at this time.
1. SSPは、[RFC2822]のドメイン部分について、DKIMのコンテキストでのアドレスから慣行と期待の主張を作成できる必要があります。SSPは、現時点ではDKIMの他のアドレスについて主張しません。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参照：問題シナリオ1および2、セクション3.1および3.2。
2. SSP MUST provide a concise linkage between the [RFC2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a first party signature.
2. SSPは、[rfc2822] .fromとdkim i = tagのアイデンティティ、または署名に欠落している場合のデフォルトとの間に簡潔なリンケージを提供する必要があります。つまり、SSPは、ファーストパーティの署名としての資格のセマンティクスを正確に定義する必要があります。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参照：問題シナリオ1および2、セクション3.1および3.2。
3. SSP MUST be able to publish a practice that the domain's signing behavior is "DKIM Signing Complete". That is, all messages were transmitted with a valid first party signature.
3. SSPは、ドメインの署名行動が「DKIM署名完全」であるというプラクティスを公開できる必要があります。つまり、すべてのメッセージには有効なファーストパーティの署名が送信されました。
Refs: Problem Scenario 1, Section 3.1.
参照：問題シナリオ1、セクション3.1。
4. SSP MUST be able to publish an expectation that a verifiable first party DKIM signature should be expected on receipt of a message.
4. SSPは、メッセージの受信時に検証可能なファーストパーティDKIM署名が予想されるという期待を公開できる必要があります。
Refs: Problem Scenario 2, Section 3.2.
参照：問題シナリオ2、セクション3.2。
5. Practices and expectations MUST be presented in SSP syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown.
5. プラクティスと期待は、直感的な記述子を可能な限りSSP構文で提示する必要があります。たとえば、p =？p =不明としてよりよく表現されます。
Refs: Deployment Consideration, Section 4.6.
参照：展開考慮事項、セクション4.6。
6. Because DKIM uses DNS to store selectors, there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to an affiliated party of the domain holder's choosing. That is, the domain holder may set an NS record for _domainkey.example.com to delegate to an email provider who manages the entire namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com to a third party to constrain the third party to only be able to produce valid signatures in the benefits.example.com subdomain. Last, a domain holder can even use CNAME's to delegate individual leaf nodes. Given the above considerations, SSP need not invent a different means of allowing affiliated parties to sign on a domain's behalf at this time.
6. DKIMはDNSを使用してセレクターを保存するため、ドメインホルダーが_Domainkeyサブドメインのすべてまたは一部をドメインホルダーの選択の関連当事者に委任する能力が常にあります。つまり、ドメインホルダーは、_domainkey.example.comのNSレコードを設定して、名前空間全体を管理する電子メールプロバイダーに委任することができます。また、ドメインホルダーがその名前空間をサブドメインに分割して、第三者をさらに制限する機能もあります。たとえば、ドメインホルダーは、_domainkey.benefits.example.comのみを第三者に委任することができます。最後に、ドメインホルダーはCNAMEを使用して個々の葉のノードを委任することもできます。上記の考慮事項を考えると、SSPは、現時点で関連当事者がドメインに代わって署名することを許可する別の手段を発明する必要はありません。
Refs: Deployment Consideration, Section 4.4.
参照：展開の考慮、セクション4.4。
7. Practices and expectations MUST be presented as an information service from the signing domain to be consumed as an added factor to the receiver's local policy. In particular, a practice or expectation MUST NOT mandate any disposition stance on the receiver.
7. 実践と期待は、受信者のローカルポリシーに追加の要因として消費されるために、署名ドメインからの情報サービスとして提示されなければなりません。特に、実践または期待は、受信者に対する気質のスタンスを義務付けてはなりません。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参照：問題シナリオ1および2、セクション3.1および3.2。
8. There is no requirement that SSP publish practices of any/all third parties that MUST NOT sign on the domain holder's behalf. This should be considered out of scope.
8. SSPがドメインホルダーに代わって署名してはならない/すべての第三者のプラクティスを公開するという要件はありません。これは範囲外であると考えるべきです。
INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.
有益なメモ：これは、基本的に、プロトコルがブラックリストリポジトリであることに関心がある必要はないと言っています。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参照：問題シナリオ1および2、セクション3.1および3.2。
9. SSP MUST NOT be required to be invoked if a valid first party signature is found.
9. 有効なファーストパーティの署名が見つかった場合、SSPを呼び出す必要はありません。
Refs: Deployment Consideration, Section 4.2.
参照：展開の考慮、セクション4.2。
10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers.
10. SSPは、メッセージ内の非ファーストパーティシグネチャの存在を影響するメカニズムを提供してはなりません。この要件の結果は、プロトコルが第一党の署名者の慣行をサードパーティの署名者の慣行とリンクしてはならないことです。
INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver.
有益なメモ：この要件の主な推進力は、出版社が制御しているものに対してのみプラクティスを公開する必要があり、最終的にはレシーバーのローカルポリシーであるものを干渉すべきではないということです。
Refs: Deployment Consideration, Section 4.3.
参照：展開の考慮、セクション4.3。
1. SSP MUST NOT extend to any protocol other than DKIM for email at this time. SSP SHOULD be extensible for protocols other than DKIM.
1. SSPは、現時点での電子メールのDKIM以外のプロトコルに拡張してはなりません。SSPは、DKIM以外のプロトコルに対して拡張可能である必要があります。
Refs: Deployment Consideration, Section 4.7.
参照：展開の考慮、セクション4.7。
2. SSP MUST be able to add new practices and expectations within the existing discovery/transport/practices in a backward compatible fashion.
2. SSPは、既存の発見/輸送/慣行の中に新しい慣行と期待を後方互換性のある方法で追加できる必要があります。
Refs: Deployment Consideration, Section 4.7.
参照：展開の考慮、セクション4.7。
1. SSP for a high-value domain is potentially a high-value DoS target, especially since the unavailability of SSP's record could make unsigned messages less suspicious.
1. 特にSSPのレコードが利用できないため、署名のないメッセージが少なくなる可能性があるため、高価値ドメインのSSPは潜在的に高価値のDOSターゲットです。
2. SSP MUST NOT make highly leveraged amplification or make-work attacks possible. In particular, the work and message exchanges involved MUST be order of a constant.
2. SSPは、高度に活用された増幅またはメイクワーク攻撃を可能にしてはなりません。特に、関係する作業とメッセージの交換は、定数の順序でなければなりません。
Refs: Deployment Consideration, Section 4.8.
参照：展開の考慮、セクション4.8。
3. SSP MUST have the ability for a domain holder to provide SSP's data such that a receiver can determine that it is authentically from the domain holder with a large degree of certainty. SSP may provide means that provide less certainty in trade off for ease of deployment.
3. SSPには、ドメインホルダーがSSPのデータを提供する機能を備えている必要があります。これにより、レシーバーは、それが大きな確実性を持ってドメインホルダーから本物であると判断できます。SSPは、展開を容易にするためのトレードオフの確実性が低下する手段を提供する場合があります。
Refs: Deployment Consideration, Section 4.8.
参照：展開の考慮、セクション4.8。
This document defines requirements for a new protocol and the security related requirements are defined above. Since it is expected that the new protocol will use the DNS as a basis for the published SSP information, most if not all of the threats described in [RFC4686] will be applicable.
このドキュメントでは、新しいプロトコルの要件を定義し、セキュリティ関連の要件を上記で定義します。新しいプロトコルは、公開されているSSP情報の基礎としてDNSを使用すると予想されるため、[RFC4686]で説明されているすべての脅威ではないにしても、ほとんどの場合、ほとんどの脅威が適用されます。
Dave Crocker and Jim Fenton provided substantial review of this document. Thanks also to Vijay Gurbani and David Harrington for their helpful last call reviews.
Dave CrockerとJim Fentonは、この文書の実質的なレビューを提供しました。Vijay GurbaniとDavid Harringtonにも、最後のコールレビューをしてくれてありがとう。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686] Fenton、J。、「ドメインキーを動機付けた脅威の分析（DKIM）」、RFC 4686、2006年9月。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J.、およびM. Thomas、「Domainkeys Idified Mail（DKIM）署名」、RFC 4871、2007年5月。
Author's Address
著者の連絡先
Michael Thomas Cisco Systems 606 Sanchez St San Francisco, California 94114 USA
マイケルトーマスシスコシステム606サンチェスセントサンフランシスコ、カリフォルニア94114 USA
Phone: +1-408-525-5386
Fax: +1-408-525-5386
EMail: mat@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。