Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6541 Cloudmark, Inc.
Category: Experimental February 2012
ISSN: 2070-1721
DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures
ドメインキー・アイデンティファイド・メール（DKIM）認定サードパーティの署名
Abstract
抽象
This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.
この実験的な仕様は、ドメインキー・アイデンティファイド・メール（DKIM）メッセージの作成者の管理ドメインによって追加の署名に等価であると解釈されるべきであるサードパーティの署名権限の許可広告に対する修正を提案しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（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/rfc6541.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6541で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Email Architecture Terminology .............................3
3. Roles and Scope .................................................3
4. Queries and Replies .............................................4
4.1. Hash Selection .............................................4
4.2. Extension to DKIM ..........................................5
4.3. ATPS Query Details .........................................5
4.4. ATPS Reply Details .........................................7
5. Interpretation ..................................................8
6. Relationship to ADSP ............................................8
7. Experiment Process ..............................................8
8. IANA Considerations .............................................9
8.1. ATPS Tag Registry ..........................................9
8.2. Email Authentication Methods Registry Update ..............10
8.3. Email Authentication Result Names Registry Update .........10
8.4. DKIM Signature Tag Specifications Registry ................12
9. Security Considerations ........................................12
9.1. Hash Selection ............................................12
9.2. False Privacy .............................................12
9.3. Transient Security Failures ...............................13
9.4. Load on the DNS ...........................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Appendix A. Example Query and Reply ...............................15
Appendix B. Choice of DNS RR Type .................................15
Appendix C. Acknowledgements ......................................16
[DKIM] defines a mechanism for transparent domain-level signing of messages for the purpose of declaring that a particular ADministrative Management Domain (ADMD) takes some responsibility for a message.
[DKIM]特定の管理管理ドメイン（ADMD）は、メッセージのためのいくつかの責任を負うことを宣言するためにメッセージの透明なドメインレベルの署名のためのメカニズムを定義します。
DKIM, however, deliberately makes no binding between the DNS domain of the Signer and any other identity found in the message. Despite this, there is an automatic human perception that an Author Domain Signature (one for which the RFC5322.From domain matches the DNS domain of the Signer) is more valuable or trustworthy than any other.
DKIMは、しかし、故意に何の署名者のDNSドメインとメッセージで見つかった他のIDとの間の結合を行うものではありません。これにもかかわらず、著者ドメインシグネチャー（RFC5322.Fromドメインが署名者のDNSドメインと一致するための一つ）は、より価値のある、または任意の他のより信頼できる自動人間の知覚があります。
To enable a third party to apply DKIM signatures to messages, the DKIM specification suggests delegation to a third party of either subdomains or private keys, so that the third party can add DKIM signatures that appear to have been added by the Author ADMD. Absent is a protocol by which an Author ADMD can announce that messages bearing specific valid DKIM signatures on its mail, which are added by other ADMDs, are to be treated as if they were signed by the Author ADMD itself. This memo presents an experimental mechanism for doing so, called Authorized Third-Party Signatures (ATPS).
第三者が著者ADMDによって追加されているように見えるDKIM署名を追加できるように、メッセージにDKIM署名を適用するために第三者を有効にするには、DKIM仕様は、サブドメインまたは秘密鍵のいずれかの第三者への委任を示唆しています。不在著者ADMDは、それらが著者ADMD自体によって署名されたかのように他のADMDsによって加算され、そのメールに特定の有効なDKIM署名を担持するメッセージは、処理されるべきであることを知らせることが可能なプロトコルです。このメモは、認定サードパーティの署名（ATPS）と呼ばれるそのようにするための実験的なメカニズムを提示します。
ATPS augments the semantics of DKIM by providing to the Verifier multiple identifiers rather than one. Specifically, it validates the identifier found in the DKIM signature, and then provides the RFC5322.From domain for evaluation.
ATPSは検証複数の識別子ではなく、一つに提供することで、DKIMのセマンティクスを強化します。具体的には、DKIM署名で見つかった識別子を検証し、その後、評価用RFC5322.Fromドメインを提供します。
This memo also registers, per [AUTHRES], the means to indicate to agents downstream of the Verifier that a third-party signature verification occurred.
また、このメモは、[AUTHRES]あたり、サードパーティの署名検証が発生した検証の下流のエージェントに指示する手段を登録します。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Readers are advised to be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH].
読者は、材料及び用語[MAIL]で議論と[EMAIL-ARCH]に精通していることをお勧めします。
The context of this protocol involves the following roles:
このプロトコルのコンテキストは、以下の役割が含まれます。
o ADministrative Management Domains (ADMDs), whose DNS domain name(s) appear in the RFC5322.From field of a [MAIL] message;
そのDNSドメイン名（S）[MAIL]メッセージのRFC5322.Fromフィールドに現れるO管理管理ドメイン（ADMDs）。
o ATPS Signers, which apply [DKIM] signatures using their own domains, but on behalf of the message Author's ADMD; and
しかし、メッセージの作者のADMDの代わりに、自分のドメインを使用して、[DKIM]署名を適用ATPS署名者、O;そして
o the Verifier, who implements the signature validation procedures described in [DKIM].
[DKIM]に記載の署名検証手順を実装検証、O。
An ADMD implements this protocol if it wishes to announce that a signature from any in a set of specified DNS domains is to be considered equivalent to one from the ADMD itself. For example, an ADMD might wish to delegate signing authority for its DNS domain to an approved messaging service provider without doing the work of key transfer described in Appendix B.1.1 of [DKIM]. An authorized ATPS
それは指定されたDNSドメインのセット内の任意の署名がADMD自体からのものと同等と見なされるべきであることを発表することを望む場合ADMDは、このプロトコルを実装します。例えば、ADMDは[DKIM]の付録B.1.1に説明するキー転送の作業を行うことなく承認されたメッセージングサービスプロバイダにそのDNSドメインの署名権限を委任したいかもしれません。認可ATPS
Signer makes a claim of this relationship via new tags in the DKIM signature, and the ADMD confirms this claim by publishing a specific TXT record in its DNS.
署名者は、DKIM署名で新しいタグを経由して、この関係の主張を行い、ADMDはそのDNS内の特定のTXTレコードを公開することによって、この主張を確認しました。
A Verifier implements this protocol if it wishes to ensure that a message bears one or more signatures from sources authorized to sign mail on behalf of the ADMD, and identify for special treatment mail that meets (or does not meet) that criterion. It will do so by treating the Signer's authorization on behalf of the Author's ADMD to mean that the Signer's signature is equivalent to one affixed by the Author's ADMD.
それはメッセージがADMDの代わりにメールに署名する権限ソースから1つの以上のシグネチャを有することを確認し、その基準を満たす（あるいは満たしていない）特殊な治療メールを識別することを望む場合検証は、このプロトコルを実装します。これは、署名者の署名が著者のADMDで貼られているものと同等であることを意味すると著者のADMDに代わって署名者の承認を処理することによって、そうします。
This section describes in detail the queries issued, the replies received, and how they should be interpreted and applied.
このセクションでは、詳細に返信が受信発行されたクエリを記述し、それらがどのように解釈して適用されるべきです。
The Author's ADMD will indicate authorization of a third party to sign its mail via the presence of a DNS TXT record that contains an encoding of the third party's DNS domain name. There are two supported methods for doing so -- one that involves a plain copy of the third party's DNS domain name, and one that involves an encoded version of the name. The encoding mechanism is provided so that any domain name can be added to the DNS in a fixed length, so that longer third-party domain names are not excluded from participation because of the overall length limit on a DNS query.
著者のADMDは、サードパーティのDNSドメイン名のエンコーディングが含まれているDNSのTXTレコードの存在を経由してそのメールに署名するために、第三者の承認を示します。サードパーティのDNSドメイン名のプレーンなコピーを含み1、および名前のエンコードされたバージョンを必要とするものを - そうするためのサポートされている2つの方法があります。長いサードパーティのドメイン名が原因DNSクエリに対する全体的な長さの制限の参加から除外されないように、任意のドメイン名は、固定長でDNSに添加することができるように符号化機構が設けられています。
If selected, the encoding mechanism requires constructing a digest of the third party's DNS domain name. The Author ADMD MUST select a digest ("hash") method currently supported by DKIM (see Section 7.7 of [DKIM]), and this selection needs to be communicated to the ATPS Signer, as it is used in generation of the third-party signatures.
選択した場合は、エンコードメカニズムは、サードパーティのDNSドメイン名のダイジェストを構築する必要になります。ダイジェスト（「ハッシュ」）は、現在、DKIMによってサポートされる方法を選択しなければならない著者ADMDは（[DKIM]のセクション7.7を参照）、この選択は、それが、サードパーティの生成に使用されるように、ATPS署名者に伝達する必要があります署名。
Where the encoding mechanism is not used, the ATPS Signer MUST use a hash name of "none".
エンコードメカニズムが使用されていない場合は、ATPS署名者は、「なし」のハッシュ名を使用しなければなりません。
The full DNS mechanism is specified in Section 4.3.
完全なDNSメカニズムはセクション4.3で指定されています。
[DKIM] signatures contain a "tag=value" sequence. This protocol will add additional tags called "atps" and "atpsh".
[DKIM]署名が「タグ=値」配列を含みます。このプロトコルは、「ATPS」と「atpsh」と呼ばれる追加のタグを追加します。
When the ATPS Signer generates a DKIM signature for another ADMD, it MUST put its own domain in the signature's "d" tag, and include an "atps" tag that has as its value the domain name of the ADMD on whose behalf it is signing.
ATPS署名者は、別のADMDのためにDKIM署名を生成するときに、署名者の「D」タグに独自のドメインを入れて、それが署名され、その代わりに、その値としてADMDのドメイン名を持っている「ATPS」タグを含まなければなりません。
The tag name that carries the name of the selected hash algorithm is "atpsh". This tag MUST also be included, as it is required as part of the algorithm that will be enacted by the Verifier.
選択されたハッシュアルゴリズムの名前を運ぶタグ名は「atpsh」です。これを検証することによって制定されるアルゴリズムの一部として必要とされるように、このタグはまた、含まなければなりません。
The formal syntax definition, per [ABNF], is as follows:
次のように正式な構文の定義は、[ABNF]ごとに、次のとおりです。
dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name
DKIM-ATPSタグ=％x61.74.70.73 * WSP "=" * WSPドメイン名
dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP ( "none" / key-h-tag-alg )
DKIM-atpshタグ=％のx61.74.70.73.68 * WSP "=" * WSP（ "なし" /キー-H-タグALG）
"domain-name" and "key-h-tag-alg" are defined in [DKIM]. Note that according to [DKIM], internationalized domain names are to be encoded as A-labels, as described in Section 2.3 of [IDNA].
"ドメイン名" と "鍵-H-タグ-ALGは" [DKIM]で定義されています。 [DKIM]によれば、国際化ドメイン名は[IDNA]のセクション2.3に記載されているように、-ラベルとして符号化されるべきであることに留意されたいです。
The registration for these tags can be found in Section 8.
これらのタグの登録は、セクション8に記載されています。
When a [DKIM] signature including an "atps" tag is successfully verified, and is considered acceptable to the Verifier according to any local policy requirements (which are not discussed here or in [DKIM]), the Verifier compares the domain name in the value of that tag with the one found in the RFC5322.From field of the message. The match MUST be done in a case-insensitive manner.
「ATPS」タグを含む[DKIM]署名が正常に検証され、そして（ここまたは[DKIM]で議論されていない）、任意のローカルポリシーの要件に応じて検証者に許容可能であると考えられる場合、検証者は、ドメイン名を比較しますメッセージのRFC5322.Fromフィールドで見つかったもので、そのタグの値。一致は大文字と小文字を区別しない方法で行われなければなりません。
If they do not match, the "atps" tag MUST be ignored.
両者が一致しない場合は、「ATPS」タグを無視しなければなりません。
If they do match, the Verifier issues a DNS TXT query, as specified below, looking for confirmation by the Author ADMD that the ATPS Signer is authorized by that ADMD to sign mail on its behalf. Where multiple DKIM signatures including valid "atps" tags are present, these queries MAY be done in any order or MAY be done in parallel.
彼らは試合を行うとATPS署名者は、その代わりにメールに署名することADMDによって承認されていることを著者ADMDによる確認を探して、以下のように指定、Verifierは、DNSのTXTクエリを発行します。有効な「ATPS」タグを含む複数のDKIM署名が存在する場合、これらのクエリは、任意の順序で実行されても、並列的に行うことができます。
Where the RFC5322.From field contains multiple addresses, this process SHOULD be applied if the "atps" tag's value matches any of the domains found in that field. These MAY be done in any order.
RFC5322.Fromフィールドは、複数のアドレスが含まれている場合は、このプロセスは「ATPS」タグの値は、そのフィールドで見つかったドメインのいずれかと一致した場合に適用されるべきです。これらは任意の順序で行うことができます。
Note that the algorithm uses hashing, but this is not a security mechanism. See Section 9.2 for discussion.
このアルゴリズムは、ハッシュを使用していますが、これはセキュリティ・メカニズムではないことに注意してください。議論のためのセクション9.2を参照してください。
The name for the query is constructed as follows:
次のようにクエリの名前が構築されています。
1. Select the hash algorithm from the "atpsh" tag in the signature. If the hash algorithm specified does not appear in the list registered with IANA as one valid for use with DKIM (see Section 7.7 of [DKIM]), and is not the reserved name "none" as described above, abort the query.
1.署名で「atpsh」タグからハッシュアルゴリズムを選択します。指定されたハッシュアルゴリズムは、DKIMで使用するための有効な1としてIANAに登録されているリストに表示されない場合（7.7節の[DKIM]を参照）、および予約名「なし」前述したように、クエリを中断しません。
3. Convert any uppercase characters in that string to their lowercase equivalents.
3.その文字列内のすべての大文字は小文字その同等物に変換します。
4. If the selected hash algorithm is not "none", apply the following additional steps:
4.選択されたハッシュアルゴリズムは、次の追加手順を適用し、「なし」でない場合：
A. Feed the resulting string to the selected hash algorithm.
A.は、選択されたハッシュアルゴリズムの結果の文字列をフィード。
B. Convert the output of the hash to a string of printable ASCII characters by applying base32 encoding as defined in Section 6 of [BASE32]. The base32 encoding is used because its output is restricted to characters that are legal for use in labels in the DNS, and it is evaluated the same way in the DNS whether encoded using uppercase or lowercase characters.
B. [BASE32]のセクション6で定義されるようにbase32エンコーディングを適用することにより、印刷可能なASCII文字の文字列に、ハッシュの出力を変換します。その出力はDNSのラベルで使用するための法的な文字に制限されているため、base32エンコードが使用され、そしてそれは、大文字と小文字を使用してエンコードするかどうかをDNSで同じように評価されます。
6. Append the domain name found in the "atps" tag of the validated signature.
6.検証署名の「ATPS」タグで見つかったドメイン名を追加します。
The query's formal syntax definition, per [ABNF], is as follows:
次のようにクエリの正式な構文定義は、[ABNF]ごとに、次のとおりです。
atps-query = ( 1*63BASE32 / domain-name ) %x2e.5f.61.74.70.73.2e domain-name
ATPSクエリ=（1 * 63BASE32 /ドメイン名）％のx2e.5f.61.74.70.73.2eドメイン名
BASE32 = ( ALPHA / %x32-37 )
BASE32 =（ALPHA /％x32-37）
The width limit of 63 on the base32 encoding is based on the maximum label limit as defined in Section 2.3.4 of [DNS].
[DNS]のセクション2.3.4で定義されるようにbase32エンコードに63の幅の上限は、最大ラベル制限に基づいています。
See Appendix A for an example of a query construction.
クエリの構成の例については、付録Aを参照してください。
In the descriptions below, the label NOERROR symbolizes DNS response code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 of [DNS] for further details.
以下の説明では、ラベルNOERRORは、DNS応答コード（「RCODE」）0を象徴し、NXDOMAINは、詳細については[DNS]のRCODE 3参照セクション4.1.1を表します。
At this time, only three possibilities need to be identified in this specification:
この時点では、唯一の3つの可能性は、本明細書で識別される必要があります。
o An answer is returned (i.e., [DNS] reply code NOERROR with at least one answer) containing a valid ATPS reply. In this case, the protocol has been satisfied and the Verifier can conclude that the signing domain is authorized by the ADMD to sign its mail. Further queries SHOULD NOT be initiated.
O答えが有効ATPS応答を含む（少なくとも1つの答えで、すなわち、[DNS]応答コードNOERROR）に戻されます。この場合、プロトコルが満たされていると検証は、署名ドメインは、そのメールに署名するADMDによって承認されていることを結論付けることができます。また、クエリが開始されるべきではありません。
o No answer is returned (i.e., [DNS] reply code NXDOMAIN, or NOERROR with no answers), or one or more answers have been returned as described above but none contain a valid ATPS reply. In this case, the Signer has not been authorized to act as a third-party Signer for this ADMD, and thus the Verifier MUST continue to the next query, if any.
O無回答が返されない（すなわち、[DNS]は応答コードNXDOMAIN、またはNOERRORない答え）上記のように、または1つ以上の回答が返されてきたが、どれも有効なATPS応答を含みません。この場合、署名者は、このADMDのためのサードパーティの署名者として行動する権限を与えられていない、とあればこれVerifierは、次のクエリし続けなければなりません。
o An error is returned (i.e., any other [DNS] reply code). It is no longer possible to determine whether or not this message satisfies the ADMD's list of authorized third-party Signers. The Verifier SHOULD stop processing and defer the message for later processing, such as requesting a temporary failure code from the Mail Transfer Agent (MTA).
Oエラー（すなわち、他の[DNS]応答コード）が戻されます。このメッセージは、許可のサードパーティの署名者のADMDのリストを満たしているか否かを決定することはできなくなりました。検証は、メール転送エージェント（MTA）から一時的な故障コードを要求するように、後の処理のためにメッセージを処理を停止し、延期すべきです。
If all queries are completed and return either NXDOMAIN or NOERROR with no answers, then the Signer was not authorized by the ADMD.
すべてのクエリが完了していない答えをNXDOMAINまたはNOERRORのいずれかを返している場合は、署名者は、ADMDによって許可されませんでした。
A valid ATPS reply consists of a sequence of tag=value pairs as described in Section 3.2 of [DKIM]. The following tags and values are currently supported in ATPS records:
[DKIM]のセクション3.2に記載されているように、有効なATPS応答がタグと値のペアの配列からなります。次のタグと値は、現在ATPSレコードにサポートされています。
d: Domain (plain-text; RECOMMENDED). This tag includes a plain-text copy of the DNS domain being authorized as an ATPS Signer. This is included to assist with collision detections; for example, if the base32 encoding of this name is not the same as the base32 portion of the query, or more simply if this name is not the same as that found in the "atps" tag, a hash collision could have occurred. Its use where no name hashing has occurred is redundant. The ABNF is as follows:
D：ドメイン（平文;推奨）。このタグは、ATPS署名者として認定されているDNSドメインのプレーンテキストのコピーを含んでいます。これは、衝突判定を支援するために含まれています。例えば、この名前のbase32エンコードは、クエリのbase32部分と同じではない場合、またはより単純に、この名前は「ATPS」タグで見つかったものと同じでない場合は、ハッシュ衝突が発生することがありました。何名のハッシュが発生していないその使用は冗長です。次のようにABNFは以下のとおりです。
atps-d-tag = %x64 [FWS] "=" [FWS] domain-name ; FWS is defined in [DKIM]
=％x64の[FWS] "=" [FWS]ドメイン名ATPS-D-タグ。 FWSは、[DKIM]で定義されています
v: Version (plain-text; REQUIRED). This tag indicates the version of the ATPS specification to which the record complies. The record MUST be ignored if the value is not "ATPS1". The ABNF is as follows:
V：バージョン（平文;必須）。このタグは、レコードが準拠するATPS仕様のバージョンを示します。値が「ATPS1」でない場合、レコードは無視しなければなりません。次のようにABNFは以下のとおりです。
atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 ; FWS is defined in [DKIM]
ATPS-V-タグ=％のX76 [FWS] "=" [FWS]％のx41.54.50.53.31。 FWSは、[DKIM]で定義されています
For each DKIM signature that verifies (see Section 6 of [DKIM]), if a Verifier succeeds in confirming that the Author's ADMD authorized the ATPS Signer using this protocol, then the Verifier SHOULD evaluate the message as though it contained a valid signature from the Author's ADMD. It MAY also independently evaluate the ATPS Signer when determining message disposition.
それから、有効な署名を含んでいたかのように検証者がこのプロトコルを使用して、著者のADMDは、ATPS署名者を承認したことを確認に成功したかどうかを検証各DKIM署名は、（[DKIM]のセクション6を参照）、次に検証は、メッセージを評価しなければなりません著者のADMD。メッセージの処分を決定する場合にも独立してATPSの署名者を評価することができます。
This assertion is based on the fact that the ADMD explicitly endorsed the ATPS Signer. Therefore, a module assessing reputation that is based on DKIM signature verification SHOULD apply the reputation of the Author's ADMD domain instead of, or in addition to, that of the ATPS Signer domain.
この主張は、ADMDが明示的にATPS署名者を支持しているという事実に基づいています。したがって、DKIM署名検証に基づいてモジュールの評価評判の代わりに、またはそれに加えて著者のADMDドメイン、ATPS署名者のドメインのことの評判を適用する必要があります。
[ADSP] defined a protocol by which the owner of an Author Domain can advertise a request to message receivers that messages bearing no valid author signature be treated with suspicion or even discarded.
【ADSPは】者の所有者は、ドメインが有効な作成者の署名を担持しないメッセージは、疑いで処理あるいは廃棄されるメッセージレシーバに要求を広告することが可能なプロトコルを定義しました。
A Verifier implementing both Author Domain Signing Practices (ADSP) and ATPS MUST test ATPS first. If ATPS indicates a valid delegation, the Verifier MUST act, with respect to ADSP, as though the message has a valid Author Domain Signature (because that's what the delegation means), and no ADSP test is required.
著者ドメイン署名プラクティス（ADSP）とATPSの両方を実装Verifierは、最初のATPSをテストする必要があります。 ATPSは有効な委任を示している場合（つまり、代表団が何を意味するのかだから）、そして何ADSPテストが必要とされないメッセージが有効な著者ドメイン署名を持っているかのように、Verifierは、ADSPに関して、行動しなければなりません。
The working group that developed DKIM considered a third-party mechanism such as this one to be controversial, in terms of need and practicality, and decided that an alternative mechanism was sufficient. However, this was not based on actual experience, as there is no specific history on this question. Thus, this experiment was devised.
DKIMを開発ワーキンググループは、このいずれかのようなサードパーティの機構が必要と実用性の観点から、論争であると考えられ、そして代替のメカニズムが十分であったことを決定しました。この質問には具体的な歴史がないのでしかし、これは、実際の経験に基づいていませんでした。したがって、この実験を考案しました。
The experimental protocol described here has been implemented as an extension to DKIM in two software products, one of which is open source and seeing increasingly wide use. It is included there to allow customers of those systems to make use of it if they believe such third-party assertions are useful to the overall DKIM mechanism. Further adoption as part of the experiment is welcome and encouraged.
ここに記載の実験プロトコールは、オープンソースますます広い用途を見ているそのうちの一つ、2つのソフトウェア製品でDKIMの拡張機能として実装されています。彼らがそのようなサードパーティのアサーションは、全体的なDKIMメカニズムに役立つと考えている場合は、それらのシステムの顧客はそれを利用することができるようにそこに含まれています。実験の一環として、さらなる採用が歓迎し、奨励しています。
Use of the protocol and anecdotes of how it affects the overall DKIM experience will be collected by those implementers and the author of this memo. Those participating in the experiment are also advised to observe and report the impact of what is discussed in Section 9.4, especially with respect to MTA latency that may be introduced.
それは、全体的なDKIMの経験をどのように影響するかのプロトコルや逸話の使用は、それらの実装とこのメモの作者によって収集されます。実験に参加したものは、特に導入してもよいMTAの待ち時間に関して、9.4節で議論されているものの影響を観察し、報告することをお勧めします。
If the response is substantial and positive, advancement along the Standards Track might be warranted.
応答が実質的かつ肯定的である場合には、標準化過程に沿って進行が保証されることがあります。
This section enumerates requested IANA actions.
このセクションでは、要求されたIANAのアクションを列挙します。
IANA has created an Authorized Third-Party Signature (ATPS) Tag Registry, under the DomainKeys Identified Mail (DKIM) Parameters group, to enumerate the tags that are valid for use in ATPS records.
IANAは、ドメインキー・アイデンティファイド・メールは（DKIM）グループのパラメータの下で、ATPSレコードで使用するための有効なタグを列挙するために、承認されたサードパーティの署名（ATPS）タグのレジストリを作成しました。
New registrations or updates MUST be made in accordance with the "Specification Required" guidelines described in [IANA]. Such registry changes MUST contain the following information:
新規登録や更新は、[IANA]に記載されている「仕様が必要」ガイドラインに従って行われなければなりません。このようなレジストリの変更は、次の情報が含まれている必要があります
3. The status of the tag, one of "active" (tag is in current use), "deprecated" (tag is in current use but its use is discouraged), or "historic" (tag is no longer in use)
3.タグのステータス、（タグが現在使用されている）、「歴史」（タグが現在使用中であるが、その使用は推奨されている）、「非推奨」、または「アクティブ」のいずれかが（タグは、もはや使用されていません）
The registry's initial entries are below:
レジストリの初期エントリは以下のとおりです。
+-----+------------+--------+
| Tag | Reference | Status |
+-----+------------+--------+
| d | [RFC6541] | active |
+-----+------------+--------+
| v | [RFC6541] | active |
+-----+------------+--------+
The following has been added to the Email Authentication Methods registry (in the Email Authentication Parameters group) established by [AUTHRES] as per [IANA]:
[AUTHRES] [IANA]ごとなどによって確立された（メール認証パラメータグループに）メール認証方法レジストリに追加されました次：
Method: dkim-atps
方法：DKIM-ATP
Defined In: [RFC6541]
で定義される：[RFC6541]
ptype: header
p型：ヘッダ
property: from
プロパティ：から
value: contents of the [MAIL] From: header field, with comments removed
値：除去コメントをヘッダフィールド、：から[MAIL]の内容
The following have been added to the Email Authentication Result Names registry (in the Email Authentication Parameters group) established by [AUTHRES] as per [IANA]:
以下は、[IANA]ごとに[AUTHRES]によって確立された（メール認証パラメータグループ内）メールの認証結果名レジストリに追加されました
Code: none
コード：なし
Existing/New Code: existing
既存/新コード：既存の
Defined In: [AUTHRES]
で定義される：[AUTHRES]
Auth Method: dkim-atps
認証方法：DKIM-ATPS
Meaning: No valid DKIM signatures were found on the message bearing "atps" tags.
意味：なし有効なDKIM署名が「ATPS」タグをもつメッセージに見つかりませんでした。
Code: pass
コード：パス
Existing/New Code: existing
既存/新コード：既存の
Defined In: [AUTHRES]
で定義される：[AUTHRES]
Auth Method: dkim-atps
認証方法：DKIM-ATPS
Meaning: An ATPS evaluation was performed, and a valid signature from an authorized third party was found on the message.
意味：ATPS評価を行い、許可済みの第三者からの有効な署名がメッセージに発見されました。
Code: fail
コード：失敗
Existing/New Code: existing
既存/新コード：既存の
Defined In: [AUTHRES]
で定義される：[AUTHRES]
Auth Method: dkim-atps
認証方法：DKIM-ATPS
Meaning: All valid DKIM signatures bearing an "atps" tag either did not reference a domain name found in the RFC5322.From field, or the ATPS test(s) performed failed to confirm a third-party authorization.
意味：「ATPS」タグを保有するすべての有効なDKIM署名がRFC5322.Fromフィールドで見つかったドメイン名を参照していないか、ATPSテスト（複数可）を実施することは、サードパーティの認証を確認することができませんでした。
Code: temperror
コード：temperror
Existing/New Code: existing
既存/新コード：既存の
Defined In: [AUTHRES]
で定義される：[AUTHRES]
Auth Method: dkim-atps
認証方法：DKIM-ATPS
Meaning: An ATPS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error. A later attempt might produce a final result.
意味：ATPS評価は、このような一時的なDNSエラーなど自然の中でおそらく一過性であり、いくつかのエラーのため完了できませんでした。以降の試みは、最終的な結果を生じる可能性があります。
Code: permerror
コード：パーマエラー
Existing/New Code: existing
既存/新コード：既存の
Defined In: [AUTHRES]
で定義される：[AUTHRES]
Auth Method: dkim-atps
認証方法：DKIM-ATPS
Meaning: An ATPS evaluation could not be completed due to some error that is not likely transient in nature, such as a permanent DNS error. A later attempt is unlikely to produce a final result.
意味：ATPS評価は、そのような永続的なDNSエラーなど自然の中でおそらく一過性ではないいくつかのエラーのため完了できませんでした。以降の試みは、最終的な結果を生成することはほとんどありません。
The following have been added to the DKIM Signature Tag Specifications registry (in the DomainKeys Identified Mail (DKIM) Parameters group) established by [DKIM] as per [IANA]:
[DKIM]によって確立された（群ドメインキー・アイデンティファイド・メール（DKIM）のパラメータ）DKIM署名タグ仕様レジストリに追加された次の[IANA]の通り：
+-------+-----------+--------+
| Type | Reference | Status |
+-------+-----------+--------+
| atps | [RFC6541] | active |
+-------+-----------+--------+
| atpsh | [RFC6541] | active |
+-------+-----------+--------+
This section discusses potential security issues related to this experimental protocol.
このセクションでは、この実験プロトコルに関連する潜在的なセキュリティ問題について説明します。
The selection of the hash algorithm to be used (see Section 4.1) has security implications, as weaker algorithms have more risk of collision, meaning a second DNS domain name could in theory be constructed to appear to have been authorized by the Author ADMD.
弱いアルゴリズムは2番目のDNSドメイン名は、理論的には著者ADMDによって認可されているように見えるように構築することができ意味、衝突のより多くのリスクを持っているとして、使用するハッシュアルゴリズムの選択は（セクション4.1を参照）、セキュリティへの影響を持っています。
At the time of publication of [DKIM], use of SHA256 was preferred over SHA1 for this reason, though support for both has been maintained. See Section 3.3 of [DKIM] for additional discussion.
両方のサポートが維持されているが[DKIM]の発行時に、SHA256の使用は、この理由のためにSHA1より好まれました。追加の議論については[DKIM]の3.3節を参照してください。
The fact that the authorized third-party domain name is hashed and then encoded with base32 might give some the false sense that the relationship between the two parties is somehow protected. This is not the case. Indeed, the very purpose of this protocol is to make it possible for such relationships to be discovered, so such an obscuration would make that process more difficult without a shared secret delivered out-of-band to message verifiers (which also adds further complexity). Rather, the hash and encode steps are done merely to convert any third-party domain name to a fixed width in the construction of the DNS query.
許可サードパーティのドメイン名がハッシュされ、その後、いくつかの二者間の関係が何らかの形で保護されていることを誤った安心感を与えるかもしれないbase32でエンコードされているという事実。これはそうではありません。確かに、このプロトコルの非常に目的は、このような不明瞭は（もさらに複雑に）メッセージの検証に帯域外配信、共有秘密ことなく、そのプロセスはより困難になるだろうので、それが可能な関係を発見することできるようにすることです。むしろ、ハッシュおよびエンコードステップは、DNSクエリーの構築に一定の幅にサードパーティのドメイン名を変換するためだけに行われます。
Approving a third-party Signer exposes the ADMD to the risk that the third-party Signer becomes compromised and then begins to sign malicious or nuisance messages on behalf of the ADMD. This can obviously reflect negatively on the ADMD, and the impact of this can become more severe as automated domain reputation systems are developed and deployed. Thorough vetting and monitoring practices by ADMDs of third-party Signers will likely need to become the norm.
サードパーティの署名者を承認することは、サードパーティの署名者が侵害されるリスクへのADMDを公開して、ADMDの代わりに悪意のあるまたは迷惑メッセージに署名を開始します。これは明らかにADMDに否定的に反映することができ、かつ自動化されたドメインのレピュテーションシステムが開発され、配備されているとして、これの影響はより深刻になることができます。サードパーティの署名者のADMDsによって徹底的に審査及びモニタリング方法は、おそらく標準になるために必要になります。
A Verifier participating in DKIM, ADSP, and ATPS will now issue a number of TXT queries to the DNS equal to as many as one (for the ADSP query) plus the number of signatures on the message (one for each key that is to be verified) plus the number of signatures that validated and that also bear an "atps" tag. This is in addition to any PTR and A queries the MTA might issue at the time the actual message relaying or delivery is initiated. Obviously, this can be burdensome on the DNS at both ends, and waiting for that number of queries to return when they are issued in parallel could trigger timeouts in the MTA.
DKIMに参加Verifierは、ADSP、およびATPSは現在DNSにTXTクエリーの数を発行するなどの多くの一つとして（ADSPクエリに対する）に等しいプラスメッセージ（される各キーに対して1つの署名の数検証済み）に加えて検証し、それはまた、「ATPS」タグを負担署名の数。これは、任意のPTRに加えて、AはMTAが実際のメッセージ中継または配信が開始された時点で発行するかもしれません照会します。明らかに、これは両端にDNS上の負担とすることができ、それらは並列に発行されたときに返すために、クエリの数を待っていると、MTAにタイムアウトを引き起こす可能性があります。
An alternative that has not yet been explored is the storage of the ATPS data at a specific URL tied to the Author's domain name. This would alleviate pressure on the DNS at the expense of requiring the ADMD to operate a web server (which has its own security implications) and the addition of the establishment of a TCP connection. Moreover, the Verifier would be well advised to implement caching of this data to prevent ATPS from being used as a denial-of-service vector.
まだ探求されていない代替が著者のドメイン名に関連付けられ、特定のURLでATPSデータのストレージです。これは、（独自のセキュリティ意味を持っている）、WebサーバとTCPコネクションの確立の追加を動作させるためにADMDを必要とする費用でDNSへの圧力を軽減するでしょう。また、検証がうまくサービス拒否ベクターとして使用されるのATPSを防止するために、このデータのキャッシュを実装することが推奨されます。
See Section 8.5 of [DKIM] for further discussion of DNS-related issues.
DNS関連の問題のさらなる議論のための[DKIM]のセクション8.5を参照してください。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、エド、およびP. Overell、。。
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
、RFC 5451、2009年4月 "メッセージ認証ステータスを示すためのメッセージヘッダフィールド" [AUTHRES] Kucherawy、M.、。
[BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE32] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]クロッカー、D.、編、ハンセン、T.編、及びM. Kucherawy、エド。、 "ドメインキー・アイデンティファイド・メール（DKIM）署名"、RFC 6376、2011年9月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[MAIL]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
【ADSP】オールマン、E.、フェントン、J.、デラニー、M.、およびJ.レヴァイン、 "ドメインキー・アイデンティファイド・メール（DKIM）著ドメイン署名プラクティス（ADSP）"、RFC 5617、2009年8月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[IDNA] "アプリケーションのための国際化ドメイン名（IDNA）：定義とドキュメントのフレームワーク" Klensin、J.、RFC 5890、2010年8月。
Appendix A. Example Query and Reply
付録A.クエリ例と返信
This section presents an example of the use of this protocol to query for a third-party authorization and discusses the interpretation of the result.
このセクションでは、サードパーティの認証を照会するには、このプロトコルの使用例を提示し、結果の解釈について説明します。
Presume a message for which the RFC5322.From domain is "example.com", and it bears two valid signatures, from "one.example.net" and from "two.example.net", each with an "atps" tag whose value is "example.com", and an "atpsh" tag whose value is "sha1". The following actions are taken:
RFC5322.Fromドメインが「example.com」であるため、メッセージを推定し、それは、その「ATPS」タグで「one.example.net」から、2人の有効な署名を担持し、「two.example.net」、それぞれから値が「example.com」であり、その値が「atpsh」タグ「SHA1」です。以下のアクションがとられています。
1. A SHA1 hash of "one.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6".
「one.example.net」の1. A SHA1ハッシュを計算し、次に文字列「QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6」で得られた、base32エンコーディングを使用して印刷可能な形式に変換されます。
2. A TXT query is issued to "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com".
2. A TXTクエリは "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com" に対して発行されます。
3. If a valid reply arrives, the algorithm stops with [AUTHRES] result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate.
3.有効な応答が到着した場合、アルゴリズムは[AUTHRES】その結果、「合格」で停止します。 NXDOMAIN以外のDNSエラーコードが返された場合、アルゴリズムは「temperror」又は適宜「PermErrorという」の結果で停止します。
4. A SHA1 hash of "two.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX".
「two.example.net」の4 A SHA1ハッシュを計算し、次に文字列「ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX」で得られた、base32エンコーディングを使用して印刷可能な形式に変換されます。
5. A TXT query is issued to "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com".
5. A TXTクエリは "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com" に対して発行されます。
6. If a valid reply arrives, the algorithm stops with [AUTHRES] result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate.
6.有効な応答が到着した場合、アルゴリズムは[AUTHRES】その結果、「合格」で停止します。 NXDOMAIN以外のDNSエラーコードが返された場合、アルゴリズムは「temperror」又は適宜「PermErrorという」の結果で停止します。
7. As there are no valid signatures left to test, the algorithm stops with an "unknown" result.
テストするために残された有効な署名がないと7は、アルゴリズムが「不明」の結果を停止します。
Appendix B. Choice of DNS RR Type
DNSのRRタイプの付録B.選択
It was proposed that this work appear within the DNS under a new Resource Record (RR) Type. Although this is possibly an appropriate thing to do, consideration was also given to the fact that major portions of DKIM already use an ASCII-based "tag=value" syntax, and store key and ADSP data in the DNS using TXT resource records. To enable re-use of existing DKIM code, it was decided to re-use the TXT message scheme.
それは、この作品は新しいリソースレコード（RR）タイプの下にDNS内に表示されることが提案されました。これはおそらく行うには適切なものではあるが、検討もDKIMの主要な部分はすでにTXTリソースレコードを使用してDNSにASCIIベースの「タグ=値」の構文、および店舗のキーとADSPデータを使用しているという事実に与えられました。既存のDKIMコードの再利用を可能にするために、それはTXTメッセージスキームを再使用することを決めました。
Appendix C. Acknowledgements
付録C.謝辞
The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark Martinec, and Phil Pennock for their review and constructive criticism of this proposal.
作者は彼らのレビューとこの提案の建設的な批判のためのデイブクロッカー、フランクEllermann、マーク・Martinec、フィル・ペノックを確認したいです。
The author also wishes to acknowledge Doug Otis and Daniel Black for their original document, upon which this work was based.
著者はまた、この作品がベースになった、元の文書のためのダグ・オーティスとダニエルブラックを確認したいです。
Author's Address
著者のアドレス
Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 US
マレーS. Kucherawyクラウドマーク社128キングセント、2階サンフランシスコ、CA 94107米国
Phone: +1 415 946 3800 EMail: msk@cloudmark.com
電話：+1 415 946 3800 Eメール：msk@cloudmark.com