[要約] RFC 6541は、DKIMの認証済み第三者署名に関するガイドラインです。目的は、DKIMの認証プロセスを改善し、信頼性とセキュリティを向上させることです。
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
DomainKeysは、郵便物（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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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ドメインとメッセージにある他の身元との間に意図的に拘束力を与えません。それにもかかわらず、著者ドメインの署名（RFC5322が署名者のDNSドメインと一致するrfc5322が1つ）が他のどのドメインよりも価値があるか信頼できるという自動人間の認識があります。
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
第三者がメッセージにDKIM署名を適用できるようにするために、DKIM仕様は、サブドメインまたはプライベートキーの第三者への委任を提案し、第三者が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によって追加されたと思われる署名。不在は、著者のADMDが、他のADMDが追加された特定の有効なDKIM署名を含むメッセージを担当するメッセージを、著者ADMD自体によって署名されたかのように扱われることを発表できるプロトコルです。このメモは、承認されたサードパーティの署名（ATP）と呼ばれる、そうするための実験メカニズムを提示します。
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は、検証剤に1つではなく複数の識別子に提供することにより、DKIMのセマンティクスを増強します。具体的には、DKIM署名で見つかった識別子を検証し、評価のためにドメインからrfc5322.を提供します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されているように解釈されます。
Readers are advised to be familiar with the material and terminology discussed in [MAIL] and [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;
o [Mail]メッセージのフィールドからDNSドメイン名に表示される管理管理ドメイン（ADMDS）。
o ATPS Signers, which apply [DKIM] signatures using their own domains, but on behalf of the message Author's ADMD; and
o ATPS署名者は、[DKIM]独自のドメインを使用して署名を適用しますが、メッセージ作成者のADMDを代表して。と
o the Verifier, who implements the signature validation procedures described in [DKIM].
o [DKIM]で説明されている署名検証手順を実装する検証剤。
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
ADMDは、指定されたDNSドメインのセット内の署名がADMD自体の署名と同等であると見なされることを発表したい場合、このプロトコルを実装します。たとえば、ADMDは、[DKIM]の付録B.1.1に記載されている重要な転送の作業を行わずに、DNSドメインの署名機関に承認されたメッセージングサービスプロバイダーに委任することを望むかもしれません。認定されたATP
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.
Verifierは、メッセージが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レコードの存在を介して、その郵便に署名する第三者の承認を示します。そうするための2つのサポートされている方法があります。1つは、第三者のDNSドメイン名の単純なコピーを含む方法と、名前のエンコードされたバージョンを含むものです。エンコーディングメカニズムが提供され、任意のドメイン名を固定長で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ドメイン名のダイジェストを構築する必要があります。著者ADMDは、DKIMによって現在サポートされているダイジェスト（「ハッシュ」）メソッド（[DKIM]のセクション7.7を参照）を選択する必要があります。署名。
Where the encoding mechanism is not used, the ATPS Signer MUST use a hash name of "none".
エンコーディングメカニズムが使用されていない場合、ATPS署名者は「none」のハッシュ名を使用する必要があります。
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]署名には「tag = value」シーケンスが含まれています。このプロトコルは、「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-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP
( "none" / key-h-tag-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].
「ドメイン名」と「key-h-tag-alg」は[dkim]で定義されています。[DKIM]によれば、[IDNA]のセクション2.3で説明されているように、国際化されたドメイン名はAラベルとしてエンコードされることに注意してください。
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.から見つかったものです。試合は、ケースに依存しない方法で行う必要があります。
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.
それらが一致する場合、Verifierは以下に指定されているように、DNS TXTクエリを発行します。著者のADMDによる確認を探して、ATPS署名者はそのADMDがそのADMDに代わって署名することを許可されています。有効な「ATP」タグを含む複数の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.フィールドに複数のアドレスが含まれている場合、「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」タグからハッシュアルゴリズムを選択します。指定されたハッシュアルゴリズムがIANAに登録されているリストにDKIMでの使用に有効なものとして表示されない場合（[DKIM]のセクション7.7を参照）、上記のように予約済みの名前「なし」ではありません。クエリを中止します。
2. Extract the value of the "d=" tag from the signature.
2. 署名から「d =」タグの値を抽出します。
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文字の文字列に変換します。Base32エンコーディングは、その出力がDNSのラベルで使用するために合法的な文字に制限されているため使用され、DNSでは大文字または小文字の文字を使用してエンコードされているかどうかと同じ方法で評価されます。
5. Append the string "._atps."
5. 文字列「._ATPS」を追加します。
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
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].
base32エンコードの幅63の幅制限は、[DNS]のセクション2.3.4で定義されている最大ラベル制限に基づいています。
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はRcode 3を表します。詳細については、[DNS]のセクション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 有効なATPの返信を含む回答が返されます（つまり、少なくとも1つの回答を伴う[DNS] Reply Code 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つ以上の回答が返されましたが、有効なATPの返信はありません。この場合、署名者はこのADMDのサードパーティの署名者として行動することを許可されていないため、検証者は次のクエリまで継続する必要があります。
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のリストを満たしているかどうかを判断することはもはや不可能です。Verifierは、メール転送エージェント（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:
有効なATPの応答は、[DKIM]のセクション3.2で説明されているように、タグ=値ペアのシーケンスで構成されています。現在、次のタグと値は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]
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]
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.
検証する各DKIM署名について（[DKIM]のセクション6を参照））、検証者が著者のADMDがこのプロトコルを使用してATPS署名者を許可したことを確認することに成功した場合、検証者はメッセージを評価する必要があります。著者の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の署名検証に基づいた評判を評価するモジュールは、ATPS署名者ドメインの代わりに、またはそれに加えて著者のADMDドメインの評判を適用する必要があります。
[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）とATPの両方を実装する検証剤は、最初にATPをテストする必要があります。ATPが有効な代表団を示している場合、メッセージに有効な著者ドメイン署名があるかのようにADSPに関して、検証剤が行動する必要があり（それが代表団の意味であるため）、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の拡張として実装されており、そのうちの1つはオープンソースであり、ますます幅広く使用されています。これらのシステムの顧客が、そのようなサードパーティの主張が全体的な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は、ATPSレコードでの使用に有効なタグを列挙するために、ドメインキー識別されたメール（DKIM）パラメーターグループの下に、承認されたサードパーティ署名（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]に記載されている「必要な仕様」ガイドラインに従って、新しい登録または更新を行う必要があります。このようなレジストリの変更には、次の情報が含まれている必要があります。
1. Name of the tag being registered or updated
1. 登録または更新されるタグの名前
2. The document where the specification is created or updated
2. 仕様が作成または更新されるドキュメント
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]:
[IANA]に従って[authres]によって確立された電子メール認証方法レジストリ（電子メール認証パラメータグループ）に以下が追加されました。
Method: dkim-atps
方法：DKIM-ATPS
Defined In: [RFC6541]
定義済み：[RFC6541]
ptype: header
PTYPE：ヘッダー
property: from
プロパティ：から
value: contents of the [MAIL] From: header field, with comments removed
値：[メール]の内容：ヘッダーフィールド、コメントが削除された
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.
意味：「ATPS」タグを示すメッセージに有効なDKIM署名は見つかりませんでした。
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
コード：気性
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.
意味：一時的なDNSエラーなど、本質的に一時的なエラーがあるため、ATPS評価は完了できませんでした。その後の試みは最終結果を生み出すかもしれません。
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.
意味：永続的なDNSエラーなど、本質的に一時的ではない可能性が高いエラーのために、ATPS評価を完了できませんでした。後の試みが最終結果を生み出す可能性は低いです。
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]:
[IANA]に従って[DKIM]によって確立されたDKIM署名タグ仕様レジストリ（DomainKeys Idified Mail（DKIM）パラメーターグループ）に以下が追加されました。
+-------+-----------+--------+
| 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.
使用するハッシュアルゴリズムの選択（セクション4.1を参照）にはセキュリティの意味があります。弱いアルゴリズムには衝突のリスクが高く、2番目のDNSドメイン名が著者ADMDによって許可されているように見えるように構築される可能性があります。
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に否定的に反映される可能性があり、自動ドメインの評判システムが開発され展開されるにつれて、この影響はより深刻になる可能性があります。サードパーティの署名者のADMDによる徹底的な審査および監視慣行は、おそらく標準になる必要があるでしょう。
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、ADSP、およびATPに参加している検証剤は、DNSに1つ（ADSPクエリ用）に等しいDNSに多数のTXTクエリを発行し、メッセージの署名の数（1つは各キーに検証済み）さらに、検証され、「ATPS」タグも付いている署名の数。これは、PTRとa任意のPTRとクエリに加えて、実際のメッセージが中継または配信が開始されたときに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データのストレージです。これにより、ADMDがWebサーバー（独自のセキュリティに影響を与える）とTCP接続の確立の追加を要求することを犠牲にして、DNSへの圧力が軽減されます。さらに、検証者は、ATPがサービス拒否ベクターとして使用されるのを防ぐために、このデータのキャッシュを実装することをお勧めします。
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.
[ABNF] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[Authres] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 5451、2009年4月。
[BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[Base32] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、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] Crocker、D.、ed。、Hansen、T.、ed。、およびM. Kucherawy、ed。、「Domainkeys Idefied Mail（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.
[メールアーチ] Crocker、D。、「Internet Mail Architecture」、RFC 5598、2009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P.、ed。、「インターネットメッセージ形式」、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] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「Domainkeys Idified Mail（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] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
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.から「embles.com」であるメッセージを推測します。「one.example.net」と「two.example.net」から、それぞれが「atps」タグを持つ「two.example.net」から2つの有効な署名が付いています。値は「embles.com」であり、値が「sha1」である「atpsh」タグです。次のアクションが実行されます。
1. A SHA1 hash of "one.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6".
1. 「One.example.net」のSHA1ハッシュが計算され、Base32エンコードを使用して印刷可能なフォームに変換され、文字列「QSP4I4D24D24CRHOPDZ3O3ZIU2KSGS3X6Z6」」になります。
2. A TXT query is issued to "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com".
2. TXTクエリは、「QSP4I4D24D24CRHOPDZ3O3ZIU2KSGS3X6Z6._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エラーコードが返される場合、必要に応じて「気性」または「パーマ」の結果でアルゴリズムが停止します。
4. A SHA1 hash of "two.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX".
4. 「2.example.net」のSha1ハッシュが計算され、Base32エンコードを使用して印刷可能な形式に変換され、文字列「ztzgrrv3f45a4u6hldkbf3zcow4v2ajx」になります。
5. A TXT query is issued to "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com".
5. 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エラーコードが返される場合、必要に応じて「気性」または「パーマ」の結果でアルゴリズムが停止します。
7. As there are no valid signatures left to test, the algorithm stops with an "unknown" result.
7. テストする有効な署名が残っていないため、アルゴリズムは「不明な」結果で停止します。
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の大部分がすでにASCIIベースの「TAG =値」構文を使用しており、TXTリソースレコードを使用してDNSにキーとADSPデータを保存しているという事実も考慮されました。既存のDKIMコードの再利用を有効にするために、TXTメッセージスキームを再利用することが決定されました。
The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark Martinec, and Phil Pennock for their review and constructive criticism of this proposal.
著者は、この提案に対する彼らのレビューと建設的な批判について、デイブ・クロッカー、フランク・エラーマン、マーク・マルティネック、フィル・ペノックに認めたいと考えています。
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
Murray S. Kuherawy Cloudmark、Inc。128 King St.、2階サンフランシスコ、カリフォルニア94107 US
Phone: +1 415 946 3800
EMail: msk@cloudmark.com