RFC4871 日本語訳
4871 DomainKeys Identified Mail (DKIM) Signatures. E. Allman, J.Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. May 2007. (Format: TXT=166054 bytes) (Obsoletes RFC4870) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. Delany
M. Libbey
Yahoo! Inc
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
コメントを求めるワーキンググループE.オールマン要求をネットワークでつないでください: 4871 センドメールInc.は以下を時代遅れにします。 4870年のJ.カラカテゴリ: 標準化過程PGP社のM.ディラニーM.リッベイYahoo!Inc J.フェントンM.トーマスシスコシステムズInc.2007年5月
DomainKeys Identified Mail (DKIM) Signatures
DomainKeysはメール(DKIM)署名を特定しました。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing".
DomainKeys Identifiedメール(DKIM)は、メールのために公開カギ暗号とメール配達エージェント(MTAs)かメール・ユーザー・エージェントのどちらか(MUAs)でソースの検証とメッセージのコンテンツを可能にする主要なサーバ技術を使用することでドメインレベル認証枠組みを定義します。 この枠組みの究極の目標は調印ドメインがメッセージへの責任について断言することを許可することです、その結果、彼らがそれが今日知られているようにインターネットメールの機能性を保有している間に伝えるメッセージのメッセージ署名者のアイデンティティと保全を保護します。 メールのアイデンティティの保護は「スパム」と「フィッシング詐欺」のグローバルなコントロールを助けるかもしれません。
Allman, et al. Standards Track [Page 1] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17
3.6. Key Management and Representation . . . . . . . . . . . . 25
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Normalize the Message to Prevent Transport Conversions . . 35
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Extract Signatures from the Message . . . . . . . . . . . 41
6.2. Communicate Verification Results . . . . . . . . . . . . . 46
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 アイデンティティ. . . . . . . . . . . . . . . . . . . . . 5 1.2にサインします。 スケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . 5 1.3。 簡単なKey Management. . . . . . . . . . . . . . . . . . 5 2。 用語と定義. . . . . . . . . . . . . . . . . 5 2.1。 署名者. . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2。 検証. . . . . . . . . . . . . . . . . . . . . . . . 6 2.3。 空白. . . . . . . . . . . . . . . . . . . . . . . . 6 2.4。 一般的なABNF象徴. . . . . . . . . . . . . . . . . . . . 6 2.5。 輸入されたABNF象徴. . . . . . . . . . . . . . . . . . . 7 2.6。 DKIMが引用した、印刷可能である、.7 3 要素. . . . . . . . . . . . . . . . . . . . . . 8 3.1について議定書の中で述べてください。 セレクタ. . . . . . . . . . . . . . . . . . . . . . . . 8 3.2。 =値リスト. . . . . . . . . . . . . . . . . . . . . 10 3.3にタグ付けをしてください。 調印と検証アルゴリズム. . . . . . . . . . . 11 3.4。 Canonicalization. . . . . . . . . . . . . . . . . . . . . 13 3.5。 DKIM-署名ヘッダーフィールド. . . . . . . . . . . . . 17 3.6。 Key Managementと表現. . . . . . . . . . . . 25 3.7。 メッセージを計算すると、.293.8は論じ尽くされます。 親ドメイン. . . . . . . . . . . . . . . . 31 4のそばでサインします。 複数の署名. . . . . . . . . . . . . . . 32 4.1の意味論 例のシナリオ. . . . . . . . . . . . . . . . . . . . 32 4.2。 解釈. . . . . . . . . . . . . . . . . . . . . . 33 5。 署名者動作. . . . . . . . . . . . . . . . . . . . . . . . 34 5.1。 メールがサインされるべきであってだれが.345.2を決定してくださいか。 秘密鍵と対応するセレクタ情報. . . . . . . . . . . . . . . . . . . . . . . 35 5.3を選択してください。 輸送変換. . 35 5.4を防ぐメッセージを正常にしてください。 サイン. . . . . . . . . . . 36 5.5へのヘッダーフィールドを決定してください。 お勧めの署名内容. . . . . . . . . . . . . . 38 5.6。 メッセージ細切れ肉料理と署名. . . . . . . . . . 39 5.7を計算してください。 DKIM-署名ヘッダーフィールド. . . . . . . . . . 40 6を挿入してください。 検証動作. . . . . . . . . . . . . . . . . . . . . . . 40 6.1。 メッセージ. . . . . . . . . . . 41 6.2から署名を抽出してください。 検証結果. . . . . . . . . . . . . 46 6.3を伝えてください。 /がローカルの方針. . . . . . . . . . . 47 7を適用するという結果を解釈してください。 IANA問題. . . . . . . . . . . . . . . . . . . . . 48 7.1。 DKIM-署名タグ仕様. . . . . . . . . . . . 48 7.2。 DKIM-署名質問方法登録. . . . . . . . . . . 49 7.3。 DKIM-署名Canonicalization登録. . . . . . . . . 49 7.4。 _domainkey DNS TXT Record Tag Specifications. . . . . . . 50 7.5。 DKIMの主要なタイプ登録. . . . . . . . . . . . . . . . . . 50 7.6。 DKIMは.517.7にアルゴリズム登録を論じ尽くします。 DKIMサービスは登録. . . . . . . . . . . . . . . 51 7.8をタイプします。 DKIMセレクタは登録. . . . . . . . . . . . . . . 52に旗を揚げさせます。
Allman, et al. Standards Track [Page 2] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[2ページ]。
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57
9.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60
A.1. The user composes an email . . . . . . . . . . . . . . . . 60
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69
7.9. DKIM-署名ヘッダーフィールド. . . . . . . . . . . . . . . 52 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 52 8.1。 ボディーの長さの誤用は.528.2を制限します(「l=」タグ)。 秘密鍵. . . . . . . . . . . . . . . 53 8.3を流用しました。 主要なサーバサービス不能攻撃. . . . . . . . . . . 54 8.4。 DNS. . . . . . . . . . . . . . . . . 54 8.5に対する攻撃。 反射攻撃. . . . . . . . . . . . . . . . . . . . . . 55 8.6。 キー. . . . . . . . . . . . . . . . . 55 8.7を取り消すときの限界。 故意に奇形の主要な記録. . . . . . . . . . . 56 8.8。 故意に奇形のDKIM-署名ヘッダーフィールド. . . 56 8.9。 情報漏出. . . . . . . . . . . . . . . . . . . 56 8.10。 リモートタイミングは.56 8.11を攻撃します。 ヘッダーフィールド. . . . . . . . . . . . . . . . . 56 8.12をReorderedしました。 RSAは.56 8.13を攻撃します。 親ドメイン. . . . . . . . . 57 9のそばの不適当な調印。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 57 9.2。 使用(有益)の. . . . . . . . . . . . 60に関する有益な参照. . . . . . . . . . . . . . . . . . 58付録A.の例、A.1。 ユーザはメール. . . . . . . . . . . . . . . . 60A.2を構成します。 メールはサインされた.61A.3です。 メール署名は確かめられた.61Appendix B.Usage Examples(INFORMATIVE). . . . . . . . . . . . 62B.1です。 服従シナリオ. . . . . . . . . . . . . . 63B.2を交替してください。 .67の公開鍵の(有益)の付録D.MUA問題. . . . . . . . . . . . . . . . . 68付録E.承認. . . . . . . . . . . . . . . . . . 69を作成する代替配送シナリオ. . . . . . . . . . . . . . . 65付録C.
Allman, et al. Standards Track [Page 3] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[3ページ]。
1. Introduction
1. 序論
DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.
DomainKeys Identifiedメール(DKIM)は暗号でメールメッセージにサインできるメカニズムを定義します、調印ドメインがメッセージの導入のためにメールストリームの中に犯行声明を出すことを許可して。 メッセージ受取人は、適切な公開鍵を検索するために署名者のドメインについて質問することによって直接署名について確かめて、その結果、メッセージが秘密鍵の所有物のパーティーによって調印ドメインに証明されたと確認できます。
The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
DKIMによって取られたアプローチはそれでメッセージ調印への前のアプローチ(例えば、Secure/マルチパーパスインターネットメールエクステンション(S/MIME)[RFC1847]、OpenPGP[RFC2440])と異なっています:
o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the
message body;
o メッセージ署名がメッセージヘッダーフィールドとして書かれているので、人間の受取人でなくてまた既存でないMUA(メール・ユーザー・エージェント)ソフトウェアはメッセージ本体の署名関連の満足している排臨で混乱します。
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities;
o 依存が全く周知の、そして、信じられた認証局によって発行される公衆と秘密鍵組にありません。
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation;
o 公開鍵分配か取消しのためのどんな新しいインターネットプロトコルやサービスの展開でも依存が全くありません。
o signature verification failure does not force rejection of the
message;
o 署名照合失敗はメッセージの拒絶を強制しません。
o no attempt is made to include encryption as part of the mechanism;
o メカニズムの一部として暗号化を含んでいるのを試みを全くしません。
o message archiving is not a design goal.
o メッセージ格納はデザイン目標ではありません。
DKIM:
DKIM:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o 既存のメールインフラストラクチャと互換性があって可能な最もふくよかな範囲に透明です。
o requires minimal new infrastructure;
o 最小量の新社会資本を必要とします。
o can be implemented independently of clients in order to reduce
deployment time;
o クライアントの如何にかかわらず展開時間を減少させるために実行できます。
o can be deployed incrementally;
o 増加して配備できます。
o allows delegation of signing to third parties.
o 第三者にサインする代表団を許容します。
Allman, et al. Standards Track [Page 4] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[4ページ]。
1.1. Signing Identity
1.1. アイデンティティにサインします。
DKIM separates the question of the identity of the signer of the message from the purported author of the message. In particular, a signature includes the identity of the signer. Verifiers can use the signing information to decide how they want to process the message. The signing identity is included as part of the signature header field.
DKIMはメッセージの主張された作者とメッセージの署名者のアイデンティティの問題を切り離します。 特に、署名は署名者のアイデンティティを含んでいます。 検証は、それらがどうメッセージを処理したがっているかを決めるのに調印情報を使用できます。 調印のアイデンティティは署名ヘッダーフィールドの一部として含まれています。
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field because of the broad methods of interpretation by
recipient mail systems, including MUAs.
有益な原理: DKIM署名で指定された調印のアイデンティティは解釈の広い方法のために受取人メールシステムでどんな特定のヘッダーフィールドでもアドレスを合わせるのに必要ではありません、MUAsを含んでいて。
1.2. Scalability
1.2. スケーラビリティ
DKIM is designed to support the extreme scalability requirements that characterize the email identification problem. There are currently over 70 million domains and a much larger number of individual addresses. DKIM seeks to preserve the positive aspects of the current email infrastructure, such as the ability for anyone to communicate with anyone else without introduction.
DKIMは、メール識別問題を特徴付ける極端なスケーラビリティ要件を支持するように設計されています。 現在、はるかに多くの個々のアドレスがあります。 DKIMは現在のメールインフラストラクチャの肯定的な面を保持しようとします、だれでも序論なしで他の誰ともコミュニケートする能力などのように。
1.3. Simple Key Management
1.3. 簡単なKey Management
DKIM differs from traditional hierarchical public-key systems in that no Certificate Authority infrastructure is required; the verifier requests the public key from a repository in the domain of the claimed signer directly rather than from a third party.
DKIMはCertificate Authorityインフラストラクチャが全く必要でないという点において伝統的な階層的な公開カギシステムと異なっています。 検証は第三者より要求された署名者のドメインの倉庫から公開鍵を直接むしろ要求します。
The DNS is proposed as the initial mechanism for the public keys. Thus, DKIM currently depends on DNS administration and the security of the DNS system. DKIM is designed to be extensible to other key fetching services as they become available.
DNSは公開鍵のための初期のメカニズムとして提案されます。 したがって、DKIMは現在、DNSシステムのDNS管理とセキュリティに頼ります。 DKIMは、利用可能になるので他の主要な魅惑的なサービスに広げることができるように設計されています。
2. Terminology and Definitions
2. 用語と定義
This section defines terms used in the rest of the document. Syntax descriptions use the form described in Augmented BNF for Syntax Specifications [RFC4234].
このセクションはドキュメントの残りに使用される用語を定義します。 構文記述はSyntax Specifications[RFC4234]のためにAugmented BNFで説明されたフォームを使用します。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Allman, et al. Standards Track [Page 5] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[5ページ]。
2.1. Signers
2.1. 署名者
Elements in the mail system that sign messages on behalf of a domain are referred to as signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other agents such as mailing list exploders. In general, any signer will be involved in the injection of a message into the message system in some way. The key issue is that a message must be signed before it leaves the administrative domain of the signer.
メールシステムのドメインを代表してメッセージにサインする要素が署名者と呼ばれます。 これらは、MUAs(メール・ユーザー・エージェント)、MSAs(Submissionエージェントに郵送する)、MTAs(メール配達エージェント)、またはメーリングリスト発破器などの他のエージェントであるかもしれません。 一般に、どんな署名者も何らかの方法でメッセージシステムへのメッセージの注射にかかわるでしょう。 主要な問題は署名者の管理ドメインを出る前にメッセージにサインしなければならないということです。
2.2. Verifiers
2.2. 検証
Elements in the mail system that verify signatures are referred to as verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. In most cases it is expected that verifiers will be close to an end user (reader) of the message or some consuming agent such as a mailing list exploder.
メールシステムの署名について確かめる要素が検証と呼ばれます。 これらは、MTAs、メールDeliveryエージェント(MDAs)、またはMUAsであるかもしれません。 多くの場合、メッセージかいくつかのエンドユーザ(読者)の近くに検証がメーリングリスト発破器などのエージェントを消費しながらあると予想されます。
2.3. Whitespace
2.3. 空白
There are three forms of whitespace:
空白の3つのフォームがあります:
o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]).
o WSPは簡単な空白、すなわち、スペースまたはタブキャラクタ([RFC4234]への公式の定義)の代理をします。
o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]).
o LWSPはWSPとCRLF([RFC4234]への公式の定義)と定義された直線的な空白です。
o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined.
o FWSは折りたたみの空白です。 それは少なくとも1つの空白があとに続いた、接合されたCRLFによって切り離された複数の線を許容します。
The formal ABNF for these are (WSP and LWSP are given for information only):
これらのための正式なABNFはこと(情報だけのためにWSPとLWSPを与える)です:
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
WSPはSP / HTAB LWSP=*(WSP / CRLF WSP)FWS=[*WSP CRLF]1*WSPと等しいです。
The definition of FWS is identical to that in [RFC2822] except for the exclusion of obs-FWS.
FWSの定義はobs-FWSの除外を除いた[RFC2822]でそれと同じです。
2.4. Common ABNF Tokens
2.4. 一般的なABNF象徴
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
以下のABNF象徴はほかの場所で本書では使用されます: 「ハイフンでつないだ単語がアルファー[*(ALPHA / DIGIT /「-」)(アルファー/ケタ)]base64string=1*と等しい、(アルファ/ケタ/「+」/、」 /、」 /[FWS)[「=」[FWS][[FWS]と「等しいです」]]
Allman, et al. Standards Track [Page 6] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[6ページ]。
2.5. Imported ABNF Tokens
2.5. 輸入されたABNF象徴
The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive.
注意されるように他のRFCsから以下の象徴を輸入します。 それらのRFCsは決定的であると考えられるべきです。
The following tokens are imported from [RFC2821]:
[RFC2821]から以下の象徴を輸入します:
o "Local-part" (implementation warning: this permits quoted strings)
o 「地方の部分」(実現警告: これは引用文字列を可能にします)
o "sub-domain"
o 「サブドメイン」
The following tokens are imported from [RFC2822]:
[RFC2822]から以下の象徴を輸入します:
o "field-name" (name of a header field)
o 「フィールド名」(ヘッダーフィールドの名前)
o "dot-atom-text" (in the Local-part of an email address)
o 「ドット原子テキスト」(EメールアドレスのLocal-部分の)
The following tokens are imported from [RFC2045]:
[RFC2045]から以下の象徴を輸入します:
o "qp-section" (a single line of quoted-printable-encoded text)
o 「qp-セクション」(シングルが立ち並んでいる、引用、印刷可能である、コード化、テキスト)
o "hex-octet" (a quoted-printable encoded octet)
o 「十六進法八重奏」(引用されて印刷可能なコード化された八重奏)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey
the rules of RFC 4234 and must be interpreted accordingly,
particularly as regards case folding.
有益な注意: RFC2045のABNFにRFC4234の規則に従わないで、それに従って、解釈しなければならないのを意識してください、特にあいさつが折り重なりをケースに入れるように。
Other tokens not defined herein are imported from [RFC4234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc.
[RFC4234]からここに定義されなかった他の象徴を輸入します。 これらはSP、HTAB、WSP、アルファー、DIGIT、CRLFなどの直感的な基関数です。
2.6. DKIM-Quoted-Printable
2.6. DKIMが引用した、印刷可能
The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding.
DKIMが引用した、印刷可能である、構文をコード化すると、Quoted印刷可能な[RFC2045]、セクション6.7で説明されたそれは似通います: 2つの16進数字がそのキャラクタの16進でコード化された整数値を表しながらアルファベット"0123456789ABCDEF"(どんな小文字のキャラクタも可能にしなかった)からあとに続いていて、どんなキャラクタも「=」としてコード化されるかもしれません。 すべての制御文字(値の<%x20があるそれら)、8ビットのキャラクタ(値の>%x7F)、キャラクタDEL(%x7F)、SPACE(%x20)、およびセミコロン、(「」、;、%x3B) コード化しなければなりません。 SPACE、CR、およびLFキャラクタを含むすべての空白をコード化しなければならないことに注意してください。 コード化、FWS MAYの後、過度に長い線を避けるために任意の位置で加えられてください。 そのような空白を価値の一部でなく、解読する前に、取り除かなければなりません。
Allman, et al. Standards Track [Page 7] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[7ページ]。
ABNF:
ABNF:
dkim-quoted-printable =
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
dkimが引用した、印刷可能である、=*(dkimの安全な十六進法FWS/八重奏/炭)。 十六進法八重奏はRFC2045のdkimの安全な炭=%からx21-3A/%x3C/%x3E-7E来ています。 ''!'--'、:、'、'<'、'>'--'~'、。 キャラクターは中で「メール安全である」として記載しませんでした。 また、RFC2049は推薦されません。
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways:
有益な注意: DKIMが引用した、印刷可能である、いくつかの重要な方法でRFC2045の定義されるとして印刷可能なQuotedと異なっています:
1. Whitespace in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does
not permit encoding of CR or LF characters that are part of a
CRLF line break.
1. CRとLFを含む入力テキストの空白をコード化しなければなりません。 RFC2045は、そのようなコード化を必要としないで、またCRLFラインブレイクの一部であるCRかLFキャラクタにコード化するのを可能にしません。
2. Whitespace in the encoded text is ignored. This is to allow
tags encoded using DKIM-Quoted-Printable to be wrapped as
needed. In particular, RFC 2045 requires that line breaks in
the input be represented as physical line breaks; that is not
the case here.
2. コード化されたテキストの空白は無視されます。 これが使用することでコード化されたタグを許容するためのものである、DKIMが引用した、印刷可能である、必要に応じて包装されるために。 特に、RFC2045は、物理行が壊れるので入力におけるラインブレイクが表されるのを必要とします。 それはここのそうではありません。
3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply.
3. 「柔らかいラインブレイク」構文(線の上の最後の非空白キャラクタとしての「=」)は適用されません。
4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded
text is being used).
4. DKIMが引用した、印刷可能である、コード化された線が長い間(コード化されたテキストが使用されている文脈による他の要件があるかもしれませんが)76未満のキャラクタであることが必要ではありません。
3. Protocol Elements
3. プロトコル要素
Protocol Elements are conceptual parts of the protocol that are not specific to either signers or verifiers. The protocol descriptions for signers and verifiers are described in later sections (Signer Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This section must be read in the context of those sections.
Protocol Elementsはプロトコルの署名者か検証のどちらかに特定でない概念的な部分です。 後のセクション(署名者Actions(セクション5)とVerifier Actions(セクション6))で署名者と検証のためのプロトコル記述は説明されます。 以下に注意してください。 それらのセクションの文脈でこのセクションを読まなければなりません。
3.1. Selectors
3.1. セレクタ
To support multiple concurrent public keys per signing domain, the key namespace is subdivided using "selectors". For example, selectors might indicate the names of office locations (e.g., "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date (e.g., "january2005", "february2005", etc.), or even the individual user.
複数のドメインにサインするのあたりの同時発生の公開鍵を支持するために、主要な名前空間は「セレクタ」を使用することで細分されます。 例えば、セレクタは店舗立地の名前(例えば、"sanfrancisco"、"coolumbeach"、および"reykjavik")、調印日付(例えば、"january2005"、"february2005"など)、または個々のユーザさえ示すかもしれません。
Allman, et al. Standards Track [Page 8] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[8ページ]。
Selectors are needed to support some important use cases. For example:
セレクタによる必要であることで、重要な状態でいくつかを支持するのがケースを使用するということです。 例えば:
o Domains that want to delegate signing capability for a specific
address for a given duration to a partner, such as an advertising
provider or other outsourced function.
o 与えられた持続時間のための特定のアドレスのために何らかの広告主などのパートナーへ調印能力を社外調達されていた状態で代表として派遣したがっているドメインが機能します。
o Domains that want to allow frequent travelers to send messages
locally without the need to connect with a particular MSA.
o 頻繁な旅行者が特定のMSAに接続する必要性なしでメッセージを局所的に送るのを許容したがっているドメイン。
o "Affinity" domains (e.g., college alumni associations) that
provide forwarding of incoming mail, but that do not operate a
mail submission agent for outgoing mail.
o 入って来るメールの推進を提供しますが、送信するメールのためにメール服従エージェントを手術しない「Affinity」ドメイン(例えば、大学同窓会)。
Periods are allowed in selectors and are component separators. When keys are retrieved from the DNS, periods in selectors define DNS label boundaries in a manner similar to the conventional use in domain names. Selector components might be used to combine dates with locations, for example, "march2005.reykjavik". In a DNS implementation, this can be used to allow delegation of a portion of the selector namespace.
期間は、セレクタに許容されていて、コンポーネント分離符です。 キーがDNSから検索されるとき、セレクタの期間はドメイン名における従来の使用と同様の方法におけるDNSラベル境界を定義します。 セレクタの部品は、"march2005.reykjavik"という例えば、位置がある日付を結合するのに使用されるかもしれません。 DNS実現では、セレクタ名前空間の部分の代表団を許容するのにこれを使用できます。
ABNF:
ABNF:
selector = sub-domain *( "." sub-domain )
セレクタ=サブドメイン*(「. 」 サブドメイン、)
The number of public keys and corresponding selectors for each domain is determined by the domain owner. Many domain owners will be satisfied with just one selector, whereas administratively distributed organizations may choose to manage disparate selectors and key pairs in different regions or on different email servers.
各ドメインへの公開鍵と対応するセレクタの数はドメイン所有者によって測定されます。 多くのドメイン所有者がちょうど1個のセレクタに満足するでしょうが、行政上分配された組織は、異なった領域、または、異なったEメールサーバの上で異種のセレクタと主要な組を経営するのを選ぶかもしれません。
Beyond administrative convenience, selectors make it possible to seamlessly replace public keys on a routine basis. If a domain wishes to change from using a public key associated with selector "january2005" to a public key associated with selector "february2005", it merely makes sure that both public keys are advertised in the public-key repository concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the "february2005" private key. At the end of the transition period, the "january2005" public key is removed from the public-key repository.
管理便利を超えて、セレクタで継ぎ目なく普段から公開鍵を交換するのは可能になります。 ドメインであるなら、セレクタ"january2005"に関連している公開鍵を使用するので公開鍵に変化するという願望はセレクタ"february2005"と交際して、それは、両方の公開鍵がメールが検証の前にトランジット中であるかもしれない過渡期のために同時に公開カギ倉庫に広告を出すのを単に確実にします。 過渡期の始めでは、外国行きのEメールサーバは、"february2005"秘密鍵と契約するために構成されます。 過渡期の終わりでは、公開カギ倉庫から"january2005"公開鍵を取り除きます。
INFORMATIVE NOTE: A key may also be revoked as described below.
The distinction between revoking and removing a key selector
record is subtle. When phasing out keys as described above, a
signing domain would probably simply remove the key record after
有益な注意: また、キーは以下で説明されるように取り消されるかもしれません。 主要なセレクタ記録を取り消して、取り除くところの区別は微妙です。 上で説明されるようにキーを段階的に廃止して、調印ドメインはいつたぶん単に主要な記録を取り除きますか。
Allman, et al. Standards Track [Page 9] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[9ページ]。
the transition period. However, a signing domain could elect to
revoke the key (but maintain the key record) for a further period.
There is no defined semantic difference between a revoked key and
a removed key.
過渡期。 しかしながら、調印ドメインは、さらなる期間、キー(主要な記録を保守する)を取り消すのを選ぶかもしれません。 取り消されたキーと取り外されたキーの意味違いは定義されません。
While some domains may wish to make selector values well known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties. For example, if per-user keys are issued, the domain owner will need to make the decision as to whether to associate this selector directly with the user name, or make it some unassociated random value, such as a fingerprint of the public key.
いくつかのドメインがセレクタ値をよく明らかにしたがっているかもしれない間、他のものは、外部のパーティーでデータを取り入れる方法でセレクタ名を割り当てないように注意したくなるでしょう。 例えば、1ユーザあたりのキーが支給されると、ドメイン所有者は、直接ユーザ名にこのセレクタを関連づけるか、またはそれを作るために、或るものが無作為の値を非連想したかどうかに関して決定をする必要があるでしょう、公開鍵の指紋のように。
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key
(for example, changing the key associated with a user's name)
makes it impossible to tell the difference between a message that
didn't verify because the key is no longer valid versus a message
that is actually forged. For this reason, signers are ill-advised
to reuse selectors for new keys. A better strategy is to assign
new keys to new selectors.
有益な操作は以下に注意します。 新しいキー(例えば、ユーザの名前に関連しているキーを変える)でセレクタを再利用するのに、キーがもう実際に作り出されるメッセージに対して有効でないのでそれが確かめなかったメッセージの違いを言うのは不可能になります。 この理由で、署名者は、新しいキーのためにセレクタを再利用するためにあさはかです。 より良い戦略は新しいセレクタの新しいキーを割り当てることです。
3.2. Tag=Value Lists
3.2. タグ=値リスト
DKIM uses a simple "tag=value" syntax in several contexts, including in messages and domain signature records.
DKIMはメッセージとドメイン署名に記録を含むいくつかの文脈で簡単な「タグ=価値」構文を使用します。
Values are a series of strings containing either plain text, "base64"
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid,
Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6).
The name of the tag will determine the encoding of each value.
Unencoded semicolon (";") characters MUST NOT occur in the tag value,
since that separates tag-specs.
または、値がプレーンテキストを含む一連のストリングである、「base64"テキスト([RFC2045]、セクション6.8で定義されるように)、「qp-セクション」(ibid、セクション6.7)、「dkimが引用した、印刷可能である、」、(セクション2.6で定義されるように)、」 タグの名前はそれぞれの価値のコード化を決定するでしょう。 暗号化されていないセミコロン、(「」、)、それがタグ仕様を切り離すので、キャラクタはタグ値で起こってはいけません。
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined
below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF8-encoded text in tag=value
lists.
有益な実現注意: 以下(「タグ値」として)で定義された「プレーンテキスト」は7ビットのキャラクタを含んでいるだけですが、将来の規格を予期したがっていた実現がタグ=値リストにおけるUTF8によってコード化されたテキストの使用を排除しないように教えられるでしょう。
Allman, et al. Standards Track [Page 10] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[10ページ]。
Formally, the syntax rules are as follows:
正式に、シンタックス・ルールは以下の通りです:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
タグリスト=タグ仕様0*、(「」、;、タグ仕様)、[「」、]、タグ仕様=[FWS]タグ名[FWS]の「=」[FWS]タグ価値[FWS]タグ名=アルファ0*ALNUMPUNCタグ価値は[tval0*(1*(WSP / FWS)tval)]と等しいです。 WSPとFWSは首尾で1*VALCHAR VALCHAR=tval=%をx21-3A/%x3C-7E禁止しました。 セミコロンALNUMPUNC以外のティルドへの感嘆はアルファ/ケタ/"_"と等しいです。
Note that WSP is allowed anywhere around tags. In particular, any WSP after the "=" and any WSP before the terminating ";" is not part of the value; however, WSP inside the value is significant.
WSPがタグの周りでどこでも許容されていることに注意してください。 「特に「終わりの前の=」 いずれもWSP」の後のどんなWSPも」 価値の一部ではありません。 しかしながら、値におけるWSPは重要です。
Tags MUST be interpreted in a case-sensitive manner. Values MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity.
大文字と小文字を区別する方法でタグを解釈しなければなりません。 意味論の明確なタグ記述が大文字小文字の同一視を指定しない場合、大文字と小文字を区別するとして値を処理しなければなりません。
Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid.
写し名があるタグはただ一つのタグリストの中に現れてはいけません。 タグ名が一度より現れるなら、全体のタグリストは無効です。
Whitespace within a value MUST be retained unless explicitly excluded by the specific tag description.
明確なタグ記述で明らかに除かれない場合、値の中の空白を保有しなければなりません。
Tag=value pairs that represent the default value MAY be included to aid legibility.
デフォルト値を表すタグ=値組は、読みやすさを支援するために含まれるかもしれません。
Unrecognized tags MUST be ignored.
認識されていないタグを無視しなければなりません。
Tags that have an empty value are not the same as omitted tags. An omitted tag is treated as having the default value; a tag with an empty value explicitly designates the empty string as the value. For example, "g=" does not mean "g=*", even though "g=*" is the default for that tag.
空の値があるタグは省略されたタグと同じではありません。 省略されたタグはデフォルト値を持っているとして扱われます。 空の値があるタグは値として明らかに空のストリングを指定します。 例えば、「gは*と等しいです」はそのタグのためのデフォルトですが、「g=」は、「gは*と等しいです。」と意味しません。
3.3. Signing and Verification Algorithms
3.3. 調印と検証アルゴリズム
DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. The rsa-sha256 algorithm is the default if no algorithm is specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256.
DKIMは複数のデジタル署名アルゴリズムを支持します。2つのアルゴリズムがこのとき、この仕様で定義されます: rsa-sha1とrsa- sha256。 アルゴリズムが全く指定されないなら、rsa-sha256アルゴリズムはデフォルトです。 検証はrsa-sha1とrsa-sha256の両方を実行しなければなりません。 署名者は道具とSHOULDサイン使用rsa-sha256がそうしなければなりません。
Allman, et al. Standards Track [Page 11] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[11ページ]。
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever
possible.
有益な注意: sha256は強く奨励されますが、低いセキュリティメッセージ(通常のニュースレターなどの)の何人かの送付者が、sha1細切れ肉料理を計算するという減少しているCPU要件のためにsha1を使用するのを好むかもしれません。 一般に、可能であるときはいつも、sha256はいつも使用されるべきです。
3.3.1. The rsa-sha1 Signing Algorithm
3.3.1. rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. The signing algorithm SHOULD use a public exponent of 65537.
rsa-sha1 Signing Algorithmはalgを論じ尽くすとしてSHA-1[FIPS.180-2.2002]を使用する下でセクション3.7で説明されるようにメッセージ細切れ肉料理を計算します。 そして、地下室-algと署名者の秘密鍵としてRSAアルゴリズム(PKCS#1バージョン1.5[RFC3447]では、定義される)を使用することでその細切れ肉料理は署名者によってサインされます。 サインされる前に、細切れ肉料理を、先端を切られてはいけないか、ネイティブの二部形式以外のどんなフォームにも変換してはいけません。 調印アルゴリズムSHOULDは65537の公共の解説者を使用します。
3.3.2. The rsa-sha256 Signing Algorithm
3.3.2. rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed.
rsa-sha256 Signing Algorithmはalgを論じ尽くすとしてSHA-256[FIPS.180-2.2002]を使用する下でセクション3.7で説明されるようにメッセージ細切れ肉料理を計算します。 そして、地下室-algと署名者の秘密鍵としてRSAアルゴリズム(PKCS#1バージョン1.5[RFC3447]では、定義される)を使用することでその細切れ肉料理は署名者によってサインされます。 サインされる前に、細切れ肉料理を、先端を切られてはいけないか、ネイティブの二部形式以外のどんなフォームにも変換してはいけません。
3.3.3. Key Sizes
3.3.3. 主要なサイズ
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a signature is acceptable.
適切な主要なサイズを選択するのは、費用と、性能と、リスクの間のトレードオフです。 短いRSAキーが、より容易にオフライン攻撃に屈するので、署名者は長命のキーに少なくとも1024ビットのRSAキーを使用しなければなりません。 検証はキーが512ビットから2048ビットまで及んでいる署名を有効にすることができなければなりません、そして、彼らは、より大きいキーで署名を有効にすることができるかもしれません。 検証方針は署名が許容できるかどうか決定するのにおける、メートル法の1つとして主要な調印の長さを使用するかもしれません。
Factors that should influence the key size choice include the following:
主要なサイズ選択に影響を及ぼすべきである要素が以下を含んでいます:
o The practical constraint that large (e.g., 4096 bit) keys may not
fit within a 512-byte DNS UDP response packet
o (例えば、4096年のビット)の大きいキーが512バイトのDNS UDP応答パケットの中で合わないかもしれないという実用的な規制
o The security constraint that keys smaller than 1024 bits are
subject to off-line attacks
o 1024ビットより小さいキーはオフライン攻撃を受けることがあるというセキュリティ規制
o Larger keys impose higher CPU costs to verify and sign email
o より大きいキーは、メールを確かめて、サインするために、より高いCPUコストを課します。
Allman, et al. Standards Track [Page 12] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[12ページ]。
o Keys can be replaced on a regular basis, thus their lifetime can
be relatively short
o 定期的にキーを取り替えることができます、その結果、彼らの寿命は比較的短い場合があります。
o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures
o デジタル署名を使う他のシステムの典型的な目標と比べて、この仕様のセキュリティ目標は穏やかです。
See [RFC3766] for further discussion on selecting key sizes.
主要なサイズを選択することのさらなる議論に関して[RFC3766]を見てください。
3.3.4. Other Algorithms
3.3.4. 他のアルゴリズム
Other algorithms MAY be defined in the future. Verifiers MUST ignore any signatures using algorithms that they do not implement.
他のアルゴリズムは将来、定義されるかもしれません。 それらが実行しないアルゴリズムを使用して、検証はどんな署名も無視しなければなりません。
3.4. Canonicalization
3.4. Canonicalization
Empirical evidence demonstrates that some mail servers and relay systems modify email in transit, potentially invalidating a signature. There are two competing perspectives on such modifications. For most signers, mild modification of email is immaterial to the authentication status of the email. For such signers, a canonicalization algorithm that survives modest in-transit modification is preferred.
潜在的に署名を無効にして、実証的証拠は、いくつかのメールサーバとリレー方式がトランジットにおけるメールを変更するのを示します。 そのような変更には2つの競争している見解があります。 ほとんどの署名者に関しては、メールの軽い変更はメールの認証状態に重要でないです。 そのような署名者に関しては、トランジットにおける穏やかな変更を乗り切るcanonicalizationアルゴリズムは好まれます。
Other signers demand that any modification of the email, however minor, result in a signature verification failure. These signers prefer a canonicalization algorithm that does not tolerate in-transit modification of the signed email.
他の署名者は、しかしながら、メールのどんな変更、未成年者も署名照合失敗をもたらすのを要求します。 これらの署名者はトランジットにおける、サインされたメールの変更を許容しないcanonicalizationアルゴリズムを好みます。
Some signers may be willing to accept modifications to header fields that are within the bounds of email standards such as [RFC2822], but are unwilling to accept any modification to the body of messages.
いくつかの署名者は、[RFC2822]などのメール規格の領域の中にあるヘッダーフィールドへの変更を受け入れることを望むかもしれませんが、メッセージのボディーへのどんな変更も受け入れたがっていません。
To satisfy all requirements, two canonicalization algorithms are defined for each of the header and the body: a "simple" algorithm that tolerates almost no modification and a "relaxed" algorithm that tolerates common modifications such as whitespace replacement and header field line rewrapping. A signer MAY specify either algorithm for header or body when signing an email. If no canonicalization algorithm is specified by the signer, the "simple" algorithm defaults for both header and body. Verifiers MUST implement both canonicalization algorithms. Note that the header and body may use different canonicalization algorithms. Further canonicalization algorithms MAY be defined in the future; verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms.
すべての要件を満たすために、2つのcanonicalizationアルゴリズムがヘッダー各人とボディーのために定義されます: 変更をほとんど全く許容しない「簡単な」アルゴリズムと空白交換やヘッダーフィールドなどの一般的な変更を許容する「伸びやかな」アルゴリズムは再包装を裏打ちします。 メールにサインするとき、署名者はヘッダーのためのアルゴリズムかボディーのどちらかを指定するかもしれません。 canonicalizationアルゴリズムが全く署名者によって指定されないなら、「簡単な」アルゴリズムはヘッダーとボディーの両方のためにデフォルトとします。 検証は両方のcanonicalizationアルゴリズムを実行しなければなりません。ヘッダーとボディーが異なったcanonicalizationアルゴリズムを使用するかもしれないことに注意してください。さらなるcanonicalizationアルゴリズムは将来、定義されてもよいです。 検証は認識されていないcanonicalizationアルゴリズムを使用するどんな署名も無視しなければなりません。
Canonicalization simply prepares the email for presentation to the signing or verification algorithm. It MUST NOT change the
Canonicalizationはプレゼンテーションのために単に調印か検証アルゴリズムにメールを準備します。 それは変化してはいけません。
Allman, et al. Standards Track [Page 13] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[13ページ]。
transmitted data in any way. Canonicalization of header fields and body are described below.
何らかの方法でデータを送りました。 ヘッダーフィールドとボディーのCanonicalizationは以下で説明されます。
NOTE: This section assumes that the message is already in "network normal" format (text is ASCII encoded, lines are separated with CRLF characters, etc.). See also Section 5.3 for information about normalizing the message.
以下に注意してください。 このセクションは、「ネットワーク標準」形式にはメッセージが既にあると仮定します(テキストがコード化されたASCIIである、線はCRLFキャラクタなどで切り離されます)。 また、メッセージを正常にすることの情報に関してセクション5.3を見てください。
3.4.1. The "simple" Header Canonicalization Algorithm
3.4.1. 「簡単な」ヘッダーCanonicalizationアルゴリズム
The "simple" header canonicalization algorithm does not change header fields in any way. Header fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified. In particular, header field names MUST NOT be case folded and whitespace MUST NOT be changed.
「簡単な」ヘッダーcanonicalizationアルゴリズムは何らかの方法でヘッダーフィールドを変えません。 ヘッダーフィールドについてちょうどそれらがサインされるメッセージにあるので調印か検証アルゴリズムに提示されなければならないか、または確かめなければなりません。 ヘッダーフィールド名は特に、折り重ねられたケースであるはずがありません、そして、空白を変えてはいけません。
3.4.2. The "relaxed" Header Canonicalization Algorithm
3.4.2. 「伸びやかな」ヘッダーCanonicalizationアルゴリズム
The "relaxed" header canonicalization algorithm MUST apply the following steps in order:
「伸びやかな」ヘッダーcanonicalizationアルゴリズムは整然とした状態で以下のステップを当てはまらなければなりません:
o Convert all header field names (not the header field values) to
lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".
o 小文字で印刷するために、すべてのヘッダーフィールド名(ヘッダーフィールド値でない)を変換してください。 例えば、変換してください、「subject:」 "AbC"、「subject:」 "AbC"。
o Unfold all header field continuation lines as described in
[RFC2822]; in particular, lines with terminators embedded in
continued header field values (that is, CRLF sequences followed by
WSP) MUST be interpreted without the CRLF. Implementations MUST
NOT remove the CRLF at the end of the header field value.
o [RFC2822]で説明されるようにすべてのヘッダーフィールド継続行を繰り広げてください。 特に、CRLFなしでターミネータが継続的なヘッダーフィールド値(すなわち、WSPによって従われたCRLF順序)に埋め込まれている線を解釈しなければなりません。 実現はヘッダーフィールド価値の終わりでCRLFを取り外してはいけません。
o Convert all sequences of one or more WSP characters to a single SP
character. WSP characters here include those before and after a
line folding boundary.
o 単独のSPキャラクタへの1つ以上のWSPキャラクタのすべての系列を変換してください。 ここのWSPキャラクタは境界を折り重ねる線の前後にそれらを入れます。
o Delete all WSP characters at the end of each unfolded header field
value.
o それぞれの繰り広げられたヘッダーフィールド価値の終わりのすべてのWSPキャラクタを削除してください。
o Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. The
colon separator MUST be retained.
o ヘッダーフィールド値とヘッダーフィールド名を切り離すコロン前後に残っているあらゆるWSPキャラクタを削除してください。 コロン分離符を保有しなければなりません。
3.4.3. The "simple" Body Canonicalization Algorithm
3.4.3. 「簡単な」ボディーCanonicalizationアルゴリズム
The "simple" body canonicalization algorithm ignores all empty lines at the end of the message body. An empty line is a line of zero length after removal of the line terminator. If there is no body or no trailing CRLF on the message body, a CRLF is added. It makes no
「簡単な」ボディーcanonicalizationアルゴリズムはメッセージ本体の先のすべての人影のない線を無視します。 人影のない線は線ターミネータの取り外しの後のゼロ・レングスの線です。 メッセージ本体の上にどんなボディーがないのも引きずっているCRLFもなければ、CRLFは加えられます。 それはいいえを作ります。
Allman, et al. Standards Track [Page 14] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[14ページ]。
other changes to the message body. In more formal terms, the "simple" body canonicalization algorithm converts "0*CRLF" at the end of the body to a single "CRLF".
メッセージ本体への他の変化。 より正式な用語で、「簡単な」ボディーcanonicalizationアルゴリズムはボディーの先で「0*CRLF」を単一の"CRLF"に変換します。
Note that a completely empty or missing body is canonicalized as a single "CRLF"; that is, the canonicalized length will be 2 octets.
完全に空の、または、なくなったボディーが単一の"CRLF"としてcanonicalizedされることに注意してください。 すなわち、canonicalized長さは2つの八重奏になるでしょう。
3.4.4. The "relaxed" Body Canonicalization Algorithm
3.4.4. 「伸びやかな」ボディーCanonicalizationアルゴリズム
The "relaxed" body canonicalization algorithm:
「伸びやかな」ボディーcanonicalizationアルゴリズム:
o Ignores all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.
o 行末のすべての空白を無視します。 実現は行の終わりでCRLFを取り外してはいけません。
o Reduces all sequences of WSP within a line to a single SP
character.
o 線の中でWSPのすべての系列を単独のSPキャラクタに減少させます。
o Ignores all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.
o メッセージ本体の先のすべての人影のない線を無視します。 「人影のない線」はセクション3.4.3で定義されます。
INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead.
有益な注意: 伸びやかなボディーcanonicalizationアルゴリズムがメッセージが単語の間のスペースを調整することによって伝えられるかもしれない非常に粗雑な「ASCII芸術」攻撃のあるタイプを可能にするかもしれないことに注意されるべきです。 これが関心であるなら、「簡単な」ボディーcanonicalizationアルゴリズムは代わりに使用されるべきです。
3.4.5. Body Length Limits
3.4.5. ボディー長さの限界
A body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in octets. If the body length count is not specified, the entire message body is signed.
ボディー長さのカウントは、署名計算を八重奏で測定された本文の初期の接頭語に制限するために指定されるかもしれません。 ボディー長さのカウントが指定されないなら、全体のメッセージ本体はサインされます。
INFORMATIVE RATIONALE: This capability is provided because it is
very common for mailing lists to add trailers to messages (e.g.,
instructions how to get off the list). Until those messages are
also signed, the body length count is a useful tool for the
verifier since it may as a matter of policy accept messages having
valid signatures with extraneous data.
有益な原理: メーリングリストがトレーラをメッセージに追加するのが、非常に一般的であるのでこの能力を提供する、(例えば、指示、どうリストを離すか) 異質なデータで政策の問題として有効な署名を持っているメッセージを受け入れるかもしれないので、また、それらのメッセージがサインされるまで、ボディー長さのカウントは検証のための有益な手段です。
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
an attack in which an attacker modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes and to defeat duplicate message detection
algorithms. To avoid this attack, signers should be wary of using
有益な実現注意: ボディー長さの限界を使用すると、攻撃者が唯一攻撃者のためになる内容を含むメッセージを変更する攻撃は可能にされます。 追加された内容が終わりの受取人の目でオリジナルコンテンツを完全に置き換えて、写しメッセージ検出アルゴリズムを破るのは可能です。この攻撃を避けるために、署名者は使用に用心深いはずです。
Allman, et al. Standards Track [Page 15] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[15ページ]。
this tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length, perhaps
based on other criteria.
このタグ、およびタグを無視するか、または指定されたコンテンツの長さの後に現れるテキストを取り除くという検証力の願望は恐らく他の評価基準を基礎づけました。
The body length count allows the signer of a message to permit data to be appended to the end of the body of a signed message. The body length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the body length count. Signers of MIME messages that include a body length count SHOULD be sure that the length extends to the closing MIME boundary string.
ボディー長さのカウントはデータがサインされたメッセージのボディーの先まで追加されることを許可するメッセージの署名者を許容します。 canonicalizationアルゴリズムに従って、ボディー長さのカウントについて計算しなければなりません。 例えば、canonicalizationアルゴリズムで無視されたどんな空白もボディー長さのカウントの一部として含まれていません。 確実にそれが長さであったならボディーの長さのカウントSHOULDを含んでいるMIMEメッセージの署名者は終わりのMIME境界ストリングに達します。
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that
the only acceptable modifications are to add to the MIME postlude
would use a body length count encompassing the entire final MIME
boundary string, including the final "--CRLF". A signer wishing
to allow additional MIME parts but not modification of existing
parts would use a body length count extending through the final
MIME boundary string, omitting the final "--CRLF". Note that this
only works for some MIME types, e.g., multipart/mixed but not
multipart/signed.
有益な実現注意: 確実にする唯一の許容できる変更がMIME後奏曲に追加することになっている署名者願望は全体の最終的なMIME境界ストリングを取り囲むボディー長さのカウントを使用するでしょう、決勝を含んでいて「--、CRLF、」 存在する変更ではなく、追加MIMEの部品に部品を許容する署名者願望は最終的なMIME境界ストリングを通して広がるボディー長さのカウントを使用するでしょう、決勝を省略して「--、CRLF、」 これがいくつかのMIMEの種類、例えば、しかし、複合でないまたはサインされていなく混ぜられた複合/のために働くだけであることに注意してください。
A body length count of zero means that the body is completely unsigned.
ゼロのボディー長さのカウントは、ボディーが完全に無記名であることを意味します。
Signers wishing to ensure that no modification of any sort can occur should specify the "simple" canonicalization algorithm for both header and body and omit the body length count.
どんな種類の変更も全く起こることができないのを保証したがっている署名者は、「簡単な」canonicalizationアルゴリズムをヘッダーとボディーの両方に指定して、ボディー長さのカウントを省略するはずです。
3.4.6. Canonicalization Examples (INFORMATIVE)
3.4.6. Canonicalizationの例(有益)です。
In the following examples, actual whitespace is used only for clarity. The actual input and output text is designated using bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a tab character, and "<CRLF>" for a carriage-return/line-feed sequence. For example, "X <SP> Y" and "X<SP>Y" represent the same three characters.
以下の例では、実際の空白は明快にだけ使用されます。 実際の入出力テキストは腕木を付けられた記述子を使用することで指定されます: 間隔文字のための「<SP>」、タブキャラクタのための「<HTAB>」、および復帰/改行系列のための「<CRLF>。」 例えば、「X<SP>Y」と「X<SP>Y」は同じ3つのキャラクタの代理をします。
Example 1: A message reading:
例1: メッセージの読み:
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
<CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<CRLF>
<CRLF>
A: <SP>X<CRLF>B<SP>: <SP>Y<HTAB><CRLF><HTAB>Z<SP><SP><CRLF><CRLF><SP>C<SP><CRLF>D<SP><HTAB><SP>E<CRLF><CRLF @?CRLF
Allman, et al. Standards Track [Page 16] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[16ページ]。
when canonicalized using relaxed canonicalization for both header and body results in a header reading:
canonicalizedされると、使用はヘッダーとボディー結果の両方のために以下を読んでいるヘッダーでcanonicalizationを弛緩しました。
a:X <CRLF>
b:Y <SP> Z <CRLF>
: X<CRLF>b: Y<SP>Z<CRLF>。
and a body reading:
ボディーの読み:
<SP> C <CRLF>
D <SP> E <CRLF>
<SP>C<CRLF>D<SP>E<CRLF>。
Example 2: The same message canonicalized using simple canonicalization for both header and body results in a header reading:
例2: 同じメッセージはヘッダーとボディー結果の両方にヘッダーの読みに簡単なcanonicalizationを使用することでcanonicalizedされました:
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
A: <SP>X<CRLF>B<SP>: <SP>Y<HTAB><CRLF><HTAB>Z<SP><SP><CRLF>。
and a body reading:
ボディーの読み:
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<SP>C<SP><CRLF>D<SP><HTAB><SP>E<CRLF>。
Example 3: When processed using relaxed header canonicalization and simple body canonicalization, the canonicalized version has a header of:
例3: 伸びやかなヘッダーcanonicalizationと簡単なボディーcanonicalizationを使用することで処理されると、canonicalizedバージョンには、以下のヘッダーがあります。
a:X <CRLF>
b:Y <SP> Z <CRLF>
: X<CRLF>b: Y<SP>Z<CRLF>。
and a body reading:
ボディーの読み:
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<SP>C<SP><CRLF>D<SP><HTAB><SP>E<CRLF>。
3.5. The DKIM-Signature Header Field
3.5. DKIM-署名ヘッダーフィールド
The signature of the email is stored in the DKIM-Signature header field. This header field contains all of the signature and key- fetching data. The DKIM-Signature value is a tag-list as described in Section 3.2.
メールの署名はDKIM-署名ヘッダーフィールドに格納されます。 このヘッダーフィールドは署名と主要な魅惑的なデータのすべてを含んでいます。 DKIM-署名値はセクション3.2で説明されるようにタグリストです。
The DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC2822], and hence SHOULD NOT be reordered and SHOULD be prepended to the message.
DKIM-署名ヘッダーフィールドSHOULD、扱われて、それが[RFC2822]、およびしたがって、SHOULD NOTのセクション3.6で定義される跡のヘッダーフィールドであるのに似てください、再命令、SHOULD、メッセージにprependedされます。
Allman, et al. Standards Track [Page 17] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[17ページ]。
The DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the "b=" tag (signature value) of that DKIM- Signature header field MUST be treated as though it were an empty string. Unknown tags in the DKIM-Signature header field MUST be included in the signature calculation but MUST be otherwise ignored by verifiers. Other DKIM-Signature header fields that are included in the signature should be treated as normal header fields; in particular, the "b=" tag is not treated specially.
作成されるか、または確かめられるDKIM-署名ヘッダーフィールドは署名計算にいつも含まれています、サインされるヘッダーフィールドの残りの後に。 しかしながら、署名について計算するか、または確かめるとき、まるでそれが空のストリングであるかのようにそのDKIM署名ヘッダーフィールドの「b=」タグ(署名値)の値を扱わなければなりません。 DKIM-署名ヘッダーフィールドにおける未知のタグを署名計算に含まなければなりませんが、別の方法で検証で無視しなければなりません。 署名に含まれている他のDKIM-署名ヘッダーフィールドは正常なヘッダーフィールドとして扱われるべきです。 特に、特に、「b=」タグは扱われません。
The encodings for each field type are listed below. Tags described as qp-section are encoded as described in Section 6.7 of MIME Part One [RFC2045], with the additional conversion of semicolon characters to "=3B"; intuitively, this is one line of quoted-printable encoded text. The dkim-quoted-printable syntax is defined in Section 2.6.
各フィールド・タイプのためのencodingsは以下に記載されています。 qp-セクションとして記述されたタグはMIME Part One[RFC2045]のセクション6.7でセミコロンキャラクタの追加変換で説明されて、「3Bと等しくなる」ようにコード化されます。 これは直観的に、引用されて印刷可能なコード化されたテキストの1つの線です。 dkimが引用した、印刷可能である、構文はセクション2.6で定義されます。
Tags on the DKIM-Signature header field along with their type and requirement status are shown below. Unrecognized tags MUST be ignored.
それらのタイプと要件状態に伴うDKIM-署名ヘッダーフィールドのタグは以下で見せられます。 認識されていないタグを無視しなければなりません。
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison
on this value; for example, "1" is not the same as "1.0".
=バージョン(含まなければならない)に対して。 このタグは署名記録に適用されるこの仕様のバージョンを定義します。 それには、値「1インチ」がなければなりません。 検証がこの値でストリング比較をしなければならないことに注意してください。 例えば、「1インチは「1インチ」と同じではありません。
ABNF:
ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
sig-v-タグ=%x76[FWS]は[FWS]と「1インチ」「等しいです」。
INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this
specification are released.
有益な注意: この仕様の新しいバージョンがリリースされるのに従ってDKIM-署名バージョン番号が算術で増加すると予想されます。
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms.
アルゴリズムが署名(プレーンテキスト; REQUIRED)を発生させるのに使用した=。 検証は「rsa-sha1"と"rsa-sha256"」を支持しなければなりません。 署名者SHOULDは、"rsa-sha256"を使用することでサインします。 アルゴリズムの記述に関してセクション3.3を見てください。
ABNF:
ABNF:
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
タグ..タグ..タグ..等しい..タグ..滋賀..タグ..滋賀..タグ..滋賀..タグ..滋賀..タグ..滋賀..タグ..滋賀..タグ..等しい..アルファ..アルファー..ケタ 後の拡大のために、x-sig aタグhはアルファー*と等しいです(アルファー/DIGIT)。 後の拡大のために
Allman, et al. Standards Track [Page 18] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[18ページ]。
b= The signature data (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Signer Actions (Section 5) for how the signature is
computed.
bは署名データと等しいです(base64; REQUIRED)。 空白をこの値で無視されて、オリジナルの署名を組み立て直すとき、無視しなければなりません。 特に、サインアップ過程は安全に行長限界に従う任意の場所のこの値にFWSを挿入できます。 署名がどう計算されるかために、Signer Actions(セクション5)を見てください。
ABNF:
ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
sig-b-タグ=%x62[FWS]は[FWS]sig-bタグデータsig-bタグデータ=base64stringと「等しいです」。
bh= The hash of the canonicalized body part of the message as limited
by the "l=" tag (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Section 3.7 for how the body hash is computed.
bhは制限されるとしての「l=」タグ(base64; REQUIRED)によるメッセージのcanonicalized身体の部分の細切れ肉料理と等しいです。 空白をこの値で無視されて、オリジナルの署名を組み立て直すとき、無視しなければなりません。 特に、サインアップ過程は安全に行長限界に従う任意の場所のこの値にFWSを挿入できます。 ボディー細切れ肉料理がどう計算されるかためにセクション3.7を見てください。
ABNF:
ABNF:
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string
sig-bh-タグ=%x62%x68[FWS]は[FWS]sig-bhタグデータsig-bhタグデータ=base64stringと「等しいです」。
c= Message canonicalization (plain-text; OPTIONAL, default is
"simple/simple"). This tag informs the verifier of the type of
canonicalization used to prepare the message for signing. It
consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the
header and "simple" is used for the body. For example,
"c=relaxed" is treated the same as "c=relaxed/simple".
cはメッセージcanonicalizationと等しいです(; プレーンテキスト、OPTIONAL、デフォルトは「簡単であるか簡単です」)。 このタグは調印のためにメッセージを準備するのに使用されるcanonicalizationのタイプの検証を知らせます。 それはヘッダーに文通していて、「スラッシュ」(%d47)キャラクタによって切り離された2つの名前とボディーcanonicalizationアルゴリズムからそれぞれ成ります。 これらのアルゴリズムはセクション3.4で説明されます。 1つのアルゴリズムだけが命名されるなら、アルゴリズムがヘッダーに中古で「簡単であること」はボディーに使用されます。 例えば、「c=はリラックスしたこと」が同じように「c=は簡単な状態で/を弛緩した」として扱われます。
ABNF:
ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension
sig-c-タグ=%x63[FWS]「=」[FWS]sig-cタグalg[「/」sig-cタグalg]sig-cタグalgは「簡単である」か「伸びやかな」/x-sig-cタグalg x-sig-cタグalg=ハイフンでつないだ単語と等しいです。 後の拡大のために
d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid.
dは調印実体のドメインと等しいです(プレーンテキスト; REQUIRED)。 これは公開鍵のために質問されるドメインです。 このドメインは、同じであって、「i=」タグ(以下で説明されるとしての調印のアイデンティティ)の親ドメインであるに違いありませんかそれはセクション3.8で説明された親ドメイン調印のために条件を満たさなければなりません。 これらに会わない署名を与えるとき、要件、検証は、署名が無効であると考えなければなりません。
Allman, et al. Standards Track [Page 19] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[19ページ]。
Internationalized domain names MUST be encoded as described in
[RFC3490].
[RFC3490]で説明されるように国際化ドメイン名をコード化しなければなりません。
ABNF:
ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal
sig-d-タグ=%x64[FWS]が[FWS]ドメイン名ドメイン名=サブドメイン1*と「等しい」、(「. 」 サブドメイン、)、。 しかし、RFC2821Domain、除外によって、アドレス文字通りです。
h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields
do not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature
header field that is being created or verified, but may include
others. Folding whitespace (FWS) MAY be included on either side
of the colon separator. Header field names MUST be compared
against actual header field names in a case-insensitive manner.
This list MUST NOT be empty. See Section 5.4 for a discussion of
choosing header fields to sign.
h=がヘッダーフィールドにサインした、(記述を見るのを除いたプレーンテキスト、REQUIRED) 調印アルゴリズムに提示されたヘッダーフィールドを特定するヘッダーフィールド名のコロンで切り離されたリスト。 分野は調印アルゴリズムに提示されたオーダーにおけるヘッダーフィールドに関する全リストを含まなければなりません。 分野はサインされる場合存在しないヘッダーフィールドの名前を含むかもしれません。 実在しないヘッダーフィールドは署名計算に貢献しません(すなわち、それらがヌル入力として扱われます、ヘッダーフィールド名、分離コロン、ヘッダーフィールド値、およびどんなCRLFターミネータも含んでいて)。 分野は、作成されるか、または確かめられているDKIM-署名ヘッダーフィールドを含んではいけませんが、他のものを含むかもしれません。 折りたたみの空白(FWS)はコロン分離符のどちらの側にも含まれるかもしれません。 大文字と小文字を区別しない方法で実際のヘッダーフィールド名に対してヘッダーフィールド名をたとえなければなりません。 このリストは空であるはずがありません。 ヘッダーフィールドを選ぶ議論がサインするセクション5.4を見てください。
ABNF:
ABNF:
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name )
hdr-name = field-name
「sig-h-タグ=%x68[FWS]は[FWS]hdr名前0*(」 : 」 *がFWS hdr命名する*FWS)hdr-名前=フィールド名と「等しいです」。
INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those
header fields before verification. However, since a signer
cannot possibly know what header fields might be created in
the future, and that some MUAs might present header fields
that are embedded inside a message (e.g., as a message/rfc822
content type), the security of this solution is not total.
有益な説明: 実際に存在しないヘッダーフィールドが「サイン」であることによって、署名者は検証の前にそれらのヘッダーフィールドの挿入を防ぐことができます。 しかしながら、署名者が、ヘッダーフィールドが将来作成されたものであって、いくつかのMUAsがメッセージ(例えば、メッセージ/rfc822の満足しているタイプとしての)で埋め込まれているヘッダーフィールドを提示するかもしれないのを知ることができないので、この解決策のセキュリティは総はありません。
INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent
header fields prevents an attacker from inserting an actual
header field with a null value.
有益な説明: 実在しないヘッダーフィールドのためのヘッダーフィールド値と同様にヘッダーフィールド名とコロンの除外によって、攻撃者はヌル値で実際のヘッダーフィールドを挿入できません。
Allman, et al. Standards Track [Page 20] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[20ページ]。
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
私がユーザかエージェント(例えば、メーリングリストマネージャ)を代表してこのメッセージがサインされるアイデンティティと等しい、(dkimが引用した、印刷可能である、;、OPTIONAL、デフォルトがドメインが「d=」タグからあとに続いた"@"によっていうことになられた空のLocal-部分である ) 構文はLocal-部分が省略されるかもしれない標準のEメールアドレスです。 アドレスの部分が同じであるに違いないドメインか「d=」タグの値に関するサブドメイン。
Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function.
[RFC3490]のセクション4に"ToASCII"機能を使用することで記載されたステップを使用して、国際化ドメイン名を変換しなければなりません。
ABNF:
ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
sig-i-タグ=%x69[FWS]は[FWS][地方の部分]"@"ドメイン名と「等しいです」。
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may
wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit
to an individual user name within their domain. It can do so
by including the domain part but not the Local-part of the
identity.
有益な注意: 署名者がいくつかの場合確かめられた個々のアイデンティティを確立できないかもしれないので、「i=」タグのLocal-一部が任意です。 そのような場合、署名者は、それらのドメインの中の個々のユーザ名に公約するのが遠くにドメインの受取にサインするように進んでも構わないと思っていますが、不本意であると断言したがっているかもしれません。 それが、Local-部分ではなく、アイデンティティのドメイン部分を含んでいることによって、そうできます。
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.
有益な議論: このドキュメントは、どんなメッセージヘッダーフィールドでもアイデンティティを合わせるために「i=」タグの値を必要としません。 これは検証政策問題であると考えられます。 他のヘッダーフィールドにおける、「i=」タグと他のアイデンティティの値の間の規制は満足している作者などの役割に関連している信用の意味論に基本的な認証を適用しようとします。 信用は広くて複雑な話題です、そして、信用メカニズムは非常に創造的な攻撃を受けることがあります。 「i=」値と他のアイデンティティの間のいずれにもかかわらず、最も基本的な結合の本当の世界効力は確固としません、そして、攻撃者による転覆には脆弱性がありません。 したがって、これらのオプションの使用への信用は厳密に制限されるべきです。 特に、それが「i=」オプションのうまくいっている使用で典型的なエンドユーザ受取人が何か保証に依存できるというどんな範囲まで作られているかは、全く明確ではありません。
l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
default is entire body). This tag informs the verifier of the
number of octets in the body of the email after canonicalization
included in the cryptographic hash, starting from 0 immediately
following the CRLF preceding the body. This value MUST NOT be
larger than the actual number of octets in the canonicalized
message body.
lはボディー長さのカウントと等しいです(プレーンテキストの未署名の10進整数; OPTIONAL、デフォルトは全身です)。 暗号のハッシュにcanonicalizationを含んだ後にこのタグはメールのボディーの八重奏の数の検証を知らせます、すぐにボディーに先行するCRLFに続いて、0から始めて。 この値はcanonicalizedメッセージ本体の八重奏の実数より大きいはずがありません。
Allman, et al. Standards Track [Page 21] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[21ページ]。
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
allow display of fraudulent content without appropriate
warning to end users. The "l=" tag is intended for
increasing signature robustness when sending to mailing lists
that both modify their content and do not sign their
messages. However, using the "l=" tag enables attacks in
which an intermediary with malicious intent modifies a
message to include content that solely benefits the attacker.
It is possible for the appended content to completely replace
the original content in the end recipient's eyes and to
defeat duplicate message detection algorithms. Examples are
described in Security Considerations (Section 8). To avoid
this attack, signers should be extremely wary of using this
tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length.
有益な実装警告: 「l=」タグの使用は適切な警告なしで詐欺的な内容のディスプレイをエンドユーザに許容するかもしれません。 それらの内容を変更して、それらのメッセージに署名しないメーリングリストに発信するとき、「l=」タグは増加する署名丈夫さのために意図します。 しかしながら、「l=」タグを使用すると、仲介者が悪意で唯一攻撃者のためになる内容を含むメッセージを変更する攻撃は可能にされます。 追加された内容が終わりの受取人の目でオリジナルコンテンツを完全に置き換えて、写しメッセージ検出アルゴリズムを破るのは可能です。例はSecurity Considerations(セクション8)で説明されます。 この攻撃を避けるために、署名者がこのタグを使用するのに非常に用心深いはずであり、検証は、タグを無視したいか、または指定されたコンテンツの長さの後に現れるテキストを取り除きたがっているかもしれません。
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76
decimal digits. This constraint is not intended to predict
the size of future messages or to require implementations to
use an integer representation large enough to represent the
maximum possible value, but is intended to remind the
implementer to check the length of this and all other tags
during verification and to test for integer overflow when
decoding the value. Implementers may need to limit the
actual value expressed to a value smaller than 10^76, e.g.,
to allow a message to fit within the available storage space.
有益な注意: 「l=」タグの値は76の10進数字に抑制されます。 この規制は、将来のメッセージのサイズを予測するか、または最大の可能な値を表すことができるくらい大きい整数表現を使用するために実装を必要とすることを意図しませんが、検証の間、他のこれとすべてのタグの長さをチェックして、値を解読するときには整数オーバーフローがないかどうかテストするようにimplementerに思い出させることを意図します。 Implementersは10^76より小さい値に言い表された実価を制限して、例えば利用可能な集積スペースの中で合うメッセージを許容する必要があるかもしれません。
ABNF:
ABNF:
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT
sig lタグ=%x6c[FWS]は[FWS]1*76DIGITと「等しいです」。
q= A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns/txt"). Each
query method is of the form "type[/options]", where the syntax
and semantics of the options depend on the type and specified
options. If there are multiple query mechanisms listed, the
choice of query mechanism MUST NOT change the interpretation of
the signature. Implementations MUST use the recognized query
mechanisms in the order presented.
質問メソッドのコロンで切り離されたq=リストは以前はよく公開鍵を検索していました(; プレーンテキスト、OPTIONAL、デフォルトは"dns/txt"です)。 それぞれの質問メソッドはフォームでは、「[/オプション]をタイプしてください」、オプションの構文と意味論をタイプと指定されたオプションに頼っているところでことです。 複数の記載された質問メカニズムがあれば、質問メカニズムの選択は署名の解釈を変えてはいけません。 実装はオーダーにおけるメカニズムが提示した認識された質問を使用しなければなりません。
Currently, the only valid value is "dns/txt", which defines the DNS
TXT record lookup algorithm described elsewhere in this document.
The only option defined for the "dns" query type is "txt", which
MUST be included. Verifiers and signers MUST support "dns/txt".
現在、唯一の有効値がほかの場所で本書では説明されたDNS TXTの記録的なルックアップアルゴリズムを定義する"dns/txt"です。 "dns"質問タイプのために定義された唯一のオプションが含まなければならない"txt"です。 検証と署名者は"dns/txt"をサポートしなければなりません。
Allman, et al. Standards Track [Page 22] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[22ページ]。
ABNF:
ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value
「sig-q-タグ=%x71[FWS]は[FWS]sig-qタグメソッド*[FWS]と「等し」」: 」 [FWS]sig-qタグメソッド) x-sig-qタグ"dns/txt"/タイプ[「/」x-sig-qタグargs]x-sig-qタグsig-qタグメソッド=タイプはハイフンでつないだ単語と等しいです。 将来の拡大x-sig-qタグargs=qp-hdr-価値のために
s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED).
「d=」(ドメイン)タグ(プレーンテキスト; REQUIRED)のために名前空間を細分するs=セレクタ。
ABNF:
ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector
sig-s-タグ=%x73[FWS]は[FWS]セレクタと「等しいです」。
t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The
value is expressed as an unsigned integer in decimal ASCII. This
value is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at
least 10^12 (until approximately AD 200,000; this fits into 40
bits). To avoid denial-of-service attacks, implementations MAY
consider any value longer than 12 digits to be infinite. Leap
seconds are not counted. Implementations MAY ignore signatures
that have a timestamp in the future.
tは署名Timestampと等しいです(プレーンテキストの未署名の10進整数; RECOMMENDED、デフォルトは未知の作成時間です)。 この署名が作成された時間。 UTCの時間帯における1970年1月1日00:00:00以来形式は秒数です。 値は10進ASCIIにおける符号のない整数として言い表されます。 この値が31か32ビットの整数に収まるのが抑制されません。 実装SHOULD、値を少なくとも10^12まで扱うように用意してください(西暦20万年頃まで; これは40ビットに収まります)。 サービス不能攻撃を避けるために、実装は、12ケタより長いどんな値も無限であると考えるかもしれません。 飛躍秒は数えられません。 実装は将来タイムスタンプを持つ署名を無視するかもしれません。
ABNF:
ABNF:
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
sig tタグ=%x74[FWS]は[FWS]1*12DIGITと「等しいです」。
x= Signature Expiration (plain-text unsigned decimal integer;
RECOMMENDED, default is no expiration). The format is the same
as in the "t=" tag, represented as an absolute date, not as a
time delta from the signing timestamp. The value is expressed as
an unsigned integer in decimal ASCII, with the same constraints
on the value in the "t=" tag. Signatures MAY be considered
invalid if the verification time at the verifier is past the
expiration date. The verification time should be the time that
the message was first received at the administrative domain of
the verifier if that time is reliably available; otherwise the
current time should be used. The value of the "x=" tag MUST be
greater than the value of the "t=" tag if both are present.
xは署名Expirationと等しいです(プレーンテキストの未署名の10進整数; RECOMMENDED、デフォルトは満了ではありません)。 形式は、絶対期日として「t=」タグと同じで、署名タイムスタンプからの時間デルタとして表されるのではなく、表されます。 値は10進ASCIIにおける符号のない整数として言い表されます、同じ規制が「t=」タグの値にある状態で。 検証の検証時間が有効期限を過ぎているなら、署名は無効であると考えられるかもしれません。 検証時間はその時が確かに空くなら最初に検証の管理ドメインにメッセージを受け取った時間であるべきです。 さもなければ、現在の時間は使用されるべきです。 両方が存在しているなら、「x=」タグの値は「t=」タグの値より大きいに違いありません。
Allman, et al. Standards Track [Page 23] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[23ページ]。
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
defense.
有益な注意: 「x=」タグは反再生ディフェンスとして意図しません。
ABNF:
ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
sig-x-タグ=%x78[FWS]は[FWS]1*12DIGITと「等しいです」。
z= Copied header fields (dkim-quoted-printable, but see description;
OPTIONAL, default is null). A vertical-bar-separated list of
selected header fields present when the message was signed,
including both the field name and value. It is not required to
include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a
copied header field must be encoded). Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value. After encoding, FWS MAY be added at
arbitrary locations in order to avoid excessively long lines;
such whitespace is NOT part of the value of the header field, and
MUST be removed before decoding.
z=がヘッダーフィールドをコピーした、(dkimが引用した、印刷可能である、記述を見てください; OPTIONAL、デフォルトがヌルである、) メッセージであるときに、フィールド名と値の両方を含んでいて、現在の選択されたヘッダーフィールドの垂直なバーが分離しているリストは署名されました。 それは、署名時点の現在のすべてのヘッダーフィールドを含むのに必要ではありません。 この分野は「h=」タグに記載された同じヘッダーフィールドを含む必要はありません。 ヘッダーフィールドテキスト自体が縦棒をコード化しなければならない、(「|」、%x7C) キャラクタ(すなわち、「z=」テキストの縦棒はメタキャラクタです、そして、コピーされたヘッダーフィールドにおけるどんな実際の縦棒キャラクタもコード化しなければなりません)。 コロンとヘッダーフィールド値の間の空白を含んでいて、すべての空白をコード化しなければならないことに注意してください。 コード化、FWS MAYの後、過度に長い系列を避けるために任意の位置で加えられてください。 そのような空白をヘッダーフィールドの価値の一部でなく、解読する前に、取り除かなければなりません。
The header fields referenced by the "h=" tag refer to the fields in
the RFC 2822 header of the message, not to any copied fields in
the "z=" tag. Copied header field values are for diagnostic use.
「h=」タグによって参照をつけられるヘッダーフィールドは「z=」タグのどんなコピーされた分野ではなく、2822年のメッセージのRFCヘッダーの野原についても言及します。 コピーされたヘッダーフィールド値は診断使用のためのものです。
Header fields with characters requiring conversion (perhaps from
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted
as described in MIME Part Three [RFC2047].
MIME Part Three[RFC2047]のキャラクタ必要な変換(恐らく[RFC2822]対応でないレガシーMTAsからの)SHOULDが説明されるとして変換されているヘッダーフィールド。
ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
ABNF: 「sig-z-タグ=%x7A[FWS]は「」 [FWS]sig-zタグコピー*(「|」 [FWS]sig-zタグコピー)sig-zタグコピー=hdr-名と等しいです」」 qp-hdr-値のqp-hdr-値が等しい、dkimが引用した、印刷可能である、。 「」|「コード化されます」。
INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines:
署名ヘッダーフィールドのINFORMATIVE EXAMPLEは複数の継続行の向こう側に広まりました:
Allman, et al. Standards Track [Page 24] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[24ページ]。
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
DKIM-署名: a=rsa-sha256。 d=example.net。 s=brisbane。 c=簡単。 q=dns/txt。 iは@eng.example.netと等しいです。 t=1117574938。 x=1118006938。 : 以下から対象までのh=: デートしてください。 zはFrom: foo@eng.example.net と等しいです。|To: joe@example.com | Subject: デモ=20run|日付: 7月は205と等しく、= 午後の202005=203:44:08=20は20-0700と等しいです。 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=。 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR
3.6. Key Management and Representation
3.6. Key Managementと表現
Signature applications require some level of assurance that the verification public key is associated with the claimed signer. Many applications achieve this by using public key certificates issued by a trusted third party. However, DKIM can achieve a sufficient level of security, with significantly enhanced scalability, by simply having the verifier query the purported signer's DNS entry (or some security-equivalent) in order to retrieve the public key.
署名アプリケーションは検証公開鍵が要求された署名者に関連しているという何らかのレベルを保証を必要とします。 多くのアプリケーションが、信頼できる第三者機関によって発行された公開鍵証明書を使用することによって、これを実現します。 しかしながら、DKIMは十分なレベルのセキュリティを達成できます、かなり高められたスケーラビリティで、検証に公開鍵を検索するために、主張された署名者のDNSエントリー(または、何らかのセキュリティ同等物)について単に、質問させることによって。
DKIM keys can potentially be stored in multiple types of key servers and in multiple formats. The storage and format of keys are irrelevant to the remainder of the DKIM algorithm.
複数のタイプの主要なサーバと複数の形式で潜在的にDKIMキーを保存できます。 キーのストレージと形式はDKIMアルゴリズムの残りと無関係です。
Parameters to the key lookup algorithm are the type of the lookup (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- Signature header field), and the selector (the "s=" tag).
主要なルックアップアルゴリズムへのパラメタは、ルックアップのタイプ(「q=」タグ)と、署名者のドメイン(DKIM署名ヘッダーフィールドの「d=」タグ)と、セレクタ(「s=」タグ)です。
public_key = dkim_find_key(q_val, d_val, s_val)
公共の_主要な=dkim_掘り出し物_キー(__q val、_d val、s val)
This document defines a single binding, using DNS TXT records to distribute the keys. Other bindings may be defined in the future.
キーを分配するのにDNS TXT記録を使用して、このドキュメントはただ一つの結合を定義します。 他の結合は将来、定義されるかもしれません。
3.6.1. Textual Representation
3.6.1. 原文の表現
It is expected that many key servers will choose to present the keys in an otherwise unstructured text format (for example, an XML form would not be considered to be unstructured text for this purpose). The following definition MUST be used for any DKIM key represented in an otherwise unstructured textual form.
多くの主要なサーバが、そうでなければ、不統一なテキスト形式でキーを贈るのを選ぶ(例えば、XMLフォームはこのために不統一なテキストであると考えられない)と予想されます。 そうでなければ、不統一な原文のフォームに表されたどんなDKIMキーにも以下の定義を使用しなければなりません。
The overall syntax is a tag-list as described in Section 3.2. The current valid tags are described below. Other tags MAY be present and MUST be ignored by any implementation that does not understand them.
総合的な構文はセクション3.2で説明されるようにタグリストです。 現在の有効なタグは以下で説明されます。 他のタグを存在しているかもしれなくて、それらを理解していないどんな実装でも無視しなければなりません。
Allman, et al. Standards Track [Page 25] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[25ページ]。
v= Version of the DKIM key record (plain-text; RECOMMENDED, default
is "DKIM1"). If specified, this tag MUST be set to "DKIM1"
(without the quotes). This tag MUST be the first tag in the
record. Records beginning with a "v=" tag with any other value
MUST be discarded. Note that verifiers must do a string
comparison on this value; for example, "DKIM1" is not the same as
"DKIM1.0".
DKIMの主要な記録のv=バージョン、(; プレーンテキスト、RECOMMENDED、デフォルトがそうである、「DKIM1")」 指定されるなら、「DKIM1"(引用文のない)」にこのタグを設定しなければなりません。 このタグは記録で最初のタグであるに違いありません。 いかなる他の値がある「v=」タグでも始まる記録を捨てなければなりません。 検証がこの値でストリング比較をしなければならないことに注意してください。 例えば、「DKIM1"は"DKIM1.0""と同じではありません。
ABNF:
ABNF:
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1"
主要なvタグ=%x76[FWS]は[FWS]"DKIM1""と「等しいです」。
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a
key to a third party that should only be used for special
purposes. Wildcarding allows matching for addresses such as
"user+*" or "*-offer". An empty "g=" value never matches any
addresses.
gはキーの粒状と等しいです(; プレーンテキスト、OPTIONAL、デフォルトは「*」です)。 この値はDKIM署名ヘッダーフィールドの「i=」タグのLocal-一部に合わなければなりません(空のストリングのデフォルト値は「i=」であるなら指定されません)、単一の、そして、任意の「*」キャラクタがゼロか、より任意のキャラクタ(「wildcarding」)の系列に合っていて。 このタグの値に合っていない署名アドレスがあるメールは失敗した検証を構成します。 このタグの意図は特別な目的に使用されるだけであるべきである第三者のキーを代表として派遣するとき、例えば、どの署名アドレスを抑制するかが合法的にこのセレクタを使用できるということです。 「Wildcardingは、」 「ユーザ+*」か*申し出などのアドレスのために合っているのを許容します。」 空の「g=」値はどんなアドレスにも決して合っていません。
ABNF:
ABNF:
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
主要なgタグ=%x67[FWS]は[FWS]主要なgタグlpart主要なgタグlpart=[ドット原子テキスト]と「等しいです」。[「*」[ドット原子テキスト]]
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash
algorithms that might be used. Signers and Verifiers MUST
support the "sha256" hash algorithm. Verifiers MUST also support
the "sha1" hash algorithm.
hは許容できるハッシュアルゴリズム(プレーンテキスト; OPTIONAL、すべてのアルゴリズムを許容することへのデフォルト)と等しいです。 使用されるかもしれないハッシュアルゴリズムのコロンで切り離されたリスト。 署名者とVerifiersは"sha256"ハッシュアルゴリズムをサポートしなければなりません。 また、検証は「sha1"ハッシュアルゴリズム」をサポートしなければなりません。
ABNF:
ABNF:
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
0*( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word ; for future extension
「主要なhタグ=%x68[FWS]は[FWS]主要なhタグalg0*[FWS]と「等し」」: 」 [FWS]主要なhタグalg) 主要なhタグalg=「x主要なhタグalg x主要なhタグsha1"/"sha256"/algはハイフンでつないだ単語と等しいです」。 今後の拡大のために
Allman, et al. Standards Track [Page 26] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[26ページ]。
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey
[RFC3447] (see Sections 3.1 and A.1.1) is being used in the "p="
tag. (Note: the "p=" tag further encodes the value using the
base64 algorithm.)
kは主要なタイプと等しいです(; プレーンテキスト、OPTIONAL、デフォルトは"rsa"です)。 署名者と検証は、"rsa"が主要なタイプであるとサポートしなければなりません。 "rsa"主要なタイプは、ASN.1のDERによってコード化された[ITU.X660.1997]RSAPublicKey[RFC3447](セクション3.1とA.1.1を見る)が「p=」タグで使用されているのを示します。 (注意: 「p=」タグはbase64アルゴリズムを使用することで値をさらにコード化します。)
ABNF:
ABNF:
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension
主要なkタグ=%x76[FWS]はx主要なkタグ"rsa"/タイプのx主要なkタグ[FWS]主要なkタグタイプの主要なkタグタイプ=タイプ=ハイフンでつないだ単語と「等しいです」。 今後の拡大のために
n= Notes that might be of interest to a human (qp-section; OPTIONAL,
default is empty). No interpretation is made by any program.
This tag should be used sparingly in any key server mechanism
that has space limitations (notably DNS). This is intended for
use by administrators, not end users.
nは人間にとって、興味深いかもしれない雰囲気と等しいです(; qp-セクション、OPTIONAL、デフォルトは空です)。 どんなプログラムでも解釈を全くしません。 このタグは宇宙制限(著しくDNS)を持っているどんな主要なサーバメカニズムでも控えめに使用されるべきです。 これは使用のためにエンドユーザではなく、管理者によって意図されます。
ABNF:
ABNF:
key-n-tag = %x6e [FWS] "=" [FWS] qp-section
主要なnタグ=%x6e[FWS]は[FWS]qp-セクションと「等しいです」。
p= Public-key data (base64; REQUIRED). An empty value means that
this public key has been revoked. The syntax and semantics of
this tag value before being encoded in base64 are defined by the
"k=" tag.
pは公開鍵データと等しいです(base64; REQUIRED)。 空の値は、この公開鍵が取り消されたことを意味します。 base64でコード化される前のこのタグ価値の構文と意味論は「k=」タグによって定義されます。
INFORMATIVE RATIONALE: If a private key has been compromised
or otherwise disabled (e.g., an outsourcing contract has been
terminated), a signer might want to explicitly state that it
knows about the selector, but all messages using that
selector should fail verification. Verifiers should ignore
any DKIM-Signature header fields with a selector referencing
a revoked key.
有益な原理: 秘密鍵が感染されるか、または別の方法で無効にされたなら(例えばアウトソーシング契約は終えられました)、署名者は、それがセレクタに関して知っていると明らかに述べたがっているかもしれませんが、そのセレクタを使用するすべてのメッセージが検証に失敗するべきです。 検証はセレクタが取り消されたキーに参照をつけているどんなDKIM-署名ヘッダーフィールドも無視するはずです。
ABNF:
ABNF:
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ]
主要なpタグ=%x70[FWS]「=」[[FWS]base64string]
INFORMATIVE NOTE: A base64string is permitted to include white
space (FWS) at arbitrary places; however, any CRLFs must be
followed by at least one WSP character. Implementors and
administrators are cautioned to ensure that selector TXT
records conform to this specification.
有益な注意: base64stringが任意の場所に余白(FWS)を含んでいることが許可されています。 しかしながら、少なくとも1つのWSPキャラクタがどんなCRLFsも後をつけなければなりません。 作成者と管理者が、セレクタTXT記録がこの仕様に従うのを保証すると警告されます。
Allman, et al. Standards Track [Page 27] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[27ページ]。
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon-
separated list of service types to which this record applies.
Verifiers for a given service type MUST ignore this record if the
appropriate type is not listed. Currently defined service types
are as follows:
sはサービスTypeと等しいです(プレーンテキスト; OPTIONAL; デフォルトは「*」です)。 この記録が申請されるサービスのコロン切り離されたリストはタイプされます。 適切なタイプが記載されていないなら、与えられたサービスタイプのための検証はこの記録を無視しなければなりません。 現在定義されたサービスタイプは以下の通りです:
* matches all service types
* すべてのサービスタイプを合わせます。
email electronic mail (not necessarily limited to SMTP)
メール電子メール(必ずSMTPに制限されるというわけではありません)
This tag is intended to constrain the use of keys for other
purposes, should use of DKIM be defined by other services in the
future.
このタグがキーの他の目的の使用を抑制することを意図します、DKIMの使用が将来他のサービスで定義されるなら。
ABNF:
ABNF:
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type
0*( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word ; for future extension
「主要なsタグ=%x73[FWS]は[FWS]キーズsタグタイプ0*[FWS]と「等し」」: 」 [FWS]主要なsタグタイプ) x主要なsタグ「メール」/「*」/タイプのx主要なsタグ主要なsタグタイプ=タイプはハイフンでつないだ単語と等しいです。 今後の拡大のために
t= Flags, represented as a colon-separated list of names (plain-
text; OPTIONAL, default is no flags set). The defined flags are
as follows:
tはコロンで切り離された名簿として表された旗と等しいです(明瞭なテキスト; OPTIONAL、デフォルトは設定されなかった旗です全く)。 定義された旗は以下の通りです:
y This domain is testing DKIM. Verifiers MUST NOT treat
messages from signers in testing mode differently from
unsigned email, even should the signature fail to verify.
Verifiers MAY wish to track testing mode results to assist
the signer.
y、このドメインはDKIMをテストしています。 検証は中の署名が確かめないモードを未署名のメールと異なってテストさえするそうするべきである署名者からメッセージを扱ってはいけません。 署名者を補助するためにモード結果をテストして、検証は追跡したがっているかもしれません。
s Any DKIM-Signature header fields using the "i=" tag MUST have
the same domain value on the right-hand side of the "@" in
the "i=" tag and the value of the "d=" tag. That is, the
"i=" domain MUST NOT be a subdomain of "d=". Use of this
flag is RECOMMENDED unless subdomaining is required.
s「i=」を使用するどんなDKIM-署名ヘッダーフィールドタグも"@"の右側に「i=」タグと「d=」タグの値で同じドメイン値を持たなければなりません。 すなわち、「i=」ドメインは「d=」に関するサブドメインであるはずがありません。 subdomainingは必要でない場合、この旗の使用がRECOMMENDEDです。
ABNF:
ABNF:
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag
0*( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word ; for future extension
「主要なtタグ=%x74[FWS]は[FWS]主要なtタグ旗の0*[FWS]と「等し」」: 」 [FWS]主要なtタグ旗) 主要なtタグ旗=x主要なtタグ「y」/「s」/旗x主要なtタグ旗=ハイフンでつないだ単語。 今後の拡大のために
Unrecognized flags MUST be ignored.
認識されていない旗を無視しなければなりません。
Allman, et al. Standards Track [Page 28] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[28ページ]。
3.6.2. DNS Binding
3.6.2. DNS結合
A binding using DNS TXT records as a key service is hereby defined. All implementations MUST support this binding.
主要なサービスとしてDNS TXT記録を使用する結合はこれにより定義されます。 すべての実装がこの結合をサポートしなければなりません。
3.6.2.1. Namespace
3.6.2.1. 名前空間
All DKIM keys are stored in a subdomain named "_domainkey". Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com".
「すべてのDKIMキーが」 _domainkeyというサブドメインに保存されます。」 "example.com"の「d=」タグと"foo.bar"の「s=」タグがあるDKIM-署名分野を考えて、DNS質問は「foo.bar_domainkey.example.com」のためにものになるでしょう。
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
*.bar._domainkey.example.com) do not make sense in this context
and should not be used. Note also that wildcards within domains
(e.g., s._domainkey.*.example.com) are not supported by the DNS.
有益な操作上の注意: ワイルドカードDNS記録(例えば、*.bar._domainkey.example.com)はこのような関係においては理解できないで、使用するべきではありません。 また、ドメイン(s._domainkey例えば、*.example.com)の中のワイルドカードがDNSによって支えられないことに注意してください。
3.6.2.2. Resource Record Types for Key Storage
3.6.2.2. 主要なストレージのためのリソースレコード種類
The DNS Resource Record type used is specified by an option to the
query-type ("q=") tag. The only option defined in this base
specification is "txt", indicating the use of a TXT Resource Record
(RR). A later extension of this standard may define another RR type.
タイプが使用したDNS Resource Recordは質問タイプ(「q=」)タグへのオプションで指定されます。 TXT Resource Record(RR)の使用を示して、この基礎仕様に基づき定義された唯一のオプションが"txt"です。 この規格の後の拡大は別のRRタイプを定義するかもしれません。
Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.
ストリング、TXT RR MUSTでは、使用の前に介入している空白なしで一緒に連結されてください。 特定のセレクタ名に、TXT RRsはユニークであるに違いありません。 すなわち、複数の記録がRRsetにあれば、結果は未定義です。
TXT RRs are encoded as described in Section 3.6.1.
TXT RRsはセクション3.6.1で説明されるようにコード化されます。
3.7. Computing the Message Hashes
3.7. メッセージハッシュを計算します。
Both signing and verifying message signatures start with a step of computing two cryptographic hashes over the message. Signers will choose the parameters of the signature as described in Signer Actions (Section 5); verifiers will use the parameters specified in the DKIM- Signature header field being verified. In the following discussion, the names of the tags in the DKIM-Signature header field that either exists (when verifying) or will be created (when signing) are used. Note that canonicalization (Section 3.4) is only used to prepare the email for signing or verifying; it does not affect the transmitted email in any way.
ともに、メッセージ署名に署名して、確かめると、メッセージに関して2つの暗号のハッシュを計算するステップ始まられます。 署名者はSigner Actions(セクション5)で説明されるように署名のパラメタを選ぶでしょう。 検証は確かめられるDKIM署名ヘッダーフィールドで指定されたパラメタを使用するでしょう。 存在しているか(確かめるとき)、または作成される(署名するとき)DKIM-署名ヘッダーフィールドにおけるタグの名前は以下の議論が使用されています。 canonicalization(セクション3.4)が署名か検証のためにメールを準備するのに使用されるだけであることに注意してください。 それは何らかの方法で伝えられたメールに影響しません。
The signer/verifier MUST compute two hashes, one over the body of the message and one over the selected header fields of the message.
署名者/検証は2つのハッシュ、メッセージ欄の上の1、およびメッセージの選択されたヘッダーフィールドの上の1つを計算しなければなりません。
Allman, et al. Standards Track [Page 29] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[29ページ]。
Signers MUST compute them in the order shown. Verifiers MAY compute them in any order convenient to the verifier, provided that the result is semantically identical to the semantics that would be the case had they been computed in this order.
署名者は示されたオーダーでそれらを計算しなければなりません。 検証は検証に便利などんなオーダーでもそれらを計算するかもしれません、結果がこの順でそれらを計算してあったならケースである意味論と意味的に同じであれば。
In hash step 1, the signer/verifier MUST hash the message body, canonicalized using the body canonicalization algorithm specified in the "c=" tag and then truncated to the length specified in the "l=" tag. That hash value is then converted to base64 form and inserted into (signers) or compared to (verifiers) the "bh=" tag of the DKIM- Signature header field.
ハッシュステップ1では、署名者/検証は「c=」タグで指定されて、次に「l=」タグで指定された長さに先端を切られたボディーcanonicalizationアルゴリズムを使用することでcanonicalizedされたメッセージ本体を論じ尽くさなければなりません。 そのハッシュ値は、DKIM署名ヘッダーフィールドの(検証)「bh=」タグと次に、base64フォームに変換されて、(署名者)に挿入されるか、または比較されます。
In hash step 2, the signer/verifier MUST pass the following to the hash algorithm in the indicated order.
ハッシュステップ2では、署名者/検証は追って指示する注文のハッシュアルゴリズムに以下を通過しなければなりません。
1. The header fields specified by the "h=" tag, in the order
specified in that tag, and canonicalized using the header
canonicalization algorithm specified in the "c=" tag. Each
header field MUST be terminated with a single CRLF.
1. ヘッダーフィールドは「h=」タグで指定しました、そのタグで指定されて、「c=」タグで指定されたヘッダーcanonicalizationアルゴリズムを使用することでcanonicalizedされたオーダーで。 独身のCRLFと共に各ヘッダーフィールドを終えなければなりません。
2. The DKIM-Signature header field that exists (verifying) or will
be inserted (signing) in the message, with the value of the "b="
tag deleted (i.e., treated as the empty string), canonicalized
using the header canonicalization algorithm specified in the "c="
tag, and without a trailing CRLF.
2. 存在しているか(確かめます)、または「b=」タグの値が削除されている状態で(すなわち、空のストリングとして扱われます)メッセージに挿入される(署名します)DKIM-署名ヘッダーフィールドは、「c=」タグと、引きずっているCRLFなしで指定されたヘッダーcanonicalizationアルゴリズムを使用することでcanonicalizedされました。
All tags and their values in the DKIM-Signature header field are included in the cryptographic hash with the sole exception of the value portion of the "b=" (signature) tag, which MUST be treated as the null string. All tags MUST be included even if they might not be understood by the verifier. The header field MUST be presented to the hash algorithm after the body of the message rather than with the rest of the header fields and MUST be canonicalized as specified in the "c=" (canonicalization) tag. The DKIM-Signature header field MUST NOT be included in its own h= tag, although other DKIM-Signature header fields MAY be signed (see Section 4).
DKIM-署名ヘッダーフィールドにおけるすべてのタグとそれらの値は暗号のハッシュにヌルストリングとして扱わなければならない「b=」(署名)タグの値の一部の唯一の例外で含まれています。 それらが検証に解釈されないかもしれなくても、すべてのタグを含まなければなりません。 ヘッダーフィールドとして、ヘッダーフィールドの残りでというよりむしろメッセージ欄の後のハッシュアルゴリズムに提示しなければならなくて、「c=」(canonicalization)タグで指定されていた状態でcanonicalizedしなければなりません。 それ自身のh=タグにDKIM-署名ヘッダーフィールドを含んではいけません、他のDKIM-署名ヘッダーフィールドは署名されるかもしれませんが(セクション4を見てください)。
When calculating the hash on messages that will be transmitted using base64 or quoted-printable encoding, signers MUST compute the hash after the encoding. Likewise, the verifier MUST incorporate the values into the hash before decoding the base64 or quoted-printable text. However, the hash MUST be computed before transport level encodings such as SMTP "dot-stuffing" (the modification of lines beginning with a "." to avoid confusion with the SMTP end-of-message marker, as specified in [RFC2821]).
base64か引用されて印刷可能なコード化を使用することで送られるメッセージでハッシュについて計算するとき、署名者はコード化の後にハッシュを計算しなければなりません。 同様に、base64か引用されて印刷可能なテキストを解読する前に、検証は値をハッシュに組み入れなければなりません。 しかしながら、「ドットを詰めるのである」というSMTPなどの輸送レベルencodingsの前でハッシュを計算しなければなりません。「(a」で始まる系列の変更、」 [RFC2821)で指定されるようにSMTPメッセージのエンドマーカーへの混乱を避けるために。
With the exception of the canonicalization procedure described in Section 3.4, the DKIM signing process treats the body of messages as
セクション3.4で説明されたcanonicalization手順、サインアップ過程がメッセージを遺体を処理するDKIMを除いて
Allman, et al. Standards Track [Page 30] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[30ページ]。
simply a string of octets. DKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content. Message attachments in MIME format MUST be included in the content that is signed.
単に一連の八重奏。 プレーンテキストかMIME形式にはDKIMメッセージがあるかもしれません。 どんな特別な処理もMIME内容に与えません。 署名される内容にMIME形式におけるメッセージ付属を含まなければなりません。
More formally, the algorithm for the signature is as follows:
body-hash = hash-alg(canon_body)
header-hash = hash-alg(canon_header || DKIM-SIG)
signature = sig-alg(header-hash, key)
より正式に、署名のためのアルゴリズムは以下の通りです: ボディーハッシュ=ハッシュ-alg(教会法_ボディー)ヘッダーハッシュ=ハッシュ-alg(教会法_ヘッダー| | DKIM-SIG)署名=sig-alg(ヘッダーハッシュ、キー)
where "sig-alg" is the signature algorithm specified by the "a=" tag, "hash-alg" is the hash algorithm specified by the "a=" tag, "canon_header" and "canon_body" are the canonicalized message header and body (respectively) as defined in Section 3.4 (excluding the DKIM-Signature header field), and "DKIM-SIG" is the canonicalized DKIM-Signature header field sans the signature value itself, but with "body-hash" included as the "bh=" tag.
"sig-alg"が署名であるところでは、アルゴリズムは「=」タグ、「=」タグ、「教会法_ヘッダー」、および「教会法_ボディー」によって指定されたハッシュアルゴリズムがセクション3.4(DKIM-署名ヘッダーフィールドを除いた)で定義されるようにcanonicalizedメッセージヘッダーとボディー(それぞれ)であり、「DKIM-SIG」が署名値自体がなければcanonicalized DKIM-署名ヘッダーフィールドであるということですが、「bh=」として「ボディーハッシュ」で含まれていた「ハッシュ-alg」タグで指定しました。
INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs
provide both hashing and application of the RSA private key using
a single "sign()" primitive. When using such an API, the last two
steps in the algorithm would probably be combined into a single
call that would perform both the "hash-alg" and the "sig-alg".
有益なIMPLEMENTERSの注意: 多くのデジタル署名APIが、原始的に単一の「サイン()」を使用することで論じ尽くすのとRSA秘密鍵のアプリケーションの両方を提供します。 そのようなAPIを使用するとき、アルゴリズムにおける最後の2ステップはたぶん「ハッシュ-alg」と"sig-alg"の両方を実行するただ一つの呼び出しに結合されるでしょう。
3.8. Signing by Parent Domains
3.8. 親ドメインのそばで署名します。
In some circumstances, it is desirable for a domain to apply a
signature on behalf of any of its subdomains without the need to
maintain separate selectors (key records) in each subdomain. By
default, private keys corresponding to key records can be used to
sign messages for any subdomain of the domain in which they reside;
e.g., a key record for the domain example.com can be used to verify
messages where the signing identity ("i=" tag of the signature) is
sub.example.com, or even sub1.sub2.example.com. In order to limit
the capability of such keys when this is not intended, the "s" flag
may be set in the "t=" tag of the key record to constrain the
validity of the record to exactly the domain of the signing identity.
If the referenced key record contains the "s" flag as part of the
"t=" tag, the domain of the signing identity ("i=" flag) MUST be the
same as that of the d= domain. If this flag is absent, the domain of
the signing identity MUST be the same as, or a subdomain of, the d=
domain. Key records that are not intended for use with subdomains
SHOULD specify the "s" flag in the "t=" tag.
いくつかの事情では、ドメインが各サブドメインで別々のセレクタ(主要な記録)を維持する必要性のないサブドメインのどれかを代表して署名を適用するのは、望ましいです。 デフォルトで、それらが住んでいるドメインに関するどんなサブドメインへのメッセージにもサインするのに主要な記録に対応する秘密鍵を使用できます。 調印のアイデンティティ(署名の「i=」タグ)がsub.example.com、またはsub1.sub2.example.comでさえあるメッセージについて確かめるのに例えばドメインexample.comに、主要な記録を使用できます。 これが意図しないとき、そのようなキーの能力を制限するために、「s」旗はまさに調印のアイデンティティのドメインに記録の正当性を抑制する主要な記録の「t=」タグのセットであるかもしれません。 参照をつけられた主要な記録が「t=」タグの一部として「s」旗を含んでいるなら、調印のアイデンティティ(「i=」旗)のドメインはd=ドメインのものと同じであるに違いありません。 この旗が欠けているか、そして、アイデンティティが同じであるに違いない調印のドメイン、またはサブドメイン、dはドメインと等しいです。 サブドメインSHOULDとの使用のために意図しない主要な記録は「t=」タグで「s」旗を指定します。
Allman, et al. Standards Track [Page 31] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[31ページ]。
4. Semantics of Multiple Signatures
4. 複数の署名の意味論
4.1. Example Scenarios
4.1. 例のシナリオ
There are many reasons why a message might have multiple signatures. For example, a given signer might sign multiple times, perhaps with different hashing or signing algorithms during a transition phase.
メッセージには複数の署名があるかもしれない多くの理由があります。 例えば、与えられた署名者は過渡期の間、恐らく、異なった論じ尽くすかアルゴリズムにサインするのに複数の回にサインするかもしれません。
INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be
insufficiently strong, and DKIM usage transitions to SHA-1024. A
signer might immediately sign using the newer algorithm, but
continue to sign using the older algorithm for interoperability
with verifiers that had not yet upgraded. The signer would do
this by adding two DKIM-Signature header fields, one using each
algorithm. Older verifiers that did not recognize SHA-1024 as an
acceptable algorithm would skip that signature and use the older
algorithm; newer verifiers could use either signature at their
option, and all other things being equal might not even attempt to
verify the other signature.
有益な例: SHA-1024への不十分に強い、そして、DKIM用法変遷になるようにSHA-256が将来見つけられると仮定してください。 より新しいアルゴリズムを使用することで署名者はすぐに、サインするかもしれませんが、相互運用性のための、より古いアルゴリズムを使用するのをまだアップグレードしていなかった検証を契約し続けてください。 2つのDKIM-署名ヘッダーフィールドを加えるある使用に署名者は各アルゴリズムをするでしょう。 SHA-1024が許容できるアルゴリズムであると認めなかったより古い検証が、その署名をサボって、より古いアルゴリズムを使用するでしょう。 より新しい検証は彼らの選択のときにどちらの署名も使用するかもしれません、そして、他のすべての等しいものはもう片方の署名について確かめるのを試みてさえいないかもしれません。
Similarly, a signer might sign a message including all headers and no "l=" tag (to satisfy strict verifiers) and a second time with a limited set of headers and an "l=" tag (in anticipation of possible message modifications in route to other verifiers). Verifiers could then choose which signature they preferred.
同様に、署名者はもう一度限られたセットのヘッダーと「l=」タグ(他の検証へのルートによる可能なメッセージ変更を予測した)でヘッダーにもかかわらず、すべての「l=」タグ(厳しい検証を満たす)を含むというわけではないメッセージにサインするかもしれません。 そして、検証は、彼らがどの署名を好んだかを選ぶかもしれません。
INFORMATIVE EXAMPLE: A verifier might receive a message with two
signatures, one covering more of the message than the other. If
the signature covering more of the message verified, then the
verifier could make one set of policy decisions; if that signature
failed but the signature covering less of the message verified,
the verifier might make a different set of policy decisions.
有益な例: 検証はもう片方より2つの署名、メッセージのもうひとつの覆いでメッセージを受け取るかもしれません。 確かめられた一層のメッセージをカバーする署名であるなら、検証は1セットの政策決定をするかもしれません。 その署名が失敗したか、しかし、メッセージの以下が確かめた署名覆い、検証は異なった政策決定をするかもしれません。
Of course, a message might also have multiple signatures because it passed through multiple signers. A common case is expected to be that of a signed message that passes through a mailing list that also signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources.
もちろん、また、複数の署名者を通り抜けたので、メッセージには複数の署名があるかもしれません。 よくある例はまた、すべてのメッセージにサインするメーリングリストを通り抜けるサインされたメッセージのものであると予想されます。 それらの署名の両方が確かめる仮定、それらの署名のどちらかが信頼できるソースから来るのが知られているなら、受取人はメッセージを受け入れるのを選ぶでしょうに。
INFORMATIVE EXAMPLE: Recipients might choose to whitelist mailing
lists to which they have subscribed and that have acceptable anti-
abuse policies so as to accept messages sent to that list even
from unknown authors. They might also subscribe to less trusted
mailing lists (e.g., those without anti-abuse protection) and be
willing to accept all messages from specific authors, but insist
on doing additional abuse scanning for other messages.
有益な例: 受取人は、未知の作者からさえそのリストに送られたメッセージを受け入れるためにそれらが申し込んで、許容できる反乱用方針を持っているwhitelistメーリングリストに選ぶかもしれません。 彼らは、また、それほど信じられなかったメーリングリスト(例えば、反乱用保護のないそれら)に加入して、特定の作者からすべてのメッセージを受け入れても構わないと思っているかもしれませんが、他のメッセージのためにスキャンされる追加乱用をすると主張してください。
Allman, et al. Standards Track [Page 32] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[32ページ]。
Another related example of multiple signers might be forwarding services, such as those commonly associated with academic alumni sites.
複数の署名者の別の関連する例は一般的にアカデミックな同窓生サイトに関連づけられたものなどの転送サービスであるかもしれません。
INFORMATIVE EXAMPLE: A recipient might have an address at
members.example.org, a site that has anti-abuse protection that is
somewhat less effective than the recipient would prefer. Such a
recipient might have specific authors whose messages would be
trusted absolutely, but messages from unknown authors that had
passed the forwarder's scrutiny would have only medium trust.
有益な例: 受取人はmembers.example.org(受取人が好むだろうよりいくらか効果的でない反乱用保護を持っているサイト)にアドレスを持っているかもしれません。 そのような受取人には、メッセージが絶対に信じられる特定の作者がいるかもしれませんが、混載業者の精査を通過した未知の作者からのメッセージでは、中型の信用しかないでしょう。
4.2. Interpretation
4.2. 解釈
A signer that is adding a signature to a message merely creates a new DKIM-Signature header, using the usual semantics of the h= option. A signer MAY sign previously existing DKIM-Signature header fields using the method described in Section 5.4 to sign trace header fields.
署名をメッセージに追加している署名者は単に新しいDKIM-署名ヘッダーを創造します、h=オプションの普通の意味論を使用して。 署名者は、以前に、跡のヘッダーフィールドにサインするようにセクション5.4で説明された方法を使用する既存のDKIM-署名ヘッダーフィールドにサインするかもしれません。
INFORMATIVE NOTE: Signers should be cognizant that signing DKIM-
Signature header fields may result in signature failures with
intermediaries that do not recognize that DKIM-Signature header
fields are trace header fields and unwittingly reorder them, thus
breaking such signatures. For this reason, signing existing DKIM-
Signature header fields is unadvised, albeit legal.
有益な注意: 署名者による認識力があるそんなにサインされているDKIM署名ヘッダーフィールドがDKIM-署名ヘッダーフィールドが跡のヘッダーフィールドであると認めない仲介者がいる署名失敗と知らず知らず結果として生じるかもしれないということであるはずである、追加注文、その結果、それら、壊れているそのような署名。 この理由で、既存のDKIM署名ヘッダーフィールドにサインするのは、軽率であって、それにしても、法的です。
INFORMATIVE NOTE: If a header field with multiple instances is
signed, those header fields are always signed from the bottom up.
Thus, it is not possible to sign only specific DKIM-Signature
header fields. For example, if the message being signed already
contains three DKIM-Signature header fields A, B, and C, it is
possible to sign all of them, B and C only, or C only, but not A
only, B only, A and B only, or A and C only.
有益な注意: 複数の例があるヘッダーフィールドがサインされるなら、それらのヘッダーフィールドはいつも下からサインされます。 したがって、特定のDKIM-署名ヘッダーフィールドだけにサインするのは可能ではありません。 サインされるメッセージが既に3つのDKIM-署名ヘッダーフィールドA、Bを含んでいるか、そして、C、例えば、AだけかBだけかAとBだけか、AとCだけではなく、それらかBとCだけか、Cだけにサインするのは可能です。
A signer MAY add more than one DKIM-Signature header field using different parameters. For example, during a transition period a signer might want to produce signatures using two different hash algorithms.
異なったパラメタを使用して、署名者は1つ以上のDKIM-署名ヘッダーフィールドを加えるかもしれません。 例えば、過渡期の間、署名者は、2つの異なった細切れ肉料理アルゴリズムを使用することで署名を起こしたがっているかもしれません。
Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified.
署名者SHOULD NOTはそれらがサインしているメッセージからどんなDKIM-署名ヘッダーフィールドも取り除きます、署名について確かめることができないのを知っても。
When evaluating a message with multiple signatures, a verifier SHOULD evaluate signatures independently and on their own merits. For example, a verifier that by policy chooses not to accept signatures with deprecated cryptographic algorithms would consider such signatures invalid. Verifiers MAY process signatures in any order of
倍数でメッセージを評価するとき、署名、検証SHOULDは独自に実力で署名を評価します。 例えば、推奨しない暗号アルゴリズムで署名を受け入れないのを方針で選ぶ検証は、そのような署名が無効であると考えるでしょう。 いずれの署名が注文する検証5月の過程
Allman, et al. Standards Track [Page 33] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[33ページ]。
their choice; for example, some verifiers might choose to process signatures corresponding to the From field in the message header before other signatures. See Section 6.1 for more information about signature choices.
彼らの選択。 例えば、いくつかの検証が、他の署名の前にメッセージヘッダーのFrom分野に対応する署名を処理するのを選ぶかもしれません。 署名選択に関する詳しい情報に関してセクション6.1を見てください。
INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate
valid signatures with invalid signatures in an attempt to guess
why a signature failed are ill-advised. In particular, there is
no general way that a verifier can determine that an invalid
signature was ever valid.
有益な実現注意: 署名がなぜ失敗したかを推測する試みにおける無効の署名で有効な署名を関連させる検証試みはあさはかです。 特に、検証が無効の署名がかつて有効であったことを決定できるどんな一般的な方法もありません。
Verifiers SHOULD ignore failed signatures as though they were not present in the message. Verifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the verifier. To limit potential denial-of-service attacks, verifiers MAY limit the total number of signatures they will attempt to verify.
まるでそれらがメッセージに存在していないかのように検証SHOULDは失敗した署名を無視します。 検証SHOULDは署名までの署名が首尾よく検証の満足に確かめるチェックに続きます。 潜在的サービス不能攻撃を制限するために、検証はそれらが確かめるのを試みる署名の総数を制限するかもしれません。
5. Signer Actions
5. 署名者動作
The following steps are performed in order by signers.
以下のステップは署名者によって整然とした状態で実行されます。
5.1. Determine Whether the Email Should Be Signed and by Whom
5.1. メールがサインされるべきであるかどうか決定して、だれ
A signer can obviously only sign email for domains for which it has a private key and the necessary knowledge of the corresponding public key and selector information. However, there are a number of other reasons beyond the lack of a private key why a signer could choose not to sign an email.
署名者は明らかにそれが秘密鍵を持っているドメインのためのメールと対応する公開鍵とセレクタ情報に関する必要な知識に調印できるだけです。 しかしながら、秘密鍵の不足を超えた署名者がメールにサインしないのを選ぶことができた他の多くの理由があります。
INFORMATIVE NOTE: Signing modules may be incorporated into any
portion of the mail system as deemed appropriate, including an
MUA, a SUBMISSION server, or an MTA. Wherever implemented,
signers should beware of signing (and thereby asserting
responsibility for) messages that may be problematic. In
particular, within a trusted enclave the signing address might be
derived from the header according to local policy; SUBMISSION
servers might only sign messages from users that are properly
authenticated and authorized.
有益な注意: 適切であると考えられるようにモジュールにサインするのはメールシステムのどんな部分にも組み入れられるかもしれません、MUA、SUBMISSIONサーバ、またはMTAを含んでいて。 そして、どこでも、実行されているところでは、署名者が調印に注意するはずである、(その結果、責任について断言する、)、問題が多いかもしれないメッセージ。 ローカルの方針に応じて、信じられた飛び地の中では、特に、ヘッダーから調印アドレスを得るかもしれません。 SUBMISSIONサーバは適切に認証されて、権限を与えられるユーザからのメッセージにサインするだけであるかもしれません。
INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign
Received header fields if the outgoing gateway MTA obfuscates
Received header fields, for example, to hide the details of
internal topology.
有益なIMPLEMENTERアドバイス: 例えば、出発しているゲートウェイMTAが内部のトポロジーの詳細を隠すためにReceivedヘッダーフィールドを困惑させるなら、SUBMISSIONサーバはReceivedヘッダーフィールドにサインするべきではありません。
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email.
ある理由でメールにサインできないなら、メールするのは、処理するべきことに関するローカルの政策決定です。
Allman, et al. Standards Track [Page 34] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[34ページ]。
5.2. Select a Private Key and Corresponding Selector Information
5.2. 秘密鍵と対応するセレクタ情報を選択してください。
This specification does not define the basis by which a signer should choose which private key and selector information to use. Currently, all selectors are equal as far as this specification is concerned, so the decision should largely be a matter of administrative convenience. Distribution and management of private keys is also outside the scope of this document.
この仕様は署名者がどの秘密鍵とセレクタ情報を使用したらよいかを選ぶはずである基礎を定義しません。 現在この仕様に関する限り、すべてのセレクタが等しいので、決定は主に管理便利の問題であるべきです。 このドキュメントの範囲の外にも秘密鍵の分配と管理があります。
INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a
private key when the selector containing the corresponding public
key is expected to be revoked or removed before the verifier has
an opportunity to validate the signature. The signer should
anticipate that verifiers may choose to defer validation, perhaps
until the message is actually read by the final recipient. In
particular, when rotating to a new key pair, signing should
immediately commence with the new private key and the old public
key should be retained for a reasonable validation interval before
being removed from the key server.
有益な操作アドバイス: 対応する公開鍵を含むセレクタが検証に署名を有効にする機会がある前に、取り消されるか、または取り除かれると予想されるとき、署名者は秘密鍵と契約するはずがありません。 署名者は、検証が、合法化を延期するのを選ぶかもしれないと予期するはずです、恐らくメッセージが実際に最終的な受取人によって読まれるまで。 すぐに新しい主要な組に回転するとき、特に、調印は新しい秘密鍵と共に始まるべきです、そして、主要なサーバから取り除く前に妥当な合法化間隔の間、古い公開鍵を保有するべきです。
5.3. Normalize the Message to Prevent Transport Conversions
5.3. 輸送変換を防ぐメッセージを正常にしてください。
Some messages, particularly those using 8-bit characters, are subject to modification during transit, notably conversion to 7-bit form. Such conversions will break DKIM signatures. In order to minimize the chances of such breakage, signers SHOULD convert the message to a suitable MIME content transfer encoding such as quoted-printable or base64 as described in MIME Part One [RFC2045] before signing. Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm.
いくつかのメッセージ(特に8ビットのキャラクタを使用するもの)がトランジット、著しく7ビットのフォームへの変換の間、変更を受けることがあります。 そのような変換はDKIM署名を壊すでしょう。 そのような折損の機会を最小にするために、署名者SHOULDは調印の前にMIME Part One[RFC2045]で説明されるように引用されて印刷可能であるとしてそのようなものをコード化するMIMEの適当な内容転送かbase64にメッセージを変換します。 DKIMの範囲の外にそのような変換はあります。 実際はSHOULDを通信させます。DKIMアルゴリズムへのプレゼンテーションの前にMUAかMSAによって7ビットのMIMEに変換されます。
If the message is submitted to the signer with any local encoding that will be modified before transmission, that modification to canonical [RFC2822] form MUST be done before signing. In particular, bare CR or LF characters (used by some systems as a local line separator convention) MUST be converted to the SMTP-standard CRLF sequence before the message is signed. Any conversion of this sort SHOULD be applied to the message actually sent to the recipient(s), not just to the version presented to the signing algorithm.
トランスミッションの前に変更されるどんな地方のコード化でも署名者にメッセージを提出するなら、調印の前に正準な[RFC2822]フォームへのその変更をしなければなりません。 メッセージがサインされる前に特に、むき出しのCRかLFキャラクタ(いくつかのシステムで、ローカル線分離符コンベンションとして使用される)をSMTP標準のCRLF系列に変換しなければなりません。 適用されていて、どんなこの変換もSHOULDを調印アルゴリズムに提示されたバージョンだけではなく、実際に受取人に送られたメッセージに分類します。
More generally, the signer MUST sign the message as it is expected to be received by the verifier rather than in some local or internal form.
より一般に、何らかの地方の、または、内部のフォームでというよりむしろ検証によって受け取られると予想されるとき、署名者はメッセージにサインしなければなりません。
Allman, et al. Standards Track [Page 35] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[35ページ]。
5.4. Determine the Header Fields to Sign
5.4. サインするためにヘッダーフィールドを決定してください。
The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field). Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit. In particular, [RFC2821] explicitly permits modification or removal of the Return-Path header field in transit. Signers MAY include any other header fields present at the time of signing at the discretion of the signer.
Fromヘッダーフィールドにサインしなければなりません(すなわち、結果として起こるDKIM-署名ヘッダーフィールドの「h=」タグでは、含まれています)。 署名者SHOULD NOTは合法的に変更しそうであるか、またはトランジットで取り除きそうな既存のヘッダーフィールドに、サインします。 特に、[RFC2821]は明らかにトランジットにおける、Return-経路ヘッダーフィールドの変更か取り外しを可能にします。 署名者は署名者の裁量でサインする時点の現在のいかなる他のヘッダーフィールドも含むかもしれません。
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
sign is non-obvious. One strategy is to sign all existing, non-
repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver. A
third strategy is to sign only "well known" headers. Note that
verifiers may treat unsigned header fields with extreme
skepticism, including refusing to display them to the end user or
even ignoring the signature if it does not cover certain header
fields. For this reason, signing fields present in the message
such as Date, Subject, Reply-To, Sender, and all MIME header
fields are highly advised.
有益な操作は以下に注意します。 選択はどのヘッダーフィールドにサインするかを非明白です。 1つの戦略はすべての既存の、そして、非反復可能なヘッダーフィールドにサインすることです。 代替の戦略は表示しそうであるか、またはそうでなければ、受信機でメッセージの処理に影響しそうなようにありそうなヘッダーフィールドだけにサインすることです。3番目の戦略は「よく知られている」ヘッダーだけにサインすることです。 検証が極端な懐疑をもって無記名のヘッダーフィールドを扱うかもしれないことに注意してください、エンドユーザにそれらを表示するのを拒否するか、またはあるヘッダーフィールドをカバーしていないなら署名を無視さえするのを含んでいて。 Sender、およびすべてのMIMEヘッダーフィールドが非常にそうです。この理由で、調印分野はDateとしてメッセージにそのようなものを示します、Subject、Reply、-、アドバイスされます。
The DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed.
DKIM-署名ヘッダーフィールドを、いつもそれとなくサインして、また、他の先在の署名がサインされるのを示す以外に、「h=」タグに含んではいけません。
Signers MAY claim to have signed header fields that do not exist (that is, signers MAY include the header field name in the "h=" tag even if that header field does not exist in the message). When computing the signature, the non-existing header field MUST be treated as the null string (including the header field name, header field value, all punctuation, and the trailing CRLF).
署名者は、存在しないヘッダーフィールドにサインしたと主張するかもしれません(そのヘッダーフィールドがメッセージに存在していなくても、すなわち、署名者は「h=」タグにヘッダーフィールド名を含むかもしれません)。 署名を計算するとき、非既存のヘッダーフィールドをヌルストリングとして扱わなければなりません(ヘッダーフィールド名、ヘッダーフィールド値、すべての句読、および引きずっているCRLFを含んでいて)。
INFORMATIVE RATIONALE: This allows signers to explicitly assert
the absence of a header field; if that header field is added later
the signature will fail.
有益な原理: これで、署名者は明らかにヘッダーフィールドの欠如について断言できます。 そのヘッダーフィールドが後で加えられると、署名は失敗するでしょう。
INFORMATIVE NOTE: A header field name need only be listed once
more than the actual number of that header field in a message at
the time of signing in order to prevent any further additions.
For example, if there is a single Comments header field at the
time of signing, listing Comments twice in the "h=" tag is
sufficient to prevent any number of Comments header fields from
being appended; it is not necessary (but is legal) to list
Comments three or more times in the "h=" tag.
有益な注意: ヘッダーフィールド名はもう一度、どんなさらなる追加も防ぐためにサインする時点のメッセージのそのヘッダーフィールドの実数より記載されるだけでよいです。 例えば、ただ一つのCommentsヘッダーフィールドが調印時点であれば、「h=」タグに二度Commentsを記載するのが、いろいろなCommentsヘッダーフィールドが追加されるのを防ぐことができるくらいの。 「h=」タグにComments threeか、より多くの回を記載するのは必要ではありません(しかし、法的です)。
Allman, et al. Standards Track [Page 36] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[36ページ]。
Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added.
メッセージの一度(Receivedとしてのそのようなもの)がそうしなければならないより起こる既存のヘッダーフィールドにサインするのを選ぶ署名者がヘッダーブロックでそのヘッダーフィールドの物理的に最後の例にサインします。 そのようなヘッダーフィールドの複数の例にサインしたがっている署名者は、DKIM-署名ヘッダーフィールドのh=タグに複数の回ヘッダーフィールド名を含まなければならなくて、ヘッダー周囲浸潤麻酔法の下部から先端まで整然としているそのようなヘッダーフィールドにサインしなければなりません。 署名者はhのヘッダーフィールド名の= その名前SHOULD NOTの追加ヘッダーフィールドが加えられるのを示すために実際の対応するヘッダーフィールドがあるより多くの例を含むかもしれません。
INFORMATIVE EXAMPLE:
有益な例:
If the signer wishes to sign two existing Received header fields,
and the existing header contains:
2つの既存のReceivedヘッダーフィールド、および存在にサインするという署名者願望であるなら、ヘッダーは以下を含んでいます。
Received: <A>
Received: <B>
Received: <C>
受け取られている: >が受けた<: <B>は受信されました: <C>。
then the resulting DKIM-Signature header field should read:
次に、結果として起こるDKIM-署名ヘッダーフィールドは読むべきです:
DKIM-Signature: ... h=Received : Received : ...
DKIM-署名: … h=は受信されました: 受け取られている: ...
and Received header fields <C> and <B> will be signed in that
order.
そして、そのオーダーはReceivedヘッダーフィールドの<C>と<B>にサインインされるでしょう。
Signers should be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or otherwise reordered. Trace header fields (such as Received) and Resent-* blocks are the only fields prohibited by [RFC2822] from being reordered. In particular, since DKIM-Signature header fields may be reordered by some intermediate MTAs, signing existing DKIM- Signature header fields is error-prone.
署名者は後で配送過程で追加例を加えるかもしれないヘッダーフィールドにサインするように注意しているべきです、そのようなヘッダーフィールドがサインされた例の後に挿入されるか、または別の方法で再命令されるかもしれないので。 跡のヘッダーフィールド(Receivedなどの)とResent-*ブロックは再命令されるのが[RFC2822]によって禁止された唯一の分野です。 DKIM-署名ヘッダーフィールドがいくつかの中間的MTAsによって再命令されるかもしれないので、既存のDKIM署名ヘッダーフィールドにサインするのは誤り特に、傾向があります。
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits
header fields to be reordered (with the exception of Received
header fields), reordering of signed header fields with multiple
instances by intermediate MTAs will cause DKIM signatures to be
broken; such anti-social behavior should be avoided.
有益な訓戒: [RFC2822]が、ヘッダーフィールドが再命令されることを(Receivedヘッダーフィールドを除いて)許可するという事実にもかかわらず、中間的MTAsによる複数の例があるサインされたヘッダーフィールドに関する再命令は、DKIM署名が中断していることを引き起こすでしょう。 そのような非社交的な振舞いは避けられるべきです。
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this
specification, all end-user visible header fields should be signed
to avoid possible "indirect spamming". For example, if the
Subject header field is not signed, a spammer can resend a
previously signed mail, replacing the legitimate subject with a
one-line spam.
有益なIMPLEMENTERの注意: この仕様は必要ではありませんが、すべてのエンドユーザの目に見えるヘッダーフィールドが可能な「間接的なばらまくこと」を避けるようにサインされるべきです。 例えば、Subjectヘッダーフィールドがサインされないなら、スパマーは以前にサインされたメールを再送できます、正統の対象を1線のスパムに取り替えて。
Allman, et al. Standards Track [Page 37] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[37ページ]。
5.5. Recommended Signature Content
5.5. お勧めの署名内容
In order to maximize compatibility with a variety of verifiers, it is recommended that signers follow the practices outlined in this section when signing a message. However, these are generic recommendations applying to the general case; specific senders may wish to modify these guidelines as required by their unique situations. Verifiers MUST be capable of verifying signatures even if one or more of the recommended header fields is not signed (with the exception of From, which must always be signed) or if one or more of the disrecommended header fields is signed. Note that verifiers do have the option of ignoring signatures that do not cover a sufficient portion of the header or body, just as they may ignore signatures from an identity they do not trust.
さまざまな検証との互換性を最大にするために、署名者がメッセージにサインするときこのセクションで概説された習慣に続くのは、お勧めです。 しかしながら、これらは一般的なケースに適用される一般的な推薦です。 特定の送付者は必要に応じてそれらのユニークな状況でこれらのガイドラインを変更したがっているかもしれません。 お勧めのヘッダーフィールドの1つ以上がサインされないか(いつもサインしなければならないFromを除いて)、または不推薦されたヘッダーフィールドの1つ以上がサインされるなら、検証は署名について確かめることができなければなりません。 検証にはヘッダーかボディーの十分な部分をカバーしない署名を無視するオプションがあることに注意してください、ちょうど彼らが信じないアイデンティティから署名を無視するかもしれないように。
The following header fields SHOULD be included in the signature, if they are present in the message being signed:
以下のヘッダーフィールドSHOULDが署名に含まれていて、それらがそうならサインされるメッセージに以下を示してください。
o From (REQUIRED in all signatures)
o from(すべての署名におけるREQUIRED)
o Sender, Reply-To
o 送付者、答え
o Subject
o 対象
o Date, Message-ID
o 日付、Message ID
o To, Cc
o cc
o MIME-Version
o MIMEバージョン
o Content-Type, Content-Transfer-Encoding, Content-ID, Content-
Description
o コンテントタイプ、満足している転送コード化、コンテントID、内容記述
o Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc,
Resent-Message-ID
o -再送して、デートしてください、憤慨、-、送付者に憤慨する、憤慨、-、ccに憤慨して、Message IDに憤慨してください。
o In-Reply-To, References
o に対して参照
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive
o リストイド、リストヘルプ、リストで外していて、リストで申し込んでいるリストポスト、リスト所有者、リストアーカイブ
The following header fields SHOULD NOT be included in the signature:
含まれていて、以下のヘッダーは署名でSHOULD NOTをさばきます:
o Return-Path
o リターンパス
o Received
o 受信します。
o Comments, Keywords
o コメント、キーワード
Allman, et al. Standards Track [Page 38] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[38ページ]。
o Bcc, Resent-Bcc
o Bccと、Bccに憤慨します。
o DKIM-Signature
o DKIM-署名
Optional header fields (those not mentioned above) normally SHOULD NOT be included in the signature, because of the potential for additional header fields of the same name to be legitimately added or reordered prior to verification. There are likely to be legitimate exceptions to this rule, because of the wide variety of application- specific header fields that may be applied to a message, some of which are unlikely to be duplicated, modified, or reordered.
通常、任意のヘッダーは同じ名前の追加ヘッダーフィールドが合法的に加えられる可能性のために署名に含まれていたか、または検証の前に再命令されたSHOULD NOTをさばきます(上に言及されなかったもの)。 この規則への正統の例外がありそうです、コピーされそうにないか、変更されそうにないか、それの或るものが再命令されそうにないメッセージに適用されるかもしれない広いバラエティーのアプリケーションの特定のヘッダーフィールドのために。
Signers SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk. For example, e-commerce sites sending primarily purchase receipts, which are not expected to be processed by mailing lists or other software likely to modify messages, will generally prefer "simple" canonicalization. Sites sending primarily person-to-person email will likely prefer to be more resilient to modification during transport by using "relaxed" canonicalization.
署名者SHOULDはそれらが処理するメッセージのタイプと彼らの危険回避に基づくcanonicalizationアルゴリズムを選びます。 例えば、主として発信する電子商取引サイトは領収書を購入します、と一般に、「簡単な」canonicalizationが好むでしょう。(領収書はメッセージを変更しそうなメーリングリストか他のソフトウェアによって処理されないと予想されます)。 主として人から人にメールを送るサイトは、輸送の間、「伸びやかな」canonicalizationを使用することによって変更により弾力があるのをおそらく好むでしょう。
Signers SHOULD NOT use "l=" unless they intend to accommodate intermediate mail processors that append text to a message. For example, many mailing list processors append "unsubscribe" information to message bodies. If signers use "l=", they SHOULD include the entire message body existing at the time of signing in computing the count. In particular, signers SHOULD NOT specify a body length of 0 since this may be interpreted as a meaningless signature by some verifiers.
テキストをメッセージに追加する中間的メールプロセッサを収容しないつもりであるなら、署名者SHOULD NOTは「l=」を使用します。 例えば、多くのメーリングリストプロセッサが「外してください」という情報をメッセージ本体に追加します。 署名者は「l=」を使用して、それらは全体のメッセージが具体化させるカウントを計算しながらサインインする時点で存在するSHOULDインクルードです。 これが無意味な署名としていくつかの検証によって解釈されるかもしれないので、特に、署名者SHOULD NOTは0のボディーの長さを指定します。
5.6. Compute the Message Hash and Signature
5.6. メッセージ細切れ肉料理と署名を計算してください。
The signer MUST compute the message hash as described in Section 3.7 and then sign it using the selected public-key algorithm. This will result in a DKIM-Signature header field that will include the body hash and a signature of the header hash, where that header includes the DKIM-Signature header field itself.
選択された公開カギアルゴリズムを使用して、署名者は、セクション3.7で説明されるようにメッセージ細切れ肉料理を計算して、次に、それにサインしなければなりません。 これはボディー細切れ肉料理を含んでいるDKIM-署名ヘッダーフィールドとヘッダー細切れ肉料理の署名をもたらすでしょう。(そこでは、そのヘッダーがDKIM-署名ヘッダーフィールド自体を含んでいます)。
Entities such as mailing list managers that implement DKIM and that modify the message or a header field (for example, inserting unsubscribe information) before retransmitting the message SHOULD check any existing signature on input and MUST make such modifications before re-signing the message.
DKIMを実行して、メッセージSHOULDを再送する前にメッセージかヘッダーフィールド(例えば、挿入して、情報を外す)を変更するメーリングリストマネージャなどの実体は、入力のときにどんな既存の署名もチェックして、メッセージを再契約する前に、そのような変更をしなければなりません。
The signer MAY elect to limit the number of bytes of the body that will be included in the hash and hence signed. The length actually hashed should be inserted in the "l=" tag of the DKIM-Signature header field.
署名者は、細切れ肉料理に含まれていて、したがってサインされるボディーのバイト数を制限するのを選ぶかもしれません。 実際に論じ尽くされた長さはDKIM-署名ヘッダーフィールドの「l=」タグに挿入されるべきです。
Allman, et al. Standards Track [Page 39] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[39ページ]。
5.7. Insert the DKIM-Signature Header Field
5.7. DKIM-署名ヘッダーフィールドを挿入してください。
Finally, the signer MUST insert the DKIM-Signature header field created in the previous step prior to transmitting the email. The DKIM-Signature header field MUST be the same as used to compute the hash as described above, except that the value of the "b=" tag MUST be the appropriately signed hash computed in the previous step, signed using the algorithm specified in the "a=" tag of the DKIM- Signature header field and using the private key corresponding to the selector given in the "s=" tag of the DKIM-Signature header field, as chosen above in Section 5.2
最終的に、署名者はメールを伝える前に前のステップで作成されたDKIM-署名ヘッダーフィールドを挿入しなければなりません。 DKIM-署名ヘッダーフィールドは上で説明されるように細切れ肉料理を計算するのに使用されるのと同じであるに違いありません、「b=」タグの値がセクション5.2で上で選ばれているようにDKIM署名ヘッダーフィールドの「a=」タグで指定されて、DKIM-署名ヘッダーフィールドの「s=」タグで与えられたセレクタに対応する秘密鍵を使用することでアルゴリズムを使用することでサインされた前のステップで計算された適切にサインされた細切れ肉料理でなければならないのを除いて
The DKIM-Signature header field MUST be inserted before any other DKIM-Signature fields in the header block.
ヘッダーブロックのいかなる他のDKIM-署名分野の前にもDKIM-署名ヘッダーフィールドを挿入しなければなりません。
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this
is to insert the DKIM-Signature header field at the beginning of
the header block. In particular, it may be placed before any
existing Received header fields. This is consistent with treating
DKIM-Signature as a trace header field.
有益な実現注意: これを達成する最も簡単な方法はヘッダーブロックの始めにおけるDKIM-署名ヘッダーフィールドを挿入することです。 特に、それはどんな既存のReceivedヘッダーフィールドの前にも置かれるかもしれません。 これはDKIM-署名を跡のヘッダーフィールドとして扱うと一致しています。
6. Verifier Actions
6. 検証動作
Since a signer MAY remove or revoke a public key at any time, it is recommended that verification occur in a timely manner. In many configurations, the most timely place is during acceptance by the border MTA or shortly thereafter. In particular, deferring verification until the message is accessed by the end user is discouraged.
署名者がいつでも公開鍵を取り除くか、または取り消すかもしれないので、検証が直ちに起こるのは、お勧めです。 多くの構成には、その後、まもなく、境界MTAによる承認の間、最もタイムリーな場所があります。 メッセージがエンドユーザによってアクセスされるまで検証を延期するのは特に、お勧めできないです。
A border or intermediate MTA MAY verify the message signature(s). An MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages. This considerably simplifies things for the user, who can now use an existing mail user agent. Most MUAs have the ability to filter messages based on message header fields or content; these filters would be used to implement whatever policy the user wishes with respect to unsigned mail.
境界か中間的MTA MAYがメッセージ署名について確かめます。 検証を実行したMTAは、検証ヘッダーフィールドを入力メッセージに追加することによって、その検証の結果を伝えるかもしれません。 これはユーザのためにものをかなり簡素化します。(そのユーザは、現在、既存のメールユーザエージェントを使用できます)。 ほとんどのMUAsには、メッセージヘッダーフィールドに基づくメッセージか内容をフィルターにかける能力があります。 これらのフィルタは、ユーザが無記名のメールに関して願っているいかなる政策も実施するのに使用されるでしょう。
A verifying MTA MAY implement a policy with respect to unverifiable mail, regardless of whether or not it applies the verification header field to signed messages.
検証MTA MAYは立証不可能なメールに関して政策を実施します、検証ヘッダーフィールドをサインされたメッセージに適用するかどうかにかかわらず。
Verifiers MUST produce a result that is semantically equivalent to applying the following steps in the order listed. In practice, several of these steps can be performed in parallel in order to improve performance.
検証はオーダーにおける以下のステップが記載した適用に意味的に同等な結果を生まなければなりません。 実際には、性能を向上させるために平行でこれらのいくつかのステップを実行できます。
Allman, et al. Standards Track [Page 40] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[40ページ]。
6.1. Extract Signatures from the Message
6.1. メッセージから署名を抽出してください。
The order in which verifiers try DKIM-Signature header fields is not defined; verifiers MAY try signatures in any order they like. For example, one implementation might try the signatures in textual order, whereas another might try signatures by identities that match the contents of the From header field before trying other signatures. Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields. In particular, there is reason to believe that some relays will reorder the header fields in potentially arbitrary ways.
検証がDKIM-署名ヘッダーフィールドを試みるオーダーは定義されません。 検証は彼らが好きであるどんなオーダーでも署名を試みるかもしれません。 例えば、1つの実現が原文のオーダーにおける署名を試みるかもしれませんが、別のものは他の署名を試みる前にFromヘッダーフィールドのコンテンツに合っているアイデンティティで署名を試みるかもしれません。 検証は究極の意義を複数のDKIM-署名ヘッダーフィールドの注文の結果と考えてはいけません。 特に、いくつかのリレーはヘッダーが潜在的に任意の方法でさばく追加注文がそうすると信じる理由があります。
INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as
a clue to signing order in the absence of any other information.
However, other clues as to the semantics of multiple signatures
(such as correlating the signing host with Received header fields)
may also be considered.
有益な実装注意: 検証はいかなる他の情報がないとき署名オーダーの手がかりとしてオーダーを使用するかもしれません。 しかしながら、また、複数の署名(Receivedヘッダーフィールドで署名ホストを関連などにさせることなどの)の意味論に関する他の手がかりは考えられるかもしれません。
A verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all; such treatment is a matter of local policy and is beyond the scope of this document.
検証SHOULD NOTは1つ以上の悪い署名を持っていますが、全く署名なしでどんな良い署名もメッセージと異なって持っていないメッセージを扱います。 そのような処理は、ローカルの方針の問題であり、このドキュメントの範囲を超えています。
When a signature successfully verifies, a verifier will either stop processing or attempt to verify any other signatures, at the discretion of the implementation. A verifier MAY limit the number of signatures it tries to avoid denial-of-service attacks.
いつ、署名が首尾よく確かめるか、検証は、処理するのを止めるか、またはいかなる他の署名についても確かめるのを試みるでしょう、実装の裁量で。 検証は、サービス不能攻撃を避けるためにそれが試みる署名の数を制限するかもしれません。
INFORMATIVE NOTE: An attacker could send messages with large
numbers of faulty signatures, each of which would require a DNS
lookup and corresponding CPU time to verify the message. This
could be an attack on the domain that receives the message, by
slowing down the verifier by requiring it to do a large number of
DNS lookups and/or signature verifications. It could also be an
attack against the domains listed in the signatures, essentially
by enlisting innocent verifiers in launching an attack against the
DNS servers of the actual victim.
有益な注意: 攻撃者は多くの不完全な署名でメッセージを送ることができました。それはそれぞれDNSルックアップとメッセージについて確かめる対応するCPU時間を必要とするでしょう。 これはメッセージを受け取るドメインに対する攻撃であるかもしれません、多くのDNSルックアップ、そして/または、署名照合をするためにそれを必要とすることによって検証を減速させることによって。 また、それは署名で記載されたドメインに対して攻撃であるかもしれません、本質的には実際の犠牲者のDNSサーバに対して攻撃を開始しながら潔白な検証を得ることによって。
In the following description, text reading "return status (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") means that the verifier MUST immediately cease processing that signature. The verifier SHOULD proceed to the next signature, if any is present, and completely ignore the bad signature. If the status is "PERMFAIL", the signature failed and should not be reconsidered. If the status is "TEMPFAIL", the signature could not be verified at this time but may be tried again later. A verifier MAY either defer the message for later processing, perhaps by queueing it locally or issuing a 451/4.7.5 SMTP reply, or try another signature; if no good
以下の記述では、テキスト読書「リターン状態(説明)」(「状態」が"PERMFAIL"か"TEMPFAIL"の1つであるところ)は、検証が、すぐにその署名を処理するのをやめなければならないことを意味します。 いずれかが悪い署名を提示して、完全、無視することであるなら、検証SHOULDは次の署名に続きます。 状態が"PERMFAIL"であるなら、署名に失敗して、再考するべきではありません。 状態が"TEMPFAIL"であるなら、署名は、このとき、確かめることができませんでしたが、後で再び試みられるかもしれません。 検証は、後で恐らく待ち行列で局所的にそれを処理するか、または451/4.7.5SMTP回答を発行することへのメッセージを延期するか、または別の署名を試みるかもしれません。 良くない
Allman, et al. Standards Track [Page 41] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[41ページ]。
signature is found and any of the signatures resulted in a TEMPFAIL status, the verifier MAY save the message for later processing. The "(explanation)" is not normative text; it is provided solely for clarification.
署名は当たられます、そして、署名のどれかはTEMPFAIL状態をもたらしました、そして、検証は後で処理することへのメッセージを保存するかもしれません。 「(説明)」は標準のテキストではありません。 唯一明確化にそれを提供します。
Verifiers SHOULD ignore any DKIM-Signature header fields where the signature does not validate. Verifiers that are prepared to validate multiple signature header fields SHOULD proceed to the next signature header field, should it exist. However, verifiers MAY make note of the fact that an invalid signature was present for consideration at a later step.
検証SHOULDは署名がそうしないどんなDKIM-署名ヘッダーフィールドも無視します。有効にします。 複数の署名ヘッダーフィールドSHOULDを有効にするように準備される検証は次の署名ヘッダーフィールドに続きます、存在しているなら。 しかしながら、検証は後のステップで無効の署名が考慮のために存在していたという事実のメモを作るかもしれません。
INFORMATIVE NOTE: The rationale of this requirement is to permit
messages that have invalid signatures but also a valid signature
to work. For example, a mailing list exploder might opt to leave
the original submitter signature in place even though the exploder
knows that it is modifying the message in some way that will break
that signature, and the exploder inserts its own signature. In
this case, the message should succeed even in the presence of the
known-broken signature.
有益な注意: この要件の原理は無効の署名にもかかわらず、有効な署名も持っているメッセージが働くことを許可することです。 例えば、メーリングリスト発破器は発破器が、その署名を壊す何らかの方法でメッセージを変更しているのを知っていますが、適所にオリジナルのsubmitter署名を残すために選ばれるかもしれません、そして、発破器はそれ自身の署名を挿入します。 この場合、メッセージは知られて中断した署名があるときさえ成功するべきです。
For each signature to be validated, the following steps should be performed in such a manner as to produce a result that is semantically equivalent to performing them in the indicated order.
各署名が有効にされるために、以下のステップはそのような方法で追って指示する注文でそれらを実行するのに意味的に同等な結果を生むほど実行されるべきです。
6.1.1. Validate the Signature Header Field
6.1.1. 署名ヘッダーフィールドを有効にしてください。
Implementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the verifier to return PERMFAIL (signature syntax error). Being "liberal in what you accept" is definitely a bad strategy in this security context. Note however that this does not include the existence of unknown tags in a DKIM-Signature header field, which are explicitly permitted.
ImplementersはDKIM-署名ヘッダーフィールドにおける形式と値をきちょうめんに有効にしなければなりません。 どんな矛盾や予期していなかった値でも、ヘッダーフィールドが完全に無視されるのを返して、検証はPERMFAIL(署名構文エラー)を返さなければなりません。 「あなたが受け入れるもので寛容」であることは、確実にこのセキュリティ文脈の悪い戦略です。 しかしながら、これがDKIM-署名ヘッダーフィールドにおける明らかに受入れられる未知のタグの存在を含んでいないことに注意してください。
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag that is inconsistent with this specification and return PERMFAIL (incompatible version).
検証は、この仕様に矛盾した「v=」タグでDKIM-署名ヘッダーフィールドを無視して、PERMFAIL(両立しないバージョン)を返さなければなりません。
INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course,
choose to also verify signatures generated by older versions of
this specification.
有益な実装注意: 実装は、また、この仕様の旧式のバージョンによって生成された署名について確かめるのをもちろん選ぶかもしれません。
If any tag listed as "required" in Section 3.5 is omitted from the DKIM-Signature header field, the verifier MUST ignore the DKIM- Signature header field and return PERMFAIL (signature missing required tag).
何かセクション3.5で「必要である」ように記載されたタグがDKIM-署名ヘッダーフィールドから省略されるなら、検証は、DKIM署名ヘッダーフィールドを無視して、PERMFAIL(署名のなくなった必要なタグ)を返さなければなりません。
Allman, et al. Standards Track [Page 42] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[42ページ]。
INFORMATIONAL NOTE: The tags listed as required in Section 3.5 are
"v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a
conflict between this note and Section 3.5, Section 3.5 is
normative.
情報の注意: 必要に応じてセクション3.5に記載されたタグは、「=」と、「=」と、「b=」と、「bh=」と、「d=」と、「h=」と、「s=」です。 この注意とセクション3.5との闘争がそうあるべきであり、セクション3.5は規範的です。
If the DKIM-Signature header field does not contain the "i=" tag, the verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag.
DKIM-署名ヘッダーフィールドが「i=」タグを含んでいないなら、検証はまるでそのタグの値が"@d"であるかのように反応しなければなりません。そこでは、「d」が「d=」タグからの値です。
Verifiers MUST confirm that the domain specified in the "d=" tag is the same as or a parent domain of the domain part of the "i=" tag. If not, the DKIM-Signature header field MUST be ignored and the verifier should return PERMFAIL (domain mismatch).
検証は、「d=」タグで指定されたドメインが同じであって、「i=」タグのドメイン一部の親ドメインであると確認しなければなりません。 そうでなければ、DKIM-署名ヘッダーフィールドを無視しなければなりません、そして、検証はPERMFAIL(ドメインミスマッチ)を返すはずです。
If the "h=" tag does not include the From header field, the verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed).
「h=」タグがFromヘッダーフィールドを含んでいないなら、検証は、DKIM-署名ヘッダーフィールドを無視して、PERMFAIL(分野から、署名されない)を返さなければなりません。
Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired.
「x=」タグを含んでいるなら、検証は、DKIM-署名ヘッダーフィールドを無視して、PERMFAIL(署名は期限が切れた)を返すかもしれません、そして、署名は期限が切れました。
Verifiers MAY ignore the DKIM-Signature header field if the domain used by the signer in the "d=" tag is not associated with a valid signing entity. For example, signatures with "d=" values such as "com" and "co.uk" may be ignored. The list of unacceptable domains SHOULD be configurable.
「d=」タグの署名者によって使用されるドメインが有効な署名実体に関連づけられないなら、検証はDKIM-署名ヘッダーフィールドを無視するかもしれません。 例えば、"com"や"co.uk"などの「d=」値がある署名は無視されるかもしれません。 記載してください。容認できないドメインSHOULDでは、構成可能であってください。
Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (unacceptable signature header) for any other reason, for example, if the signature does not sign header fields that the verifier views to be essential. As a case in point, if MIME header fields are not signed, certain attacks may be possible that the verifier would prefer to avoid.
署名が、検証が見るヘッダーフィールドが不可欠であると署名しないなら、検証は、DKIM-署名ヘッダーフィールドを無視して、例えば、いかなる他の理由でも、PERMFAIL(容認できない署名ヘッダー)を返すかもしれません。 MIMEヘッダーフィールドが署名されないなら検証が、好むだろう避けるのが攻撃が可能であるかもしれないことを確信しているその一例として。
6.1.2. Get the Public Key
6.1.2. 公開鍵を得てください。
The public key for a signature is needed to complete the verification process. The process of retrieving the public key depends on the query type as defined by the "q=" tag in the DKIM-Signature header field. Obviously, a public key need only be retrieved if the process of extracting the signature information is completely successful. Details of key management and representation are described in Section 3.6. The verifier MUST validate the key record and MUST ignore any public key records that are malformed.
署名のための公開鍵が、検証の過程を完了するのに必要です。 公開鍵を検索するプロセスは「q=」タグによってDKIM-署名ヘッダーフィールドで定義されるように質問タイプに頼っています。 明らかに、署名情報を抜粋するプロセスが完全にうまくいくなら、公開鍵は検索されるだけでよいです。 かぎ管理と表現の詳細はセクション3.6で説明されます。 検証は、主要な記録を有効にしなければならなくて、どんな奇形である公開鍵記録も無視しなければなりません。
When validating a message, a verifier MUST perform the following steps in a manner that is semantically the same as performing them in
メッセージを有効にして、検証はいつそれらを実行するのと意味的に同じ方法で以下のステップを実行しなければなりませんか。
Allman, et al. Standards Track [Page 43] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[43ページ]。
the order indicated (in some cases, the implementation may parallelize or reorder these steps, as long as the semantics remain unchanged):
指示された順番(いくつかの場合、実装がparallelizeされるかもしれませんか、またはこれらの同じくらいステップの、そして、意味論と同じくらい長い追加注文は変わりがありません):
1. Retrieve the public key as described in Section 3.6 using the
algorithm in the "q=" tag, the domain from the "d=" tag, and the
selector from the "s=" tag.
1. 「d=」タグからセクション3.6で「q=」タグ、ドメインでアルゴリズムを使用することで説明される公開鍵を検索して、「s=」タグからセレクタを検索してください。
2. If the query for the public key fails to respond, the verifier
MAY defer acceptance of this email and return TEMPFAIL (key
unavailable). If verification is occurring during the incoming
SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply
code. Alternatively, the verifier MAY store the message in the
local queue for later trial or ignore the signature. Note that
storing a message in the local queue is subject to denial-of-
service attacks.
2. 公開鍵のための質問が応じないなら、検証は、このメールの承認を延期して、TEMPFAIL(入手できないキー)を返すかもしれません。 検証が入って来るSMTPセッションの間、起こっているなら、これは451/4.7.5SMTP回答コードで達成されるかもしれません。 あるいはまた、検証は、後のトライアルのための地方の待ち行列におけるメッセージを保存するか、または署名を無視するかもしれません。 地方の待ち行列におけるメッセージを保存するのは否定を受けることがあることに注意してください、-、サービス攻撃について。
3. If the query for the public key fails because the corresponding
key record does not exist, the verifier MUST immediately return
PERMFAIL (no key for signature).
3. 対応する主要な記録が存在していないので公開鍵のための質問が失敗するなら、検証はすぐに、PERMFAIL(署名のためのキーがない)を返さなければなりません。
4. If the query for the public key returns multiple key records, the
verifier may choose one of the key records or may cycle through
the key records performing the remainder of these steps on each
record at the discretion of the implementer. The order of the
key records is unspecified. If the verifier chooses to cycle
through the key records, then the "return ..." wording in the
remainder of this section means "try the next key record, if any;
if none, return to try another signature in the usual way".
4. 公開鍵のための質問が複数の主要な記録を返すなら、検証は、implementerの裁量で各記録にこれらのステップの残りを実行しながら、主要な記録の1つを選ぶか、または主要な記録を通して循環するかもしれません。 主要な記録の注文は不特定です。 検証が、主要な記録を通して循環するのを選ぶなら、このセクションの残りにおける「リターン」…言葉遣いは、「次の主要な記録を試みてください、もしあれば」と意味します。 「なにもであるなら、戻って、不断のとおり別の署名を試みてください。」
5. If the result returned from the query does not adhere to the
format defined in this specification, the verifier MUST ignore
the key record and return PERMFAIL (key syntax error). Verifiers
are urged to validate the syntax of key records carefully to
avoid attempted attacks. In particular, the verifier MUST ignore
keys with a version code ("v=" tag) that they do not implement.
5. 質問から返された結果がこの仕様に基づき定義された書式を固く守らないなら、検証は、主要な記録を無視して、PERMFAIL(主要な構文エラー)を返さなければなりません。 検証が試みられた攻撃を避けるために慎重に主要な記録の構文を有効にするよう促されます。 特に、検証はそれらが実装しないバージョンコード(「=」タグ)があるキーを無視しなければなりません。
6. If the "g=" tag in the public key does not match the Local-part
of the "i=" tag in the message signature header field, the
verifier MUST ignore the key record and return PERMFAIL
(inapplicable key). If the Local-part of the "i=" tag on the
message signature is not present, the "g=" tag must be "*" (valid
for all addresses in the domain) or the entire g= tag must be
omitted (which defaults to "g=*"), otherwise the verifier MUST
ignore the key record and return PERMFAIL (inapplicable key).
Other than this test, verifiers SHOULD NOT treat a message signed
with a key record having a "g=" tag any differently than one
without; in particular, verifiers SHOULD NOT prefer messages that
6. 公開鍵における「g=」タグがメッセージ署名ヘッダーフィールドで「i=」タグのLocal-一部に合っていないなら、検証は、主要な記録を無視して、PERMFAIL(不適当なキー)を返さなければなりません。 メッセージ署名での「i=」タグのLocal-一部が存在していないなら、「g=」タグが「*」であるに違いない(そのドメインのすべてのアドレスに、有効な)か全体のg=タグを省略しなければならなくて(「gは*と等しく」デフォルトとします)、さもなければ、検証は、主要な記録を無視して、PERMFAIL(不適当なキー)を返さなければなりません。 このテスト、検証を除いてSHOULD NOTが「g=」が1と異なっていずれにもタグ付けをする主要な記録を契約されたメッセージを扱う。 それを通信させます特に検証SHOULD NOTが、好む。
Allman, et al. Standards Track [Page 44] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[44ページ]。
seem to have an individual signature by virtue of a "g=" tag
versus a domain signature.
「g=」タグ対ドメイン署名によって個々の署名を持っているように思えてください。
7. If the "h=" tag exists in the public key record and the hash
algorithm implied by the a= tag in the DKIM-Signature header
field is not included in the contents of the "h=" tag, the
verifier MUST ignore the key record and return PERMFAIL
(inappropriate hash algorithm).
7. 「h=」タグが公開鍵記録に存在していて、a=タグによってDKIM-署名ヘッダーフィールドで含意されたハッシュアルゴリズムが「h=」タグのコンテンツに含まれていないなら、検証は、主要な記録を無視して、PERMFAIL(不適当なハッシュアルゴリズム)を返さなければなりません。
8. If the public key data (the "p=" tag) is empty, then this key has
been revoked and the verifier MUST treat this as a failed
signature check and return PERMFAIL (key revoked). There is no
defined semantic difference between a key that has been revoked
and a key record that has been removed.
8. 公開鍵データ(「p=」タグ)が空であるならこのキーが取り消されて、検証は、失敗した署名チェックとしてこれを扱って、PERMFAILを返さなければなりません(キーは取り消されました)。 取り消されたキーと取り除かれた主要な記録の意味違いは定義されません。
9. If the public key data is not suitable for use with the algorithm
and key types defined by the "a=" and "k=" tags in the DKIM-
Signature header field, the verifier MUST immediately return
PERMFAIL (inappropriate key algorithm).
9. アルゴリズムと主要なタイプがDKIM署名ヘッダーのタグがさばく「=」と「k=」によって定義されている状態で公開鍵データが使用に適していないなら、検証はすぐに、PERMFAIL(不適当な主要なアルゴリズム)を返さなければなりません。
6.1.3. Compute the Verification
6.1.3. 検証を計算してください。
Given a signer and a public key, verifying a signature consists of actions semantically equivalent to the following steps.
署名者と公開鍵を考えて、署名について確かめるのは以下のステップに意味的に同等な動作から成ります。
1. Based on the algorithm defined in the "c=" tag, the body length
specified in the "l=" tag, and the header field names in the "h="
tag, prepare a canonicalized version of the message as is
described in Section 3.7 (note that this version does not
actually need to be instantiated). When matching header field
names in the "h=" tag against the actual message header field,
comparisons MUST be case-insensitive.
1. 「h=」タグで「c=」タグ、「l=」タグで指定されたボディーの長さ、およびヘッダーフィールド名で定義されたアルゴリズムに基づいて、そのままでセクション3.7で説明されていた状態でメッセージのcanonicalizedバージョンを用意してください(実際にこのバージョンによって例示される必要はないことに注意してください)。 「h=」タグで実際のメッセージヘッダーフィールドに対してヘッダーフィールド名を合わせるとき、比較は大文字と小文字を区別しないに違いありません。
2. Based on the algorithm indicated in the "a=" tag, compute the
message hashes from the canonical copy as described in
Section 3.7.
2. 「a=」タグで示されたアルゴリズムに基づいて、セクション3.7で説明されるように正準なコピーからメッセージハッシュを計算してください。
3. Verify that the hash of the canonicalized message body computed
in the previous step matches the hash value conveyed in the "bh="
tag. If the hash does not match, the verifier SHOULD ignore the
signature and return PERMFAIL (body hash did not verify).
3. canonicalizedメッセージ本体のハッシュが前のステップマッチで「bh=」タグで伝えられたハッシュ値を計算したことを確かめてください。 ハッシュが合っていないなら、検証SHOULDは署名を無視して、PERMFAIL(ハッシュが確かめなかったボディー)を返します。
4. Using the signature conveyed in the "b=" tag, verify the
signature against the header hash using the mechanism appropriate
for the public key algorithm described in the "a=" tag. If the
signature does not validate, the verifier SHOULD ignore the
signature and return PERMFAIL (signature did not verify).
4. 「b=」タグで伝えられた署名を使用して、「a=」タグで説明された公開鍵アルゴリズムに、適切なメカニズムを使用することでヘッダーハッシュに対して署名について確かめてください。 署名が有効にしない、検証SHOULDが署名を無視して、PERMFAILを返す、(署名が確かめなかった、)
Allman, et al. Standards Track [Page 45] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[45ページ]。
5. Otherwise, the signature has correctly verified.
5. さもなければ、署名は正しく確かめられた状態でそうしました。
INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to
initiate the public-key query in parallel with calculating the
hash as the public key is not needed until the final decryption is
calculated. Implementations may also verify the signature on the
message header before validating that the message hash listed in
the "bh=" tag in the DKIM-Signature header field matches that of
the actual message body; however, if the body hash does not match,
the entire signature must be considered to have failed.
有益なIMPLEMENTERの注意: 最終的な復号化が計算されるまで公開鍵は必要でないようにハッシュについて計算することと平行して実装が公開鍵質問を開始したがっているかもしれません。 また、実装はメッセージハッシュが「bh=」タグにDKIM-署名ヘッダーフィールドで記載した有効にする前のヘッダーが実際のメッセージ本体のものに合っているというメッセージで署名について確かめるかもしれません。 しかしながら、ボディーハッシュが合っていないなら、失敗したと全体の署名を考えなければなりません。
A body length specified in the "l=" tag of the signature limits the number of bytes of the body passed to the verification algorithm. All data beyond that limit is not validated by DKIM. Hence, verifiers might treat a message that contains bytes beyond the indicated body length with suspicion, such as by truncating the message at the indicated body length, declaring the signature invalid (e.g., by returning PERMFAIL (unsigned content)), or conveying the partial verification to the policy module.
ボディーの長さは署名限界の「l=」タグで検証アルゴリズムに通過されたボディーのバイト数を指定しました。 その限界を超えたすべてのデータがDKIMによって有効にされるというわけではありません。 したがって、検証は示されたボディーの長さに容疑でバイトを含むメッセージを扱うかもしれません、示されたボディーの長さでメッセージに先端を切らせるのなどように、署名が無効であると(例えば、戻っているPERMFAIL(未署名の内容)による)宣言するか、または部分的な検証を方針モジュールに伝えて。
INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body
at the indicated body length might pass on a malformed MIME
message if the signer used the "N-4" trick (omitting the final
"--CRLF") described in the informative note in Section 3.4.5.
Such verifiers may wish to check for this case and include a
trailing "--CRLF" to avoid breaking the MIME structure. A simple
way to achieve this might be to append "--CRLF" to any "multipart"
message with a body length; if the MIME structure is already
correctly formed, this will appear in the postlude and will not be
displayed to the end user.
有益な実装注意: 使用されて、力が署名者であるなら奇形のMIMEメッセージで通過する示されたボディーの長さでボディーに先端を切らせる検証、「N-4インチがだまされる、(決勝を省略する、「--、CRLF、」、)、セクション3.4.5におけるインチ有益な注意では、説明されます。 そのような検証がこのような場合チェックして、引きずることを含みたがっているかもしれない、「--、CRLF、」 MIME構造を壊すのを避けるために。 これを達成する簡単な方法がそう、追加する、「--、CRLF、」 ボディーの長さがあるどんな「複合」のメッセージにも。 MIME構造が既に正しく形成されると、これは、後奏曲に載って、エンドユーザに表示されないでしょう。
6.2. Communicate Verification Results
6.2. 検証結果を伝えてください。
Verifiers wishing to communicate the results of verification to other parts of the mail system may do so in whatever manner they see fit. For example, implementations might choose to add an email header field to the message before passing it on. Any such header field SHOULD be inserted before any existing DKIM-Signature or preexisting authentication status header fields in the header field block.
それらが方法で何でも見るかは、メールシステムの他の部分に検証の結果を伝えることを願っているのはそうする検証が合うので、合いました。 例えば、実装は、それを伝える前にメールヘッダーフィールドをメッセージに追加するのを選ぶかもしれません。 どんな既存のDKIM-署名の前にも挿入されるか、またはヘッダーに認証状態ヘッダーフィールドを先在することにさせるのであるどんなそのようなヘッダーフィールドSHOULDもブロックをさばきます。
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to
search for results header fields to visibly mark authenticated
mail for end users should verify that such header field was added
by the appropriate verifying domain and that the verified identity
matches the author identity that will be displayed by the MUA. In
particular, MUA filters should not be influenced by bogus results
MUAへのINFORMATIVE ADVICEは作家をフィルターにかけます: 明らかにマークするヘッダーフィールドがエンドユーザのためにメールを認証したという結果を捜し求めることを意図するパターンは、そのようなヘッダーフィールドが適切な検証ドメインによって加えられて、確かめられたアイデンティティがMUAによって表示される作者のアイデンティティに合っていることを確かめるべきです。 特に、にせの結果でMUAフィルタに影響を及ぼすべきではありません。
Allman, et al. Standards Track [Page 46] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[46ページ]。
header fields added by attackers. To circumvent this attack,
verifiers may wish to delete existing results header fields after
verification and before adding a new header field.
攻撃者によって加えられたヘッダーフィールド。 この攻撃を回避するために、検証は検証の後と新しいヘッダーフィールドを加える前にヘッダーがさばく既存の結果を削除したがっているかもしれません。
6.3. Interpret Results/Apply Local Policy
6.3. /がローカルの方針を適用するという結果を解釈してください。
It is beyond the scope of this specification to describe what actions a verifier system should make, but an authenticated email presents an opportunity to a receiving system that unauthenticated email cannot. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation. It is reasonable to treat unauthenticated email as lacking any trust and having no positive reputation.
それは検証システムがどんな動作をするはずであるかを説明するためにこの仕様の範囲を超えていますが、認証されたメールは非認証されたメールがそうすることができない受電方式に機会を提示します。 明確に、認証されたメールは他の決定に確かに対処できる予測できる識別子を作成します、信頼や評判のように。 逆に、非認証されたメールは信頼と評判を割り当てるのに使用できる信頼できる識別子を欠いています。 どんな信頼も欠いていて、どんな積極的な評判も持っていないとして非認証されたメールを扱うのは妥当です。
In general, verifiers SHOULD NOT reject messages solely on the basis of a lack of signature or an unverifiable signature; such rejection would cause severe interoperability problems. However, if the verifier does opt to reject such messages (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and the verifier runs synchronously with the SMTP session and a signature is missing or does not verify, the MTA SHOULD use a 550/5.7.x reply code.
一般に、検証SHOULD NOTは唯一署名の不足か立証不可能な署名に基づいてメッセージを拒絶します。 そのような拒絶は厳しい相互運用性問題を引き起こすでしょう。しかしながら、検証が署名がメッセージ(同輩とコミュニケートするとき、例えば、だれが、発信するだけであるのにあらかじめ取り決めて同意するかがメッセージに署名した)、および検証がSMTPセッションで同時実行して、逃しているか、または確かめないそのようなものを拒絶するために選ばれるなら、MTA SHOULDは550/5.7.x回答コードを使用します。
If it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as:
公開鍵をとって来るのが可能でないなら、恐らく主要なサーバが利用可能でないので、451/4.7.5回答コードを使用するのは一時障害メッセージに生成されるかもしれません、以下のように
451 4.7.5 Unable to verify signature - key server unavailable
451 4.7.5 入手できない署名--主要なサーバについて確かめることができません。
Temporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code. In particular, cryptographic signature verification failures MUST NOT return 4xx SMTP replies.
主要なサーバか他の外部サービスにアクセスできないことなどの一時障害はSHOULDが4xx SMTP回答コードを使用するという唯一の条件です。 特に、暗号の署名照合失敗は回答を4xx SMTPに返してはいけません。
Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/whitelists and reputation systems) and/or to the end user. If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader.
署名がいったん確かめられると、よりハイレベルのシステム(明白であるように、/whitelistsと評判システムを許容する)エンドユーザにその情報を伝えなければなりません。 メッセージがFrom:のそれを除いたどんなアドレスを代表して署名されるなら ヘッダーフィールド、メールシステムSHOULDは、読者にとって、実際の署名のアイデンティティが明確であることを保証するために苦心をします。
The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user.
検証は極端な懐疑をもって未署名のヘッダーフィールドを扱うかもしれません、信頼されていないとしてそれらをマークするか、またはディスプレイの前にそれらをエンドユーザに削除さえするのを含んでいて。
Allman, et al. Standards Track [Page 47] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[47ページ]。
While the symptoms of a failed verification are obvious -- the signature doesn't verify -- establishing the exact cause can be more difficult. If a selector cannot be found, is that because the selector has been removed, or was the value changed somehow in transit? If the signature line is missing, is that because it was never there, or was it removed by an overzealous filter? For diagnostic purposes, the exact reason why the verification fails SHOULD be made available to the policy module and possibly recorded in the system logs. If the email cannot be verified, then it SHOULD be rendered the same as all unverified email regardless of whether or not it looks like it was signed.
失敗した検証の兆候は明白です--署名がそうしない、検証、--正確な原因を確立するのは、より難しい場合があります。 セレクタを見つけることができないならそれがセレクタが取り外されたからである、またはトランジットで値をどうにか変えましたか? 署名欄がなくなるならそれがそれがそこに決してなかったからである、または熱心過ぎたフィルタはそれを取り除きましたか? 診断目的、検証がSHOULDに失敗する正確な理由で、方針モジュールに利用可能に作られていて、ことによるとシステムログに記録されてください。 メールを確かめることができないで、次に、それはSHOULDです。それが署名されたように見えるかどうかにかかわらずすべてがメールを非検証したので、同じようにレンダリングされてください。
7. IANA Considerations
7. IANA問題
DKIM introduces some new namespaces that have been registered with IANA. In all cases, new values are assigned only for values that have been documented in a published RFC that has IETF Consensus [RFC2434].
DKIMはIANAに登録されたいくつかの新しい名前空間を導入します。 すべての場合では、新しい値はIETF Consensus[RFC2434]を持っている発行されたRFCに記録された値のためだけに割り当てられます。
7.1. DKIM-Signature Tag Specifications
7.1. DKIM-署名タグ仕様
A DKIM-Signature provides for a list of tag specifications. IANA has established the DKIM-Signature Tag Specification Registry for tag specifications that can be used in DKIM-Signature fields.
DKIM-署名はタグ仕様のリストに備えます。 IANAはDKIM-署名分野で使用できるタグ仕様のためにDKIM-署名Tag Specification Registryを設立しました。
The initial entries in the registry comprise:
登録の初期のエントリーは以下を包括します。
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| v | (this document) |
| a | (this document) |
| b | (this document) |
| bh | (this document) |
| c | (this document) |
| d | (this document) |
| h | (this document) |
| i | (this document) |
| l | (this document) |
| q | (this document) |
| s | (this document) |
| t | (this document) |
| x | (this document) |
| z | (this document) |
+------+-----------------+
+------+-----------------+ | タイプ| 参照| +------+-----------------+ | v| (このドキュメント) | | a| (このドキュメント) | | b| (このドキュメント) | | bh| (このドキュメント) | | c| (このドキュメント) | | d| (このドキュメント) | | h| (このドキュメント) | | i| (このドキュメント) | | l| (このドキュメント) | | q| (このドキュメント) | | s| (このドキュメント) | | t| (このドキュメント) | | x| (このドキュメント) | | z| (このドキュメント) | +------+-----------------+
DKIM-Signature Tag Specification Registry Initial Values
DKIM-署名のタグの仕様の登録の初期の値
Allman, et al. Standards Track [Page 48] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[48ページ]。
7.2. DKIM-Signature Query Method Registry
7.2. DKIM-署名質問メソッド登録
The "q=" tag-spec (specified in Section 3.5) provides for a list of query methods.
「q=」タグ仕様(セクション3.5では、指定される)は質問メソッドのリストに備えます。
IANA has established the DKIM-Signature Query Method Registry for mechanisms that can be used to retrieve the key that will permit validation processing of a message signed using DKIM.
IANAはDKIMを使用することでメッセージの処理が署名した合法化を可能にするキーを検索するのに使用できるメカニズムのためにDKIM-署名Query Method Registryを設立しました。
The initial entry in the registry comprises:
登録の初期のエントリーは以下を包括します。
+------+--------+-----------------+
| TYPE | OPTION | REFERENCE |
+------+--------+-----------------+
| dns | txt | (this document) |
+------+--------+-----------------+
+------+--------+-----------------+ | タイプ| オプション| 参照| +------+--------+-----------------+ | dns| txt| (このドキュメント) | +------+--------+-----------------+
DKIM-Signature Query Method Registry Initial Values
DKIM-署名の質問のメソッドの登録の初期の値
7.3. DKIM-Signature Canonicalization Registry
7.3. DKIM-署名Canonicalization登録
The "c=" tag-spec (specified in Section 3.5) provides for a specifier for canonicalization algorithms for the header and body of the message.
「c=」タグ仕様(セクション3.5では、指定される)はcanonicalizationアルゴリズムのためにヘッダーとメッセージ欄に特許説明書の作成書に備えます。
IANA has established the DKIM-Signature Canonicalization Algorithm Registry for algorithms for converting a message into a canonical form before signing or verifying using DKIM.
IANAは使用DKIMについて署名するか、または確かめる前にメッセージを標準形に変換するためのアルゴリズムのためにDKIM-署名Canonicalization Algorithm Registryを設立しました。
The initial entries in the header registry comprise:
ヘッダー登録の初期のエントリーは以下を包括します。
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
+---------+-----------------+ | タイプ| 参照| +---------+-----------------+ | 簡単| (このドキュメント) | | 弛緩します。| (このドキュメント) | +---------+-----------------+
DKIM-Signature Header Canonicalization Algorithm Registry
Initial Values
DKIM-署名のヘッダーのCanonicalizationのアルゴリズムの登録の初期の値
Allman, et al. Standards Track [Page 49] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[49ページ]。
The initial entries in the body registry comprise:
ボディー登録の初期のエントリーは以下を包括します。
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
+---------+-----------------+ | タイプ| 参照| +---------+-----------------+ | 簡単| (このドキュメント) | | 弛緩します。| (このドキュメント) | +---------+-----------------+
DKIM-Signature Body Canonicalization Algorithm Registry
Initial Values
DKIM-署名のボディーのCanonicalizationのアルゴリズムの登録の初期の値
7.4. _domainkey DNS TXT Record Tag Specifications
7.4. _domainkey DNS TXT Record Tag Specifications
A _domainkey DNS TXT record provides for a list of tag specifications. IANA has established the DKIM _domainkey DNS TXT Tag Specification Registry for tag specifications that can be used in DNS TXT Records.
_domainkey DNS TXT記録はタグ仕様のリストに備えます。 IANAはDNS TXT Recordsで使用できるタグ仕様のためにDKIM_domainkey DNS TXT Tag Specification Registryを設立しました。
The initial entries in the registry comprise:
登録の初期のエントリーは以下を包括します。
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| v | (this document) |
| g | (this document) |
| h | (this document) |
| k | (this document) |
| n | (this document) |
| p | (this document) |
| s | (this document) |
| t | (this document) |
+------+-----------------+
+------+-----------------+ | タイプ| 参照| +------+-----------------+ | v| (このドキュメント) | | g| (このドキュメント) | | h| (このドキュメント) | | k| (このドキュメント) | | n| (このドキュメント) | | p| (このドキュメント) | | s| (このドキュメント) | | t| (このドキュメント) | +------+-----------------+
DKIM _domainkey DNS TXT Record Tag Specification Registry
Initial Values
DKIM_domainkey DNS TXTはタグの仕様の登録の初期の値を記録します。
7.5. DKIM Key Type Registry
7.5. DKIMの主要なタイプ登録
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- a-tag-k> (specified in Section 3.5) tags provide for a list of mechanisms that can be used to decode a DKIM signature.
sig-aタグk>(セクション3.5では、指定される)がタグ付けをする「k=」<の主要なk-タグ>(セクション3.6.1では、指定される)と「a=」<はDKIM署名を解読するのに使用できるメカニズムのリストに備えます。
IANA has established the DKIM Key Type Registry for such mechanisms.
IANAはそのようなメカニズムのためにDKIM Key Type Registryを設立しました。
Allman, et al. Standards Track [Page 50] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[50ページ]。
The initial entry in the registry comprises:
登録の初期のエントリーは以下を包括します。
+------+-----------+
| TYPE | REFERENCE |
+------+-----------+
| rsa | [RFC3447] |
+------+-----------+
+------+-----------+ | タイプ| 参照| +------+-----------+ | rsa| [RFC3447]| +------+-----------+
DKIM Key Type Initial Values
DKIMの主要なタイプ初期の値
7.6. DKIM Hash Algorithms Registry
7.6. DKIMハッシュアルゴリズム登録
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- a-tag-h> (specified in Section 3.5) tags provide for a list of mechanisms that can be used to produce a digest of message data.
sig-aタグh>(セクション3.5では、指定される)がタグ付けをする「h=」<の主要なh-タグ>(セクション3.6.1では、指定される)と「a=」<はメッセージデータのダイジェストを製作するのに使用できるメカニズムのリストに備えます。
IANA has established the DKIM Hash Algorithms Registry for such mechanisms.
IANAはそのようなメカニズムのためにDKIM Hash Algorithms Registryを設立しました。
The initial entries in the registry comprise:
登録の初期のエントリーは以下を包括します。
+--------+-------------------+
| TYPE | REFERENCE |
+--------+-------------------+
| sha1 | [FIPS.180-2.2002] |
| sha256 | [FIPS.180-2.2002] |
+--------+-------------------+
+--------+-------------------+ | タイプ| 参照| +--------+-------------------+ | sha1| [FIPS.180-2.2002]| | sha256| [FIPS.180-2.2002]| +--------+-------------------+
DKIM Hash Algorithms Initial Values
DKIMハッシュアルゴリズムは値に頭文字をつけます。
7.7. DKIM Service Types Registry
7.7. DKIMサービスは登録をタイプします。
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a list of service types to which this selector may apply.
「s=」<の主要なs-タグの>タグ(セクション3.6.1では、指定される)はこのセレクタが適用されるかもしれないサービスタイプのリストに備えます。
IANA has established the DKIM Service Types Registry for service types.
IANAはサービスタイプのためにDKIM Service Types Registryを設立しました。
The initial entries in the registry comprise:
登録の初期のエントリーは以下を包括します。
+-------+-----------------+
| TYPE | REFERENCE |
+-------+-----------------+
| email | (this document) |
| * | (this document) |
+-------+-----------------+
+-------+-----------------+ | タイプ| 参照| +-------+-----------------+ | メール| (このドキュメント) | | * | (このドキュメント) | +-------+-----------------+
DKIM Service Types Registry Initial Values
DKIMサービスは登録の初期の値をタイプします。
Allman, et al. Standards Track [Page 51] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[51ページ]。
7.8. DKIM Selector Flags Registry
7.8. DKIMセレクタは登録に旗を揚げさせます。
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a list of flags to modify interpretation of the selector.
「t=」<の主要なt-タグの>タグ(セクション3.6.1では、指定される)は、セレクタの解釈を変更するために旗のリストに備えます。
IANA has established the DKIM Selector Flags Registry for additional flags.
IANAは追加旗のためにDKIM Selector Flags Registryを設立しました。
The initial entries in the registry comprise:
登録の初期のエントリーは以下を包括します。
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| y | (this document) |
| s | (this document) |
+------+-----------------+
+------+-----------------+ | タイプ| 参照| +------+-----------------+ | y| (このドキュメント) | | s| (このドキュメント) | +------+-----------------+
DKIM Selector Flags Registry Initial Values
DKIMセレクタは登録の初期の値に旗を揚げさせます。
7.9. DKIM-Signature Header Field
7.9. DKIM-署名ヘッダーフィールド
IANA has added DKIM-Signature to the "Permanent Message Header Fields" registry (see [RFC3864]) for the "mail" protocol, using this document as the reference.
IANAは「メール」プロトコルのために「永久的なメッセージヘッダーフィールド」登録([RFC3864]を見る)にDKIM-署名を加えました、参照としてこのドキュメントを使用して。
8. Security Considerations
8. セキュリティ問題
It has been observed that any mechanism that is introduced that attempts to stem the flow of spam is subject to intensive attack. DKIM needs to be carefully scrutinized to identify potential attack vectors and the vulnerability to each. See also [RFC4686].
スパムの流れを食い止める試みをある紹介されるどんなメカニズムも徹底的を条件として攻撃されるのが観測されました。 DKIMは、起こり得るかもしれない攻撃ベクトルと脆弱性をそれぞれに特定するために慎重に精査される必要があります。 また、[RFC4686]を見てください。
8.1. Misuse of Body Length Limits ("l=" Tag)
8.1. ボディー長さの限界の誤用(「l=」タグ)
Body length limits (in the form of the "l=" tag) are subject to several potential attacks.
ボディー長さの限界(「l=」タグの形の)はいくつかの起こり得るかもしれない攻撃を受けることがあります。
8.1.1. Addition of New MIME Parts to Multipart/*
8.1.1. 複合/*への新しいMIME部分の追加
If the body length limit does not cover a closing MIME multipart section (including the trailing "--CRLF" portion), then it is possible for an attacker to intercept a properly signed multipart message and add a new body part. Depending on the details of the MIME type and the implementation of the verifying MTA and the receiving MUA, this could allow an attacker to change the information displayed to an end user from an apparently trusted source.
ボディー長さの限界が終わりのMIME複合部をカバーしない、(引きずることを含んでいる、「--、CRLF、」、部分)、その時、攻撃者が適切に署名している複合メッセージを傍受して、新しい身体の部分を加えるのは、可能です。 MIMEの種類の細部と確かめているMTAと受信MUAの実装によって、攻撃者はこれで明らかに信じられたソースからエンドユーザに表示された情報を変えることができました。
Allman, et al. Standards Track [Page 52] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[52ページ]。
For example, if attackers can append information to a "text/html" body part, they may be able to exploit a bug in some MUAs that continue to read after a "</html>" marker, and thus display HTML text on top of already displayed text. If a message has a "multipart/alternative" body part, they might be able to add a new body part that is preferred by the displaying MUA.
例えば、彼らは、既に表示されたテキストの上で「</html>」マーカーの後に読み続けているいくつかのMUAsの欠陥を利用して、その結果、攻撃者が「テキスト/html」身体の部分に情報を追加できるなら、ディスプレイHTMLテキストを利用できるかもしれません。 メッセージに「複合か代替」の身体の部分があるなら、彼らは表示しているMUAによって好まれる新しい身体の部分を加えることができるかもしれません。
8.1.2. Addition of new HTML content to existing content
8.1.2. 既存の内容への新しいHTML内容の追加
Several receiving MUA implementations do not cease display after a ""</html>"" tag. In particular, this allows attacks involving overlaying images on top of existing text.
いくつかの受信MUA実装は「「</html>」」タグの後にディスプレイをやめません。 特に、これは既存のテキストの上でイメージをかぶせることを伴う攻撃を許します。
INFORMATIVE EXAMPLE: Appending the following text to an existing,
properly closed message will in many MUAs result in inappropriate
data being rendered on top of existing, correct data:
<div style="position: relative; bottom: 350px; z-index: 2;">
<img src="http://www.ietf.org/images/ietflogo2e.gif"
width=578 height=370>
</div>
有益な例: 既存の、そして、適切に閉じているメッセージに以下のテキストを追加すると、不適当なデータは存在の上でレンダリングされながら、多くのMUAsでもたらされるでしょう、正しいデータ: <divスタイル=は「以下を置きます」。 親類。 下部: 350px。 z-インデックス: 2; 「578の" http://www.ietf.org/images/ietflogo2e.gif "><img src=幅=高さは370></div>と等しいです」。
8.2. Misappropriated Private Key
8.2. 流用された秘密鍵
If the private key for a user is resident on their computer and is not protected by an appropriately secure mechanism, it is possible for malware to send mail as that user and any other user sharing the same private key. The malware would not, however, be able to generate signed spoofs of other signers' addresses, which would aid in identification of the infected user and would limit the possibilities for certain types of attacks involving socially engineered messages. This threat applies mainly to MUA-based implementations; protection of private keys on servers can be easily achieved through the use of specialized cryptographic hardware.
ユーザのための秘密鍵がそれらのコンピュータで居住していて、適切に安全なメカニズムによって保護されないなら、マルウェアが同じ秘密鍵を共有しているそのユーザといかなる他のユーザとしてもメールを送るのは、可能です。 しかしながら、マルウェアは他の署名者のアドレスの署名しているパロディーを生成することができないでしょう。(アドレスは、感染したユーザの識別で支援して、社会的に設計されたメッセージにかかわるあるタイプの攻撃のために可能性を制限するでしょう)。 この脅威は主にMUAベースの実装に適用されます。 専門化している暗号のハードウェアの使用で容易にサーバにおける秘密鍵の保護を達成できます。
A larger problem occurs if malware on many users' computers obtains the private keys for those users and transmits them via a covert channel to a site where they can be shared. The compromised users would likely not know of the misappropriation until they receive "bounce" messages from messages they are purported to have sent. Many users might not understand the significance of these bounce messages and would not take action.
多くのユーザのコンピュータの上のマルウェアが彼らを共有できるサイトにそれらのユーザとして秘密鍵を得て、ひそかなチャンネルで彼らを送るなら、より大きい問題は起こります。 感染しているユーザは、それらが発信したために意味されるのをおそらく彼らがメッセージから「弾み」メッセージを受け取るまでの流用を知らないでしょう。 多くのユーザは、これらの弾みのメッセージの意味を理解しないかもしれなくて、また行動を取らないでしょう。
One countermeasure is to use a user-entered passphrase to encrypt the private key, although users tend to choose weak passphrases and often reuse them for different purposes, possibly allowing an attack against DKIM to be extended into other domains. Nevertheless, the decoded private key might be briefly available to compromise by malware when it is entered, or might be discovered via keystroke
1つの対策は秘密鍵を暗号化するのにユーザによって入力されたパスフレーズを使用することです、ユーザが弱いパスフレーズを選んで、異なる役割のためにしばしばそれらを再利用する傾向がありますが、ことによるとDKIMに対する攻撃が他のドメインに広げられるのを許容して。 それが入られるか、またはキーストロークで発見されるかもしれないとき、それにもかかわらず、解読された秘密鍵は、マルウェアで感染するために簡潔に利用可能であるかもしれません。
Allman, et al. Standards Track [Page 53] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[53ページ]。
logging. The added complexity of entering a passphrase each time one sends a message would also tend to discourage the use of a secure passphrase.
伐採。 また、1つがメッセージを送るたびにパスフレーズを入れる加えられた複雑さは、安全なパスフレーズの使用に水をさしている傾向があるでしょう。
A somewhat more effective countermeasure is to send messages through an outgoing MTA that can authenticate the submitter using existing techniques (e.g., SMTP Authentication), possibly validate the message itself (e.g., verify that the header is legitimate and that the content passes a spam content check), and sign the message using a key appropriate for the submitter address. Such an MTA can also apply controls on the volume of outgoing mail each user is permitted to originate in order to further limit the ability of malware to generate bulk email.
いくらか効果的な対策は、submitterアドレスに、適切なキーを使用することで、出発しているMTAを通した存在を使用することでsubmitterを認証できるメッセージにテクニック(例えば、SMTP Authentication)を送って、ことによると、メッセージ(例えば、ヘッダーが正統であり、内容がスパム内容チェックを通過することを確かめる)自体を有効にして、メッセージに署名することです。 また、そのようなMTAは、さらにマルウェアが大量のメールを作る能力を制限するために溯源する各ユーザが許可されている送信するメールのボリュームにコントロールを適用できます。
8.3. Key Server Denial-of-Service Attacks
8.3. 主要なサーバサービス不能攻撃
Since the key servers are distributed (potentially separate for each domain), the number of servers that would need to be attacked to defeat this mechanism on an Internet-wide basis is very large. Nevertheless, key servers for individual domains could be attacked, impeding the verification of messages from that domain. This is not significantly different from the ability of an attacker to deny service to the mail exchangers for a given domain, although it affects outgoing, not incoming, mail.
主要なサーバが分配されているので(各ドメインには、潜在的に別々の)、インターネット全体のベースでこのメカニズムを破るために攻撃される必要があるサーバの数は非常に大きいです。 それにもかかわらず、そのドメインからメッセージの検証を妨害して、個々のドメインへの主要なサーバを攻撃できました。 これは攻撃者がメール交換器に対するサービスを与えられたドメインに対して否定する能力とかなり異なっていません、それですが影響、外向的である、入来(メール)でない
A variation on this attack is that if a very large amount of mail were to be sent using spoofed addresses from a given domain, the key servers for that domain could be overwhelmed with requests. However, given the low overhead of verification compared with handling of the email message itself, such an attack would be difficult to mount.
この攻撃の変化は非常に多量のメールが与えられたドメインからアドレスであると偽造された使用を送ることであるなら、要求でそのドメインへの主要なサーバを圧倒できるということです。 しかしながら、メールメッセージ自体の取り扱いと比べた検証の低いオーバーヘッドを考えて、そのような攻撃は取り付けるのが難しいでしょう。
8.4. Attacks Against the DNS
8.4. DNSに対する攻撃
Since the DNS is a required binding for key services, specific attacks against the DNS must be considered.
DNSが主要なサービスのための必要な結合であるので、DNSに対する特定の攻撃を考えなければなりません。
While the DNS is currently insecure [RFC3833], these security problems are the motivation behind DNS Security (DNSSEC) [RFC4033], and all users of the DNS will reap the benefit of that work.
DNSは現在、不安定ですが[RFC3833]、これらの警備上の問題はDNS Security(DNSSEC)[RFC4033]の後ろの動機です、そして、DNSのすべてのユーザがその仕事の恩恵を獲得するでしょう。
DKIM is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements.
DKIMは信憑性を立証する「十分な」メソッドとして意図するだけです。 それが著述業かコンテンツに関する強い暗号の証拠を提供することを意図しません。 OpenPGPなどの他の技術[RFC2440]とS/MIME[RFC3851]はそれらの要件を扱います。
A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching selector-based data as well as fetching signing domain policy. Widespread
DNSに関連する2番目の安全保障問題は魅惑的な署名ドメイン方針と同様にセレクタベースのデータをとって来る結果として増強されたDNSトラフィックを中心題目とします。 広範囲
Allman, et al. Standards Track [Page 54] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[54ページ]。
deployment of DKIM will result in a significant increase in DNS queries to the claimed signing domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries.
DKIMの展開は要求された署名ドメインへのDNS質問のかなりの増加をもたらすでしょう。 大規模の偽造の場合では、DNSサーバは質問のかなりの増加を見るかもしれません。
A specific DNS security issue that should be considered by DKIM verifiers is the name chaining attack described in Section 2.3 of the DNS Threat Analysis [RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header field, could be prompted to retrieve a key record of an attacker's choosing. This threat can be minimized by ensuring that name servers, including recursive name servers, used by the verifier enforce strict checking of "glue" and other additional information in DNS responses and are therefore not vulnerable to this attack.
DKIM検証によって考えられるべきである特定のDNS安全保障問題はDNS Threat Analysis[RFC3833]のセクション2.3で説明された名前推論攻撃です。 DKIM-署名ヘッダーフィールドについて確かめている間、DKIM検証が攻撃者の選ぶことの主要な記録を検索するようにうながすことができました。 再帰的なネームサーバを含む検証で中古のネームサーバが確実にDNS応答で「接着剤」と他の追加情報の厳しい照合を実施して、したがって、この攻撃に被害を受け易くならないようにすることによって、この脅威を最小にすることができます。
8.5. Replay Attacks
8.5. 反射攻撃
In this attack, a spammer sends a message to be spammed to an accomplice, which results in the message being signed by the originating MTA. The accomplice resends the message, including the original signature, to a large number of recipients, possibly by sending the message to many compromised machines that act as MTAs. The messages, not having been modified by the accomplice, have valid signatures.
この攻撃では、スパマーは起因しているMTAを共犯へばらまかれるべきメッセージに署名させます。その共犯は、メッセージをもたらします。 共犯はメッセージを再送します、オリジナルの署名を含んでいて、多くの受取人に、ことによるとMTAsとして作動するマシンであると感染される多くにメッセージを送ることによって。 メッセージには、共犯によって変更されていなくて、有効な署名があります。
Partial solutions to this problem involve the use of reputation services to convey the fact that the specific email address is being used for spam and that messages from that signer are likely to be spam. This requires a real-time detection mechanism in order to react quickly enough. However, such measures might be prone to abuse, if for example an attacker resent a large number of messages received from a victim in order to make them appear to be a spammer.
この問題への部分的解決は、特定のEメールアドレスがスパムに使用されていて、その署名者からのメッセージがスパムである傾向があるという事実を伝えるために評判サービスの使用にかかわります。 これは、十分急速に反応するためにリアルタイム検出法メカニズムを必要とします。 しかしながら、そのような測定は乱用に傾向があるかもしれません、例えば、攻撃者がスパマーであるように見えさせるために犠牲者から受け取られた多くのメッセージを再送したなら。
Large verifiers might be able to detect unusually large volumes of mails with the same signature in a short time period. Smaller verifiers can get substantially the same volume of information via existing collaborative systems.
大きい検証は短い期間に異常に同じ署名があるメールの大きいボリュームを検出できるかもしれません。 より小さい検証は存在を通して情報の実質的に同じボリュームに協力的なシステムを手に入れることができます。
8.6. Limits on Revoking Keys
8.6. キーを取り消すときの限界
When a large domain detects undesirable behavior on the part of one of its users, it might wish to revoke the key used to sign that user's messages in order to disavow responsibility for messages that have not yet been verified or that are the subject of a replay attack. However, the ability of the domain to do so can be limited if the same key, for scalability reasons, is used to sign messages for many other users. Mechanisms for explicitly revoking keys on a per-address basis have been proposed but require further study as to their utility and the DNS load they represent.
大きいドメインがユーザのひとり側の好ましくない行動を検出するとき、それはまだ確かめられていないか、反射攻撃の対象であるメッセージへの責任を否認して、そのユーザのメッセージに署名するのに使用されるキーを取り消したがっているかもしれません。 しかしながら、スケーラビリティ理由で、同じキーが多くの他のユーザのためにメッセージに署名するのに使用されるなら、ドメインがそうする能力を制限できます。 1アドレスあたり1個のベースで明らかにキーを取り消すためのメカニズムは、彼らが表すそれらのユーティリティとDNS荷重に関して提案されましたが、さらなる研究を必要とします。
Allman, et al. Standards Track [Page 55] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[55ページ]。
8.7. Intentionally Malformed Key Records
8.7. 故意に奇形の主要な記録
It is possible for an attacker to publish key records in DNS that are intentionally malformed, with the intent of causing a denial-of- service attack on a non-robust verifier implementation. The attacker could then cause a verifier to read the malformed key record by sending a message to one of its users referencing the malformed record in a (not necessarily valid) signature. Verifiers MUST thoroughly verify all key records retrieved from the DNS and be robust against intentionally as well as unintentionally malformed key records.
攻撃者が故意に奇形であるDNSでの主要な記録を発表するのは、可能です、否定を引き起こす意図をもって。-サービスでは、非強健な検証実装で攻撃してください。 そして、攻撃者は、検証に(必ず有効であるというわけではない)の署名における奇形の記録に参照をつけているユーザのひとりにメッセージを送ることによって、奇形の主要な記録を読ませるかもしれません。 検証は、DNSから検索されたすべての主要な記録について徹底的に確かめて、故意に、そして、何気なく奇形の主要な記録に対して強健であるに違いありません。
8.8. Intentionally Malformed DKIM-Signature Header Fields
8.8. 故意に奇形のDKIM-署名ヘッダーフィールド
Verifiers MUST be prepared to receive messages with malformed DKIM- Signature header fields, and thoroughly verify the header field before depending on any of its contents.
奇形のDKIM署名ヘッダーフィールドでメッセージを受け取って、コンテンツのどれかによる前にヘッダーフィールドについて徹底的に確かめるように検証を準備しなければなりません。
8.9. Information Leakage
8.9. 情報漏出
An attacker could determine when a particular signature was verified by using a per-message selector and then monitoring their DNS traffic for the key lookup. This would act as the equivalent of a "web bug" for verification time rather than when the message was read.
攻撃者は、特定の署名がいつ1メッセージあたり1個のセレクタを使用して、次に、主要なルックアップのためにそれらのDNSトラフィックをモニターすることによって確かめられたかを決心できました。 これはメッセージが読まれた時よりむしろ検証時間の「ウェブバグ」の同等物として機能するでしょう。
8.10. Remote Timing Attacks
8.10. リモートタイミング攻撃
In some cases, it may be possible to extract private keys using a remote timing attack [BONEH03]. Implementations should consider obfuscating the timing to prevent such attacks.
いくつかの場合、リモートタイミング攻撃[BONEH03]を使用する秘密鍵を抽出するのは可能であるかもしれません。 実装は、そのような攻撃を防ぐためにタイミングを困惑させると考えるべきです。
8.11. Reordered Header Fields
8.11. ヘッダーフィールドをReorderedしました。
Existing standards allow intermediate MTAs to reorder header fields. If a signer signs two or more header fields of the same name, this can cause spurious verification errors on otherwise legitimate messages. In particular, signers that sign any existing DKIM- Signature fields run the risk of having messages incorrectly fail to verify.
既存の規格は追加注文ヘッダーフィールドに中間的MTAsを許容します。 署名者が同じ名前の2つ以上のヘッダーフィールドに署名するなら、これはそうでなければ、正統のメッセージで偽りの検証誤りを引き起こす場合があります。 特に、どんな既存のDKIM署名も分野であると署名する署名者が確かめるメッセージが不当に失敗される危険を冒します。
8.12. RSA Attacks
8.12. RSA攻撃
An attacker could create a large RSA signing key with a small exponent, thus requiring that the verification key have a large exponent. This will force verifiers to use considerable computing resources to verify the signature. Verifiers might avoid this attack by refusing to verify signatures that reference selectors with public keys having unreasonable exponents.
攻撃者は小さい解説者に、主要な大きいRSA署名を作成できました、その結果、検証キーには大きい解説者がいるのが必要です。 これによって、検証は署名について確かめるのにやむを得ずかなりのコンピューティング資源を使用するでしょう。 無理な解説者がいる公開鍵でセレクタに参照をつける署名について確かめるのを拒否することによって、検証はこの攻撃を避けるかもしれません。
Allman, et al. Standards Track [Page 56] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[56ページ]。
In general, an attacker might try to overwhelm a verifier by flooding it with messages requiring verification. This is similar to other MTA denial-of-service attacks and should be dealt with in a similar fashion.
一般に、攻撃者はメッセージが検証を必要とすることのそれをあふれさせるのによる検証を圧倒しようとするかもしれません。 これは、他のMTAサービス不能攻撃と同様であり、同様に対処されるべきです。
8.13. Inappropriate Signing by Parent Domains
8.13. 親ドメインのそばの不適当な署名
The trust relationship described in Section 3.8 could conceivably be used by a parent domain to sign messages with identities in a subdomain not administratively related to the parent. For example, the ".com" registry could create messages with signatures using an "i=" value in the example.com domain. There is no general solution to this problem, since the administrative cut could occur anywhere in the domain name. For example, in the domain "example.podunk.ca.us" there are three administrative cuts (podunk.ca.us, ca.us, and us), any of which could create messages with an identity in the full domain.
セクション3.8で説明された信頼関係は多分親ドメインによって使用されて、行政上親に伝えないサブドメインでアイデンティティをメッセージと契約するかもしれません。 例えば、".com"登録は、署名でexample.comドメインで「i=」値を使用することでメッセージを作成するかもしれません。 管理カットがドメイン名でどこでも起こることができたので、この問題の一般解が全くありません。 例えば、3つの管理カット(podunk.ca.us、ca.us、および私たち)がドメイン"example.podunk.ca.us"にあります。そのいずれも完全なドメインでアイデンティティでメッセージを作成できました。
INFORMATIVE NOTE: This is considered an acceptable risk for the
same reason that it is acceptable for domain delegation. For
example, in the example above any of the domains could potentially
simply delegate "example.podunk.ca.us" to a server of their choice
and completely replace all DNS-served information. Note that a
verifier MAY ignore signatures that come from an unlikely domain
such as ".com", as discussed in Section 6.1.1.
有益な注意: これはドメイン委譲において、同じ理由から、それが許容できるという許容リスクであると考えられます。 例えば、例では、ドメインのいずれも、上に、潜在的に単に"example.podunk.ca.us"を彼らの選択のサーバへ代表として派遣して、すべてのDNSによって役立たれた情報を完全に置き換えるかもしれません。 検証が".com"などのありそうもないドメインから来る署名を無視するかもしれないことに注意してください、セクション6.1.1で議論するように。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[FIPS.180-2.2002] U.S. Department of Commerce, "Secure Hash
Standard", FIPS PUB 180-2, August 2002.
[FIPS.180-2.2002]米国商務省、「安全なハッシュ規格」、FIPSパブ180-2、2002年8月。
[ITU.X660.1997] "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.660,
1997.
[ITU.X660.1997] 「情報Technology--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、ITU-T推薦X.660、1997。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045,
November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message header field
Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「Non-ASCII TextのためのメッセージヘッダーフィールドExtensions」、RFC2047、1996年11月。
Allman, et al. Standards Track [Page 57] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[57ページ]。
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1", RFC 3447,
February 2003.
[RFC3447] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", RFC 4234,
October 2005.
エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
9.2. Informative References
9.2. 有益な参照
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote
Timing Attacks are Practical", 2003.
[BONEH03]Proc。 第12USENIX Security Symposium、「リモートTiming AttacksはPracticalです」、2003。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed
and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
Thayer, "OpenPGP Message Format", RFC 2440,
November 1998.
[RFC2440] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths
for Public Keys Used For Exchanging Symmetric
Keys", RFC 3766, April 2004.
[RFC3766] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」RFC3766、2004年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
Allman, et al. Standards Track [Page 58] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[58ページ]。
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message
Specification", RFC 3851, June 1999.
[RFC3851] Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC3851、1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message Header
Fields", BCP 90, September 2004.
2004年9月の[RFC3864]KlyneとG.とノッティンガム、M.とJ.ムガール人、「メッセージヘッダーフィールドのための登録手順」BCP90。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D.,
and S. Rose, "DNS Security Introduction and
Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4686] Fenton, J., "Analysis of Threats Motivating
DomainKeys Identified Mail (DKIM)", RFC 4686,
September 2006.
[RFC4686] フェントン、J.、「DomainKeysを動機づける脅威の分析はメール(DKIM)を特定した」RFC4686、2006年9月。
[RFC4870] Delany, M., "Domain-Based Email Authentication
Using Public Keys Advertised in the DNS
(DomainKeys)", RFC 4870, May 2007.
[RFC4870]ディラニー(M.、「DNS(DomainKeys)の広告に掲載された公開鍵を使用するドメインベースのメール認証」、RFC4870)は2007がそうするかもしれません。
Allman, et al. Standards Track [Page 59] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[59ページ]。
Appendix A. Example of Use (INFORMATIVE)
使用に関する付録A.の例(有益)です。
This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together. The key used in this example is shown in Appendix C.
このセクションは最終的な配送への服従からメールの完全な流れを示しています、様々なコンポーネントがどう一緒に合うかを示して。 この例で使用されるキーはAppendix Cで見せられます。
A.1. The User Composes an Email
A.1。 ユーザはメールを構成します。
From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com>
From: ジョー SixPack <joe@football.example.com 、gt;、To: スージー Q <suzie@shopping.example.net 、gt;、Subject: 夕食は準備ができていますか? 日付: 金曜日、2003年7月11日21:00:37 -0700(太平洋夏時間の)のMessage ID: <20030712040037.46341.5F8J@football.example.com>。
Hi.
こんにちは。
We lost the game. Are you hungry yet?
私たちはゲームに負けました。 あなたはもう、空腹ですか?
Joe.
ジョー。
Allman, et al. Standards Track [Page 60] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[60ページ]。
A.2. The Email Is Signed
A.2。 メールは署名されます。
This email is signed by the example.com outbound email server and now looks like this:
このメールは、example.comの外国行きのEメールサーバによって署名されて、現在、これに似ています:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
DKIM-署名: v=1。 a=rsa-sha256。 s=brisbane。 d=example.com。 cは簡単な/と簡単な状態で等しいです。 q=dns/txt。 iは joe@football.example.com; と等しいです。 h=は受信されました: from: to: subject: 日付: Message ID。 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=。 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=。 受け取られている: client1.football.example.com、[192.0 .2 .1] SUBMISSIONとsubmitserver.example.com。 金曜日、2003年7月11日21:01:54 -0700(太平洋夏時間の)のFrom: ジョー SixPack <joe@football.example.com 、gt;、To: スージー Q <suzie@shopping.example.net 、gt;、Subject: 夕食は準備ができていますか? 日付: 金曜日、2003年7月11日21:00:37 -0700(太平洋夏時間の)のMessage ID: <20030712040037.46341.5F8J@football.example.com>。
Hi.
こんにちは。
We lost the game. Are you hungry yet?
私たちはゲームに負けました。 あなたはもう、空腹ですか?
Joe.
ジョー。
The signing email server requires access to the private key associated with the "brisbane" selector to generate this signature.
署名Eメールサーバは、この署名を生成するために"brisbane"セレクタに関連している秘密鍵へのアクセスを必要とします。
A.3. The Email Signature Is Verified
A.3。 メール署名は確かめられます。
The signature is normally verified by an inbound SMTP server or possibly the final delivery agent. However, intervening MTAs can also perform this verification if they choose to do so. The verification process uses the domain "example.com" extracted from the "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM- Signature header field to form the DNS DKIM query for:
通常、署名は本国行きのSMTPサーバーかことによると最終的な新聞販売店によって確かめられます。 しかしながら、また、彼らが、そうするのを選ぶなら、介入しているMTAsはこの検証を実行できます。 検証プロセスは以下に"example.com"がDNS DKIM質問を形成するために「d=」タグとセレクタ"brisbane"から「s=」タグからDKIM署名ヘッダーフィールドで抽出したドメインを使用します。
brisbane._domainkey.example.com
brisbane_domainkey.example.com
Signature verification starts with the physically last Received header field, the From header field, and so forth, in the order listed in the "h=" tag. Verification follows with a single CRLF followed by the body (starting with "Hi."). The email is canonically prepared for verifying with the "simple" method. The result of the query and subsequent verification of the signature is stored (in this
署名照合は物理的に最後のReceivedヘッダーフィールドから始まります、Fromヘッダーフィールド、などに、タグは「h=」にオーダーでは、記載していました。 ボディーが独身のCRLFのあとに続いていて、検証は続きます(「こんにちは」から始めます。)。 メールは「簡単な」メソッドがある検証のために正準に準備されます。 質問の結果と署名のその後の検証が保存される、(これ
Allman, et al. Standards Track [Page 61] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[61ページ]。
example) in the X-Authentication-Results header field line. After successful verification, the email looks like this:
例) X認証が結果として生じているヘッダーフィールドでは、立ち並んでください。 うまくいっている検証の後に、メールはこれに似ています:
X-Authentication-Results: shopping.example.net
header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
X認証は結果として生じます: shopping.example.net header.fromは joe@football.example.com; と等しいです。 dkimはパスReceivedと等しいです: mout23.football.example.com、(192.168 .1 .1) SMTPとshopping.example.net。 金曜日、2003年7月11日21:01:59 -0700(太平洋夏時間の)のDKIM-署名: v=1。 a=rsa-sha256。 s=brisbane。 d=example.com。 cは簡単な/と簡単な状態で等しいです。 q=dns/txt。 iは joe@football.example.com; と等しいです。 h=は受信されました: from: to: subject: 日付: Message ID。 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=。 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=。 受け取られている: client1.football.example.com、[192.0 .2 .1] SUBMISSIONとsubmitserver.example.com。 金曜日、2003年7月11日21:01:54 -0700(太平洋夏時間の)のFrom: ジョー SixPack <joe@football.example.com 、gt;、To: スージー Q <suzie@shopping.example.net 、gt;、Subject: 夕食は準備ができていますか? 日付: 金曜日、2003年7月11日21:00:37 -0700(太平洋夏時間の)のMessage ID: <20030712040037.46341.5F8J@football.example.com>。
Hi.
こんにちは。
We lost the game. Are you hungry yet?
私たちはゲームに負けました。 あなたはもう、空腹ですか?
Joe.
ジョー。
Appendix B. Usage Examples (INFORMATIVE)
付録B.使用例(有益)です。
DKIM signing and validating can be used in different ways, for different operational scenarios. This Appendix discusses some common examples.
異なった操作上のシナリオに異なった方法でDKIM調印と有効にすることを使用できます。 このAppendixはいくつかの一般的な例について議論します。
NOTE: Descriptions in this Appendix are for informational purposes
only. They describe various ways that DKIM can be used, given
particular constraints and needs. In no case are these examples
intended to be taken as providing explanation or guidance
concerning DKIM specification details, when creating an
implementation.
以下に注意してください。 このAppendixの記述は情報の目的だけのためのものです。 彼らは特定の規制と必要性を中古で、考えて、DKIMがそうすることができる様々な方法を述べます。 実現を作成するときDKIM仕様の詳細に関して説明か指導を提供するとしてこれらの例が取られることを決して、意図しません。
Allman, et al. Standards Track [Page 62] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[62ページ]。
B.1. Alternate Submission Scenarios
B.1。 交互の服従シナリオ
In the most simple scenario, a user's MUA, MSA, and Internet (boundary) MTA are all within the same administrative environment, using the same domain name. Therefore, all of the components involved in submission and initial transfer are related. However, it is common for two or more of the components to be under independent administrative control. This creates challenges for choosing and administering the domain name to use for signing, and for its relationship to common email identity header fields.
最も簡単なシナリオには、同じ管理環境の中にユーザのMUA、MSA、およびインターネット(境界)MTAがあります、同じドメイン名を使用して。 したがって、服従と初期の転送にかかわるコンポーネントのすべてが関係づけられます。 しかしながら、2つ以上のコンポーネントが独立している運営管理コントロールの下におけるあるのは、一般的です。 これは選んで、調印の使用にドメイン名を施す、および一般的なメールアイデンティティヘッダーフィールドとのその関係のために挑戦を作成します。
B.1.1. Delegated Business Functions
B.1.1。 代表として派遣されたビジネス機能
Some organizations assign specific business functions to discrete groups, inside or outside the organization. The goal, then, is to authorize that group to sign some mail, but to constrain what signatures they can generate. DKIM selectors (the "s=" signature tag) and granularity (the "g=" key tag) facilitate this kind of restricted authorization. Examples of these outsourced business functions are legitimate email marketing providers and corporate benefits providers.
組織の中、または、離散的なグループか、組織の外で特定のビジネス機能を割り当てる組織もあります。 目標はそして、しかし或るものがそれらが発生させることができるすべての署名を抑制するために郵送するサインにそのグループを認可することです。 DKIMセレクタ(「s=」署名タグ)と粒状(「g=」キー・タグ)はこの種類の制限された認可を容易にします。 これらの社外調達されたビジネス機能に関する例は、正統のメールマーケティングプロバイダーと法人の利益プロバイダーです。
Here, the delegated group needs to be able to send messages that are signed, using the email domain of the client company. At the same time, the client often is reluctant to register a key for the provider that grants the ability to send messages for arbitrary addresses in the domain.
ここで、代表として派遣されたグループは、サインされるメッセージを送ることができる必要があります、クライアント会社のメールドメインを使用して。 同時に、クライアントはしばしばそのドメインの任意のアドレスへのメッセージを送る能力を与えるプロバイダーのためにキーを登録するのに気が重いです。
There are multiple ways to administer these usage scenarios. In one case, the client organization provides all of the public query service (for example, DNS) administration, and in another it uses DNS delegation to enable all ongoing administration of the DKIM key record by the delegated group.
これらの用法シナリオを管理する複数の方法があります。 ある場合では、クライアント組織は公共の質問サービス(例えば、DNS)機関のすべてを提供します、そして、別のものでは、それは代表として派遣されたグループでDKIMの主要な記録のすべての進行中の管理を可能にするのにDNS代表団を使用します。
If the client organization retains responsibility for all of the DNS administration, the outsourcing company can generate a key pair, supplying the public key to the client company, which then registers it in the query service, using a unique selector that authorizes a specific From header field Local-part. For example, a client with the domain "example.com" could have the selector record specify "g=winter-promotions" so that this signature is only valid for mail with a From address of "winter-promotions@example.com". This would enable the provider to send messages using that specific address and have them verify properly. The client company retains control over the email address because it retains the ability to revoke the key at any time.
クライアント組織がDNS管理のすべてへの責任を保有するなら、アウトソーシング会社は主要な組を発生させることができます、次に質問サービスでそれを登録するクライアント会社に公開鍵を供給して、特定のFromヘッダーフィールドLocal-部分を認可するユニークなセレクタを使用して。 例えば、ドメイン"example.com"をもっているクライアントがセレクタ記録に「g=冬販売促進」を指定させることができたので、" winter-promotions@example.com "のFromアドレスがあるメールだけに、この署名は有効です。 これは、プロバイダーがそんなに特定の使用で記述して、彼らが適切に確かめるメッセージを送るのを可能にするでしょう。 いつでもキーを取り消す能力を保有するので、クライアント会社はEメールアドレスのコントロールを保有します。
Allman, et al. Standards Track [Page 63] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[63ページ]。
If the client wants the delegated group to do the DNS administration, it can have the domain name that is specified with the selector point to the provider's DNS server. The provider then creates and maintains all of the DKIM signature information for that selector. Hence, the client cannot provide constraints on the Local-part of addresses that get signed, but it can revoke the provider's signing rights by removing the DNS delegation record.
クライアントが、代表として派遣されたグループにDNS管理をして欲しいなら、それはセレクタポイントでプロバイダーのDNSサーバに指定されるドメイン名を持つことができます。次に、プロバイダーは、そのセレクタのためのDKIM署名情報のすべてを作成して、維持します。 したがって、クライアントはサインされるアドレスのLocal-部分の上で規制を提供できませんが、それは、DNS代表団記録を取り除くことによってプロバイダーが権利にサインするのを取り消すことができます。
B.1.2. PDAs and Similar Devices
B.1.2。 PDAと同様の装置
PDAs demonstrate the need for using multiple keys per domain. Suppose that John Doe wanted to be able to send messages using his corporate email address, jdoe@example.com, and his email device did not have the ability to make a Virtual Private Network (VPN) connection to the corporate network, either because the device is limited or because there are restrictions enforced by his Internet access provider. If the device was equipped with a private key registered for jdoe@example.com by the administrator of the example.com domain, and appropriate software to sign messages, John could sign the message on the device itself before transmission through the outgoing network of the access service provider.
PDAは複数の1ドメインあたりのキーを使用する必要性を示します。 そのジョン・ドウがVirtual兵士のNetwork(VPN)接続を企業ネットワークにする能力を彼の法人のEメールアドレス、 jdoe@example.com 、および彼のメール装置を使用するのが持っていなかったメッセージに送ることができるようになりたかったと仮定してください、装置が限られているか、または彼のインターネット・アクセス・プロバイダーによって励行された制限があるので。 装置はメッセージにサインするために jdoe@example.com のためにexample.comドメインの管理者によって登録された秘密鍵、および適切なソフトウェアを備えているなら、ジョンはアクセスサービスプロバイダーの出発しているネットワークを通したトランスミッションの前に装置自体でメッセージにサインできるでしょうに。
B.1.3. Roaming Users
B.1.3。 ローミングユーザ
Roaming users often find themselves in circumstances where it is convenient or necessary to use an SMTP server other than their home server; examples are conferences and many hotels. In such circumstances, a signature that is added by the submission service will use an identity that is different from the user's home system.
気付くと、ローミングユーザはそれらのホームサーバ以外のSMTPサーバーを使用するのが便利であるか、または必要である事情にしばしばいます。 例は、会議と多くのホテルです。 そのような事情では、服従サービスで加えられる署名はユーザの家のシステムと異なったアイデンティティを使用するでしょう。
Ideally, roaming users would connect back to their home server using either a VPN or a SUBMISSION server running with SMTP AUTHentication on port 587. If the signing can be performed on the roaming user's laptop, then they can sign before submission, although the risk of further modification is high. If neither of these are possible, these roaming users will not be able to send mail signed using their own domain key.
理想的に、ローミングユーザは、ポート587の上のSMTP AUTHenticationと共に走るVPNかSUBMISSIONサーバのどちらかを使用することで彼らのホームサーバに接続して戻るでしょう。 ローミングユーザのラップトップに調印を実行できるなら、彼らは服従の前にサインできます、さらなる変更のリスクが高いのですが。 これらのどちらも可能でないなら、これらのローミングユーザはそれら自身のドメインキーを使用することでサインされたメールを送ることができないでしょう。
B.1.4. Independent (Kiosk) Message Submission
B.1.4。 独立している(キオスク)メッセージ提案
Stand-alone services, such as walk-up kiosks and web-based information services, have no enduring email service relationship with the user, but users occasionally request that mail be sent on their behalf. For example, a website providing news often allows the reader to forward a copy of the article to a friend. This is typically done using the reader's own email address, to indicate who the author is. This is sometimes referred to as the "Evite problem",
エレベーターのない建物のキオスクやウェブベースの情報サービスなどのスタンドアロンのサービスには、ユーザとのどんな永続的なメールサービス関係もありませんが、ユーザは、時折メールが彼らに代わって送られるよう要求します。 例えば、ウェブサイト提供ニュースで、読者はしばしば記事のコピーを友人に送ることができます。 これは作者がだれであるかを示すのに読者の自己のEメールアドレスを使用し通常終わっています。 これは時々「Evite問題」と呼ばれます。
Allman, et al. Standards Track [Page 64] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[64ページ]。
named after the website of the same name that allows a user to send invitations to friends.
ユーザが招待状を友人に送ることができる同じ名前のウェブサイトにちなんで名付けられます。
A common way this is handled is to continue to put the reader's email address in the From header field of the message, but put an address owned by the email posting site into the Sender header field. The posting site can then sign the message, using the domain that is in the Sender field. This provides useful information to the receiving email site, which is able to correlate the signing domain with the initial submission email role.
これが扱われる一般的な方法がメッセージのFromヘッダーフィールドに読者のEメールアドレスを入れ続けることですが、メール任命サイトによってSenderヘッダーフィールドとして所有されていたアドレスを置いてください。 そして、Sender分野にあるドメインを使用して、任命サイトはメッセージにサインできます。 これは受信メールサイトに役に立つ情報を提供します。(それは、初期の服従メールの役割で調印ドメインを関連させることができます)。
Receiving sites often wish to provide their end users with information about mail that is mediated in this fashion. Although the real efficacy of different approaches is a subject for human factors usability research, one technique that is used is for the verifying system to rewrite the From header field, to indicate the address that was verified. For example: From: John Doe via news@news-site.com <jdoe@example.com>. (Note that such rewriting will break a signature, unless it is done after the verification pass is complete.)
しばしばサイトを受け取って、こんなやり方で伝えられるメールの情報を彼らのエンドユーザに提供することを願ってください。 異なるアプローチの本当の効力は人間の要素ユーザビリティ調査のための対象ですが、1つの使用されたテクニックは検証システムが確かめられたアドレスを示すためにFromヘッダーフィールドを書き直すことです。 例えば: From: news@news-site.com を通したジョン・ドウ、lt;、 jdoe@example.com 、gt。 (検証パスが完全になった後にそれをしない場合、そのような書き直しが署名を壊すことに注意してください。)
B.2. Alternate Delivery Scenarios
B.2。 代替配送シナリオ
Email is often received at a mailbox that has an address different from the one used during initial submission. In these cases, an intermediary mechanism operates at the address originally used and it then passes the message on to the final destination. This mediation process presents some challenges for DKIM signatures.
初期の服従の間に使用されるものと異なったアドレスを持っているメールボックスにしばしばメールを受け取ります。 これらの場合では、仲介者メカニズムは元々使用されたアドレスで作動します、そして、次に、それは最終的な目的地にメッセージを向かわせます。 この仲介の過程はDKIM署名のためのいくつかの挑戦を提示します。
B.2.1. Affinity Addresses
B.2.1。 親近感アドレス
"Affinity addresses" allow a user to have an email address that remains stable, even as the user moves among different email providers. They are typically associated with college alumni associations, professional organizations, and recreational organizations with which they expect to have a long-term relationship. These domains usually provide forwarding of incoming email, and they often have an associated Web application that authenticates the user and allows the forwarding address to be changed. However, these services usually depend on users sending outgoing messages through their own service providers' MTAs. Hence, mail that is signed with the domain of the affinity address is not signed by an entity that is administered by the organization owning that domain.
ユーザは「親近感アドレス」で安定した状態を保つEメールアドレスを持つことができます、ユーザが異なったメールプロバイダーの中で移るときさえ。 それらは長期の関係を持っているとそれらと予想する大学同窓会、専門家団体、およびレクリエーションの組織に通常関連しています。 通常、これらのドメインは入って来るメールの推進を提供します、そして、それらには、ユーザを認証して、フォーワーディング・アドレスが変えられるのを許容する関連ウェブアプリケーションがしばしばあります。 しかしながら、通常、これらのサービスはそれら自身のサービスプロバイダーのMTAsを通して送信されるメッセージを送るユーザに頼っています。 したがって、親近感アドレスのドメインを契約されるメールはそのドメインを所有している組織によって管理される実体によってサインされません。
With DKIM, affinity domains could use the Web application to allow users to register per-user keys to be used to sign messages on behalf of their affinity address. The user would take away the secret half
DKIMと共に、親近感ドメインは、ユーザがそれらの親近感アドレスを代表してメッセージにサインするのに使用されるために1ユーザあたりのキーを登録するのを許容するのにウェブアプリケーションを使用するかもしれません。 ユーザは秘密の半分を持ち去るでしょう。
Allman, et al. Standards Track [Page 65] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[65ページ]。
of the key pair for signing, and the affinity domain would publish the public half in DNS for access by verifiers.
キーでは、調印のために対にしてください。そうすれば、親近感ドメインはアクセスのためにDNSで検証で公共の半分を発行するでしょう。
This is another application that takes advantage of user-level keying, and domains used for affinity addresses would typically have a very large number of user-level keys. Alternatively, the affinity domain could handle outgoing mail, operating a mail submission agent that authenticates users before accepting and signing messages for them. This is of course dependent on the user's service provider not blocking the relevant TCP ports used for mail submission.
これはユーザレベルの合わせることを利用する別のアプリケーションです、そして、親近感アドレスに使用されるドメインは非常に多くのユーザレベルキーを通常持っているでしょう。 あるいはまた、親近感ドメインは送信するメールを扱うかもしれません、それらへのメッセージを受け入れて、サインする前にユーザを認証するメール服従エージェントを手術して。 これはもちろんメール提案に使用される関連TCPポートを妨げないユーザのサービスプロバイダーに依存しています。
B.2.2. Simple Address Aliasing (.forward)
B.2.2。 簡単なアドレスエイリアシング(.forward)
In some cases, a recipient is allowed to configure an email address to cause automatic redirection of email messages from the original address to another, such as through the use of a Unix .forward file. In this case, messages are typically redirected by the mail handling service of the recipient's domain, without modification, except for the addition of a Received header field to the message and a change in the envelope recipient address. In this case, the recipient at the final address' mailbox is likely to be able to verify the original signature since the signed content has not changed, and DKIM is able to validate the message signature.
いくつかの場合、受取人はオリジナルのアドレスから別のアドレスまでメールメッセージの自動リダイレクションを引き起こすためにEメールアドレスを構成できます、Unix .forwardファイルの使用などのように。 この場合、メッセージは受取人のドメインのメール取り扱いサービスで通常向け直されます、変更なしで、Receivedヘッダーフィールドのメッセージへの追加と封筒受取人アドレスにおける変化を除いて。 サインされた内容が変化していなくて、DKIMがメッセージ署名を有効にすることができるので、この場合、最終アドレスのメールボックスの受取人はオリジナルの署名について確かめることができそうです。
B.2.3. Mailing Lists and Re-Posters
B.2.3。 メーリングリストと再ポスター
There is a wide range of behaviors in services that take delivery of a message and then resubmit it. A primary example is with mailing lists (collectively called "forwarders" below), ranging from those that make no modification to the message itself, other than to add a Received header field and change the envelope information, to those that add header fields, change the Subject header field, add content to the body (typically at the end), or reformat the body in some manner. The simple ones produce messages that are quite similar to the automated alias services. More elaborate systems essentially create a new message.
メッセージの配送を取って、次にそれを再提出するサービスにおけるさまざまな振舞いがあります。 第一の例がメーリングリスト(以下にまとめて「混載業者」と呼ばれる)と共にあります、メッセージ自体への変更を全くしないものから変化して、Receivedヘッダーフィールドを加えて、封筒情報を変えるのを除いて、ボディー(通常終わりの)に内容を加えるか、Subjectヘッダーフィールドを変える、ヘッダーフィールドを加えるものに、再フォーマットは何らかの方法によるボディーを加えます。 簡単なものは自動化された別名サービスと全く同様のメッセージを出します。 より精巧なシステムは本質的には新しいメッセージを作成します。
A Forwarder that does not modify the body or signed header fields of a message is likely to maintain the validity of the existing signature. It also could choose to add its own signature to the message.
メッセージのボディーかサインされたヘッダーフィールドを変更しないForwarderは既存の署名の正当性を維持しそうです。 また、それは、それ自身の署名をメッセージに追加するのを選ぶかもしれません。
Forwarders which modify a message in a way that could make an existing signature invalid are particularly good candidates for adding their own signatures (e.g., mailing-list-name@example.net). Since (re-)signing is taking responsibility for the content of the message, these signing forwarders are likely to be selective, and forward or re-sign a message only if it is received with a valid
既存の署名を無効にすることができた方法でメッセージを変更する混載業者はそれら自身の署名(例えば、 mailing-list-name@example.net )を加える特に良い候補です。 以来、(再、)、調印がメッセージの内容への責任を取っていて、混載業者にサインするこれらは、選択していて、前進しているか、またはaが有効な状態でそれを受け取る場合にだけ、メッセージを再契約しそうです。
Allman, et al. Standards Track [Page 66] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[66ページ]。
signature or if they have some other basis for knowing that the message is not spoofed.
署名か彼らにメッセージがだまされないのを知るある他の基礎があるのであるかどうか。
A common practice among systems that are primarily redistributors of mail is to add a Sender header field to the message, to identify the address being used to sign the message. This practice will remove any preexisting Sender header field as required by [RFC2822]. The forwarder applies a new DKIM-Signature header field with the signature, public key, and related information of the forwarder.
主として、メールの「再-ディストリビュータ」がメッセージにサインするのに使用されるアドレスを特定するためにSenderヘッダーフィールドをメッセージに追加することになっているということであるシステムの中の一般的な習慣。 この習慣は、必要に応じて[RFC2822]でSenderヘッダーフィールドを先在させながら、いずれも取り除くでしょう。 混載業者は混載業者の署名、公開鍵、および関連する情報で新しいDKIM-署名ヘッダーフィールドを適用します。
Appendix C. Creating a Public Key (INFORMATIVE)
公開鍵を作成する付録C.(有益)です。
The default signature is an RSA signed SHA256 digest of the complete email. For ease of explanation, the openssl command is used to describe the mechanism by which keys and signatures are managed. One way to generate a 1024-bit, unencrypted private key suitable for DKIM is to use openssl like this:
デフォルト署名はサインされたSHA256が読みこなす完全なメールのRSAです。 説明の容易さにおいて、opensslコマンドは、キーと署名が管理されるメカニズムについて説明するのに使用されます。 DKIMに適当な1024年のビットの、そして、非コード化された秘密鍵を発生させる1つの方法はこのようにopensslを使用することです:
$ openssl genrsa -out rsa.private 1024
openssl genrsaの出ているrsa.private1024ドル
For increased security, the "-passin" parameter can also be added to encrypt the private key. Use of this parameter will require entering a password for several of the following steps. Servers may prefer to use hardware cryptographic support.
また、秘密鍵をコード化するために増加するセキュリティ、"-passin"パラメタを加えることができるので。 このパラメタの使用は、数個のためのパスワードを入力するのを以下のステップを要求するでしょう。 サーバは、ハードウェアの暗号のサポートを使用するのを好むかもしれません。
The "genrsa" step results in the file rsa.private containing the key information similar to this:
"genrsa"ステップはこれと同様の主要な情報を含むファイルrsa.privateをもたらします:
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
-----END RSA PRIVATE KEY-----
-----RSA秘密鍵を始めてください。----- /NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyOへのMIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb; -----終わりのRSA秘密鍵-----
To extract the public-key component from the private key, use openssl like this:
秘密鍵から公開カギコンポーネントを抽出するには、このようにopensslを使用してください:
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
$openssl rsaコネrsa.privateアウトrsa.public -pubout -outform PEM
Allman, et al. Standards Track [Page 67] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[67ページ]。
This results in the file rsa.public containing the key information similar to this:
これはこれと同様の主要な情報を含むファイルrsa.publicをもたらします:
-----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI MmPSPDdQPNUYckcQ2QIDAQAB -----END PUBLIC KEY-----
-----公開鍵を始めてください。----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI MmPSPDdQPNUYckcQ2QIDAQAB -----終わりの公開鍵-----
This public-key data (without the BEGIN and END tags) is placed in the DNS:
この公開カギデータ(BEGINとENDタグのない)はDNSに置かれます:
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
brisbane IN TXT「(「v=DKIM1;、p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ」 「KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt」 「IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v」」/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi」"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
Appendix D. MUA Considerations
付録D.MUA問題
When a DKIM signature is verified, the processing system sometimes makes the result available to the recipient user's MUA. How to present this information to the user in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the address associated with this signing identity in some way, in an attempt to show the user the address from which the mail was sent. An MUA might do this with visual cues such as graphics, or it might include the address in an alternate view, or it might even rewrite the original From address using the verified information. Some MUAs might indicate which header fields were protected by the validated DKIM signature. This could be done with a positive indication on the signed header fields, with a negative indication on the unsigned header fields, by visually hiding the unsigned header fields, or some combination of these. If an MUA uses visual indications for signed header fields, the MUA probably needs to be careful not to display unsigned header fields in a way that might be construed by the end user as having been signed. If the message has an l= tag whose value does not extend to the end of the message, the MUA might also hide or mark the portion of the message body that was not signed.
DKIM署名が確かめられるとき、処理システムで、結果は時々受取人ユーザのMUAに利用可能になります。 どうそれらを助ける方法でこの情報をユーザに提示するかは、人間の要素ユーザビリティ研究を続ける問題です。 傾向はMUAに何らかの方法でアイデンティティにサインするこれに関連しているアドレスを強調させることです、メールが送られたアドレスをユーザに示している試みで。 MUAがグラフィックスなどの視覚的な合図でこれをするかもしれませんか、交互の視点にアドレスを含むかもしれませんか、またはそれは、確かめられた情報を使用することでオリジナルのFromアドレスを書き直しさえするかもしれません。 いくつかのMUAsが、どのヘッダーフィールドが有効にされたDKIM署名で保護されたかを示すかもしれません。 これは、サインされたヘッダーフィールドにおける積極的な指示、負の符号表示が目視により無記名のヘッダーフィールドを隠すのによる無記名のヘッダーフィールドにある状態でしていてこれらの何らかの組み合わせであるかもしれません。 MUAがサインされたヘッダーフィールドに視覚指摘を使用するなら、MUAは、たぶんサインされたとしてエンドユーザによって解釈されるかもしれない方法で無記名のヘッダーフィールドを表示しないように慎重である必要があります。 メッセージが値がメッセージの終わりに達しないl=タグを持っているなら、また、MUAはサインされなかったメッセージ本体の一部を隠すか、または示すかもしれません。
The aforementioned information is not intended to be exhaustive. The MUA may choose to highlight, accentuate, hide, or otherwise display any other information that may, in the opinion of the MUA author, be deemed important to the end user.
前述の情報が徹底的であることを意図しません。 MUAは、MUA作者の意見でエンドユーザにとって重要であると考えられるかもしれないいかなる他の情報も強調するか、強調するか、隠すか、またはそうでなければ、表示するのを選ぶかもしれません。
Allman, et al. Standards Track [Page 68] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[68ページ]。
Appendix E. Acknowledgements
付録E.承認
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing for their valuable suggestions and constructive criticism.
作者はラスAllbery、エドウィン・青木、クラウスAssmann、スティーブ・アトキンス、ロブAustein、フレッド・ベイカー、マークBaugher、スティーブBellovin、ナザニエルBorenstein、デーヴ・クロッカー、マイケル・クダヒーに感謝したがっています、デニスDayman、ユッタDegener、フランクEllermann、パトリクFaeltstroem、マークFanto、スティーブン・ファレル、ダンカン・フィンドレイ、エリオットGillum、Olafur Guethmundsson、フィリップ・ハラム-ベイカー、トニー・ハンセン、サム・ハートマン、Arvel Hathcock、Amirハーズバーグ、ポール・ホフマン、ラスHousley、クレイグ・ヒューズ、Cullenジョニングス、ドン・ジョンセン、ハリー・キャッツ、マレーS; 彼らの貴重な提案と建設的批判のためのKucherawy、バリーLeiba、ジョン・レヴィン、チャールズ・リンジー、サイモンLongsdale、デヴィッドMargrave、ジャスティン・メイスン、デヴィッド・メイン、ティエリー・モロー、スティーブ・マーフィー、ラッセル・ネルソン、デーヴ・オラン、ダグオーティス、Shamim Pirzada、ホアンAltmayer Pizzorno、Sanjay Pol、ブレークRamsdell、クリスチャンのレノード、スコット・レンフロー、ニールRerup、エリック・レスコラ、デーヴ・ロゼッティ、ヘクトル・サントス、ジムSchaad、Spamhaus.orgチーム、Malte S.Stretz、ロバートSanders、Randワッカー、サム・ウィーラー、およびダンWing。
The DomainKeys specification was a primary source from which this specification has been derived. Further information about DomainKeys is at [RFC4870].
DomainKeys仕様はこの仕様が引き出された一次資料でした。 DomainKeysに関する詳細が[RFC4870]にあります。
Authors' Addresses
作者のアドレス
Eric Allman Sendmail, Inc. 6425 Christie Ave, Suite 400 Emeryville, CA 94608 USA
クリスティAve、エリックオールマンセンドメールInc.6425Suite400カリフォルニア94608エマリービル(米国)
Phone: +1 510 594 5501 EMail: eric+dkim@sendmail.org URI:
以下に電話をしてください。 +1 5501年の510 594メール: eric+ dkim@sendmail.org URI:
Jon Callas PGP Corporation 3460 West Bayshore Palo Alto, CA 94303 USA
西ジョンカラスPGP社3460のBayshoreカリフォルニア94303パロアルト(米国)
Phone: +1 650 319 9016 EMail: jon@pgp.com
以下に電話をしてください。 +1 9016年の650 319メール: jon@pgp.com
Allman, et al. Standards Track [Page 69] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[69ページ]。
Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
マークディラニーYahoo!Inc701First Avenueカリフォルニア95087サニーベル(米国)
Phone: +1 408 349 6831 EMail: markd+dkim@yahoo-inc.com URI:
以下に電話をしてください。 +1 6831年の408 349メール: markd+ dkim@yahoo-inc.com URI:
Miles Libbey Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
マイルリッベイYahoo!Inc701First Avenueカリフォルニア95087サニーベル(米国)
EMail: mlibbeymail-mailsig@yahoo.com URI:
メール: mlibbeymail-mailsig@yahoo.com ユリ:
Jim Fenton Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706 USA
ジムフェントンシスコシステムズInc.MS SJ-9/2 170W.タスマン・Driveカリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 526 5914 EMail: fenton@cisco.com URI:
以下に電話をしてください。 +1 5914年の408 526メール: fenton@cisco.com ユリ:
Michael Thomas Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706
マイケル・トーマス・シスコシステムズInc.MS SJ-9/2 170W.タスマン・Driveサンノゼ、カリフォルニア95134-1706
Phone: +1 408 525 5386 EMail: mat@cisco.com
以下に電話をしてください。 +1 5386年の408 525メール: mat@cisco.com
Allman, et al. Standards Track [Page 70] RFC 4871 DKIM Signatures May 2007
オールマン、他 規格はDKIM署名2007年5月にRFC4871を追跡します[70ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Allman, et al. Standards Track [Page 71]
オールマン、他 標準化過程[71ページ]
一覧
スポンサーリンク
