draft-ietf-dkim-rfc4871bis-06.txt | draft-ietf-dkim-rfc4871bis-07.txt | |||
---|---|---|---|---|
Network Working Group D. Crocker, Ed. | Network Working Group D. Crocker, Ed. | |||
Internet-Draft Brandenburg InternetWorking | Internet-Draft Brandenburg InternetWorking | |||
Obsoletes: 4871 (if approved) T. Hansen, Ed. | Obsoletes: 4871, 5672 T. Hansen, Ed. | |||
Intended status: Standards Track AT&T Laboratories | (if approved) AT&T Laboratories | |||
Expires: October 14, 2011 M. Kucherawy, Ed. | Intended status: Standards Track M. Kucherawy, Ed. | |||
Cloudmark | Expires: October 26, 2011 Cloudmark | |||
April 12, 2011 | April 24, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-06 | draft-ietf-dkim-rfc4871bis-07 | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) permits a person, role, or | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
organization that owns the signing domain to claim some | organization that owns the signing domain to claim some | |||
responsibility for a message by associating the domain with the | responsibility for a message by associating the domain with the | |||
message. This can be an author's organization, an operational relay | message. This can be an author's organization, an operational relay | |||
or one of their agents. DKIM separates the question of the identity | or one of their agents. DKIM separates the question of the identity | |||
of the signer of the message from the purported author of the | of the signer of the message from the purported author of the | |||
message. Assertion of responsibility is validated through a | message. Assertion of responsibility is validated through a | |||
cryptographic signature and querying the signer's domain directly to | cryptographic signature and querying the signer's domain directly to | |||
retrieve the appropriate public key. Message transit from author to | retrieve the appropriate public key. Message transit from author to | |||
recipient is through relays that typically make no substantive change | recipient is through relays that typically make no substantive change | |||
to the message content and thus preserve the DKIM signature. | to the message content and thus preserve the DKIM signature. | |||
This memo obsoletes RFC4871 and RFC5672 {DKIM 14}. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 14, 2011. | This Internet-Draft will expire on October 26, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Notes to Editor and Reviewers . . . . . . . . . . . . . . . . 5 | |||
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 | 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 | 2.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 | |||
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 | 3.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 | 3.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 8 | |||
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 | 3.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 | |||
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 | |||
2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | 3.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | 3.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | |||
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 | 3.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 | 3.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 | |||
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 | 4.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 | 4.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 | |||
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | 4.3. Signing and Verification Algorithms . . . . . . . . . . . 14 | |||
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | 4.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | |||
3.6. Key Management and Representation . . . . . . . . . . . . 28 | 4.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 20 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | 4.6. Key Management and Representation . . . . . . . . . . . . 29 | |||
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | 4.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | |||
3.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 | 4.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 36 | |||
3.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 | 4.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 | 4.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 | |||
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | 5. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 | |||
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | 5.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | 5.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.1. Determine Whether the Email Should Be Signed and by | 6. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 6.1. Determine Whether the Email Should Be Signed and by | |||
5.2. Select a Private Key and Corresponding Selector | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
6.2. Select a Private Key and Corresponding Selector | ||||
Information . . . . . . . . . . . . . . . . . . . . . . . 40 | Information . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
5.3. Normalize the Message to Prevent Transport Conversions . . 40 | 6.3. Normalize the Message to Prevent Transport Conversions . . 41 | |||
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | 6.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | |||
5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | 6.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 | 6.6. Compute the Message Hash and Signature . . . . . . . . . . 45 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | 6.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 | 7. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | 7.1. Extract Signatures from the Message . . . . . . . . . . . 46 | |||
6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | 7.2. Communicate Verification Results . . . . . . . . . . . . . 52 | |||
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | 7.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | 8.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | |||
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | 8.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | |||
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | 8.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | |||
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | 8.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 | |||
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | 8.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 | |||
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | 8.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | |||
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | 8.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | |||
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | 8.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 | |||
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | 8.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | |||
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | 9.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | |||
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | 9.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | |||
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | 9.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | |||
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | 9.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | |||
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 | 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 | |||
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 61 | 9.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 61 | |||
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 | 9.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | 9.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | |||
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | 9.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | |||
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | 9.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | |||
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | 9.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | |||
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 | 9.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 | |||
8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | 9.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | |||
8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 | 9.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 65 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 65 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | |||
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | |||
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 | |||
A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | |||
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 | |||
1. Introduction | 1. Notes to Editor and Reviewers | |||
This version of the memo contains notations such as "{DKIM 2}". | ||||
These correspond to DKIM working group issue tracker items. they | ||||
should be deleted prior to publication. | ||||
2. Introduction | ||||
DomainKeys Identified Mail (DKIM) permits a person, role, or | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
organization to claim some responsibility for a message by | organization to claim some responsibility for a message by | |||
associating a domain name [RFC1034] with the message [RFC5322], which | associating a domain name [RFC1034] with the message [RFC5322], which | |||
they are authorized to use. This can be an author's organization, an | they are authorized to use. This can be an author's organization, an | |||
operational relay or one of their agents. Assertion of | operational relay or one of their agents. Assertion of | |||
responsibility is validated through a cryptographic signature and | responsibility is validated through a cryptographic signature and | |||
querying the signer's domain directly to retrieve the appropriate | querying the signer's domain directly to retrieve the appropriate | |||
public key. Message transit from author to recipient is through | public key. Message transit from author to recipient is through | |||
relays that typically make no substantive change to the message | relays that typically make no substantive change to the message | |||
skipping to change at page 6, line 9 | skipping to change at page 6, line 14 | |||
o requires minimal new infrastructure; | o requires minimal new infrastructure; | |||
o can be implemented independently of clients in order to reduce | o can be implemented independently of clients in order to reduce | |||
deployment time; | deployment time; | |||
o can be deployed incrementally; | o can be deployed incrementally; | |||
o allows delegation of signing to third parties. | o allows delegation of signing to third parties. | |||
1.1. Signing Identity | 2.1. Signing Identity | |||
DKIM separates the question of the identity of the signer of the | DKIM separates the question of the identity of the signer of the | |||
message from the purported author of the message. In particular, a | message from the purported author of the message. In particular, a | |||
signature includes the identity of the signer. Verifiers can use the | signature includes the identity of the signer. Verifiers can use the | |||
signing information to decide how they want to process the message. | signing information to decide how they want to process the message. | |||
The signing identity is included as part of the signature header | The signing identity is included as part of the signature header | |||
field. | field. | |||
INFORMATIVE RATIONALE: The signing identity specified by a DKIM | INFORMATIVE RATIONALE: The signing identity specified by a DKIM | |||
signature is not required to match an address in any particular | signature is not required to match an address in any particular | |||
header field because of the broad methods of interpretation by | header field because of the broad methods of interpretation by | |||
recipient mail systems, including MUAs. | recipient mail systems, including MUAs. | |||
1.2. Scalability | 2.2. Scalability | |||
DKIM is designed to support the extreme scalability requirements that | DKIM is designed to support the extreme scalability requirements that | |||
characterize the email identification problem. There are currently | characterize the email identification problem. There are currently | |||
over 70 million domains and a much larger number of individual | over 70 million domains and a much larger number of individual | |||
addresses. DKIM seeks to preserve the positive aspects of the | addresses. DKIM seeks to preserve the positive aspects of the | |||
current email infrastructure, such as the ability for anyone to | current email infrastructure, such as the ability for anyone to | |||
communicate with anyone else without introduction. | communicate with anyone else without introduction. | |||
1.3. Simple Key Management | 2.3. Simple Key Management | |||
DKIM differs from traditional hierarchical public-key systems in that | DKIM differs from traditional hierarchical public-key systems in that | |||
no Certificate Authority infrastructure is required; the verifier | no Certificate Authority infrastructure is required; the verifier | |||
requests the public key from a repository in the domain of the | requests the public key from a repository in the domain of the | |||
claimed signer directly rather than from a third party. | claimed signer directly rather than from a third party. | |||
The DNS is proposed as the initial mechanism for the public keys. | The DNS is proposed as the initial mechanism for the public keys. | |||
Thus, DKIM currently depends on DNS administration and the security | Thus, DKIM currently depends on DNS administration and the security | |||
of the DNS system. DKIM is designed to be extensible to other key | of the DNS system. DKIM is designed to be extensible to other key | |||
fetching services as they become available. | fetching services as they become available. | |||
1.4. Data Integrity | 2.4. Data Integrity | |||
A DKIM signature associates the d= name with the computed hash of | A DKIM signature associates the d= name with the computed hash of | |||
some or all of the message (see Section 3.7) in order to prevent the | some or all of the message (see Section 3.7) in order to prevent the | |||
re-use of the signature with different messages. Verifying the | re-use of the signature with different messages. Verifying the | |||
signature asserts that the hashed content has not changed since it | signature asserts that the hashed content has not changed since it | |||
was signed, and asserts nothing else about "protecting" the end-to- | was signed, and asserts nothing else about "protecting" the end-to- | |||
end integrity of the message. | end integrity of the message. | |||
2. Terminology and Definitions | 3. Terminology and Definitions | |||
This section defines terms used in the rest of the document. | This section defines terms used in the rest of the document. | |||
DKIM is designed to operate within the Internet Mail service, as | DKIM is designed to operate within the Internet Mail service, as | |||
defined in [RFC5598]. Basic email terminology is taken from that | defined in [RFC5598]. Basic email terminology is taken from that | |||
specification. | specification. | |||
Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. | Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
2.1. Signers | 3.1. Signers | |||
Elements in the mail system that sign messages on behalf of a domain | 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), | are referred to as signers. These may be MUAs (Mail User Agents), | |||
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other | MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other | |||
agents such as mailing list exploders. In general, any signer will | agents such as mailing list exploders. In general, any signer will | |||
be involved in the injection of a message into the message system in | 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 | some way. The key issue is that a message must be signed before it | |||
leaves the administrative domain of the signer. | leaves the administrative domain of the signer. | |||
2.2. Verifiers | 3.2. Verifiers | |||
Elements in the mail system that verify signatures are referred to as | Elements in the mail system that verify signatures are referred to as | |||
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. | 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 | 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 | user (reader) of the message or some consuming agent such as a | |||
mailing list exploder. | mailing list exploder. | |||
2.3. Identity | 3.3. Identity | |||
A person, role, or organization. In the context of DKIM, examples | A person, role, or organization. In the context of DKIM, examples | |||
include the author, the author's organization, an ISP along the | include the author, the author's organization, an ISP along the | |||
handling path, an independent trust assessment service, and a mailing | handling path, an independent trust assessment service, and a mailing | |||
list operator. | list operator. | |||
2.4. Identifier | 3.4. Identifier | |||
A label that refers to an identity. | A label that refers to an identity. | |||
2.5. Signing Domain Identifier (SDID) | 3.5. Signing Domain Identifier (SDID) | |||
A single domain name that is the mandatory payload output of DKIM and | A single domain name that is the mandatory payload output of DKIM and | |||
that refers to the identity claiming responsibility for introduction | that refers to the identity claiming responsibility for introduction | |||
of a message into the mail stream. For DKIM processing, the name has | of a message into the mail stream. For DKIM processing, the name has | |||
only basic domain name semantics; any possible owner-specific | only basic domain name semantics; any possible owner-specific | |||
semantics are outside the scope of DKIM. It is specified in | semantics are outside the scope of DKIM. It is specified in | |||
Section 3.5. | Section 4.5. | |||
2.6. Agent or User Identifier (AUID) | 3.6. Agent or User Identifier (AUID) | |||
A single identifier that refers to the agent or user on behalf of | A single identifier that refers to the agent or user on behalf of | |||
whom the Signing Domain Identifier (SDID) has taken responsibility. | whom the Signing Domain Identifier (SDID) has taken responsibility. | |||
The AUID comprises a domain name and an optional <Local-part>. The | The AUID comprises a domain name and an optional <Local-part>. The | |||
domain name is the same as that used for the SDID or is a sub-domain | domain name is the same as that used for the SDID or is a sub-domain | |||
of it. For DKIM processing, the domain name portion of the AUID has | of it. For DKIM processing, the domain name portion of the AUID has | |||
only basic domain name semantics; any possible owner-specific | only basic domain name semantics; any possible owner-specific | |||
semantics are outside the scope of DKIM. It is specified in | semantics are outside the scope of DKIM. It is specified in | |||
Section 3.5 . | Section 4.5 . | |||
2.7. Identity Assessor | 3.7. Identity Assessor | |||
A module that consumes DKIM's mandatory payload, which is the | A module that consumes DKIM's mandatory payload, which is the | |||
responsible Signing Domain Identifier (SDID). The module is | responsible Signing Domain Identifier (SDID). The module is | |||
dedicated to the assessment of the delivered identifier. Other DKIM | dedicated to the assessment of the delivered identifier. Other DKIM | |||
(and non-DKIM) values can also be delivered to this module as well as | (and non-DKIM) values can also be delivered to this module as well as | |||
to a more general message evaluation filtering engine. However, this | to a more general message evaluation filtering engine. However, this | |||
additional activity is outside the scope of the DKIM signature | additional activity is outside the scope of the DKIM signature | |||
specification. | specification. | |||
2.8. Whitespace | 3.8. Whitespace | |||
There are three forms of whitespace: | There are three forms of whitespace: | |||
o WSP represents simple whitespace, i.e., a space or a tab character | o WSP represents simple whitespace, i.e., a space or a tab character | |||
(formal definition in [RFC5234]). | (formal definition in [RFC5234]). | |||
o LWSP is linear whitespace, defined as WSP plus CRLF (formal | o LWSP is linear whitespace, defined as WSP plus CRLF (formal | |||
definition in [RFC5234]). | definition in [RFC5234]). | |||
o FWS is folding whitespace. It allows multiple lines separated by | o FWS is folding whitespace. It allows multiple lines separated by | |||
skipping to change at page 9, line 5 | skipping to change at page 9, line 14 | |||
The formal ABNF for these are (WSP and LWSP are given for information | The formal ABNF for these are (WSP and LWSP are given for information | |||
only): | only): | |||
WSP = SP / HTAB | WSP = SP / HTAB | |||
LWSP = *(WSP / CRLF WSP) | LWSP = *(WSP / CRLF WSP) | |||
FWS = [*WSP CRLF] 1*WSP | FWS = [*WSP CRLF] 1*WSP | |||
The definition of FWS is identical to that in [RFC5322] except for | The definition of FWS is identical to that in [RFC5322] except for | |||
the exclusion of obs-FWS. | the exclusion of obs-FWS. | |||
2.9. Imported ABNF Tokens | 3.9. Imported ABNF Tokens | |||
The following tokens are imported from other RFCs as noted. Those | The following tokens are imported from other RFCs as noted. Those | |||
RFCs should be considered definitive. | RFCs should be considered definitive. | |||
The following tokens are imported from [RFC5321]: | The following tokens are imported from [RFC5321]: | |||
o "Local-part" (implementation warning: this permits quoted strings) | o "Local-part" (implementation warning: this permits quoted strings) | |||
o "sub-domain" | o "sub-domain" | |||
skipping to change at page 9, line 36 | skipping to change at page 9, line 45 | |||
o "hex-octet" (a quoted-printable encoded octet) | o "hex-octet" (a quoted-printable encoded octet) | |||
INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not | INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not | |||
obey the rules of [RFC5234] and must be interpreted accordingly, | obey the rules of [RFC5234] and must be interpreted accordingly, | |||
particularly as regards case folding. | particularly as regards case folding. | |||
Other tokens not defined herein are imported from [RFC5234]. These | Other tokens not defined herein are imported from [RFC5234]. These | |||
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, | are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, | |||
etc. | etc. | |||
2.10. Common ABNF Tokens | 3.10. Common ABNF Tokens | |||
The following ABNF tokens are used elsewhere in this document: | The following ABNF tokens are used elsewhere in this document: | |||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | |||
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") | ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") | |||
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) | base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) | |||
[ [FWS] "=" [ [FWS] "=" ] ] | [ [FWS] "=" [ [FWS] "=" ] ] | |||
hdr-name = field-name | hdr-name = field-name | |||
qp-hdr-value = dkim-quoted-printable ; with "|" encoded | qp-hdr-value = dkim-quoted-printable ; with "|" encoded | |||
2.11. DKIM-Quoted-Printable | 3.11. DKIM-Quoted-Printable | |||
The DKIM-Quoted-Printable encoding syntax resembles that described in | The DKIM-Quoted-Printable encoding syntax resembles that described in | |||
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded | Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded | |||
as an "=" followed by two hexadecimal digits from the alphabet | as an "=" followed by two hexadecimal digits from the alphabet | |||
"0123456789ABCDEF" (no lowercase characters permitted) representing | "0123456789ABCDEF" (no lowercase characters permitted) representing | |||
the hexadecimal-encoded integer value of that character. All control | the hexadecimal-encoded integer value of that character. All control | |||
characters (those with values < %x20), 8-bit characters (values > | characters (those with values < %x20), 8-bit characters (values > | |||
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon | %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon | |||
(";", %x3B) MUST be encoded. Note that all whitespace, including | (";", %x3B) MUST be encoded. Note that all whitespace, including | |||
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS | SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS | |||
skipping to change at page 10, line 43 | skipping to change at page 11, line 13 | |||
the case here. | the case here. | |||
3. The "soft line break" syntax ("=" as the last non-whitespace | 3. The "soft line break" syntax ("=" as the last non-whitespace | |||
character on the line) does not apply. | character on the line) does not apply. | |||
4. DKIM-Quoted-Printable does not require that encoded lines be | 4. DKIM-Quoted-Printable does not require that encoded lines be | |||
no more than 76 characters long (although there may be other | no more than 76 characters long (although there may be other | |||
requirements depending on the context in which the encoded | requirements depending on the context in which the encoded | |||
text is being used). | text is being used). | |||
3. Protocol Elements | 4. Protocol Elements | |||
Protocol Elements are conceptual parts of the protocol that are not | Protocol Elements are conceptual parts of the protocol that are not | |||
specific to either signers or verifiers. The protocol descriptions | specific to either signers or verifiers. The protocol descriptions | |||
for signers and verifiers are described in later sections (Signer | for signers and verifiers are described in later sections (Signer | |||
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This | Actions (Section 6) and Verifier Actions (Section 7)). NOTE: This | |||
section must be read in the context of those sections. | section must be read in the context of those sections. | |||
3.1. Selectors | 4.1. Selectors | |||
To support multiple concurrent public keys per signing domain, the | To support multiple concurrent public keys per signing domain, the | |||
key namespace is subdivided using "selectors". For example, | key namespace is subdivided using "selectors". For example, | |||
selectors might indicate the names of office locations (e.g., | selectors might indicate the names of office locations (e.g., | |||
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date | "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date | |||
(e.g., "january2005", "february2005", etc.), or even an individual | (e.g., "january2005", "february2005", etc.), or even an individual | |||
user. | user. | |||
Selectors are needed to support some important use cases. For | Selectors are needed to support some important use cases. For | |||
example: | example: | |||
skipping to change at page 12, line 37 | skipping to change at page 13, line 5 | |||
value, such as a fingerprint of the public key. | value, such as a fingerprint of the public key. | |||
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key | INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key | |||
(for example, changing the key associated with a user's name) | (for example, changing the key associated with a user's name) | |||
makes it impossible to tell the difference between a message that | makes it impossible to tell the difference between a message that | |||
didn't verify because the key is no longer valid versus a message | didn't verify because the key is no longer valid versus a message | |||
that is actually forged. For this reason, signers are ill-advised | that is actually forged. For this reason, signers are ill-advised | |||
to reuse selectors for new keys. A better strategy is to assign | to reuse selectors for new keys. A better strategy is to assign | |||
new keys to new selectors. | new keys to new selectors. | |||
3.2. Tag=Value Lists | 4.2. Tag=Value Lists | |||
DKIM uses a simple "tag=value" syntax in several contexts, including | DKIM uses a simple "tag=value" syntax in several contexts, including | |||
in messages and domain signature records. | in messages and domain signature records. | |||
Values are a series of strings containing either plain text, "base64" | Values are a series of strings containing either plain text, "base64" | |||
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, | text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, | |||
Section 6.7), or "dkim-quoted-printable" (as defined in | Section 6.7), or "dkim-quoted-printable" (as defined in | |||
Section 2.11). The name of the tag will determine the encoding of | Section 3.11). The name of the tag will determine the encoding of | |||
each value. Unencoded semicolon (";") characters MUST NOT occur in | each value. Unencoded semicolon (";") characters MUST NOT occur in | |||
the tag value, since that separates tag-specs. | the tag value, since that separates tag-specs. | |||
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | |||
below (as "tag-value") only includes 7-bit characters, an | below (as "tag-value") only includes 7-bit characters, an | |||
implementation that wished to anticipate future standards would be | implementation that wished to anticipate future standards would be | |||
advised not to preclude the use of UTF8-encoded text in tag=value | advised not to preclude the use of UTF8-encoded text in tag=value | |||
lists. | lists. | |||
Formally, the ABNF syntax rules are as follows: | Formally, the ABNF syntax rules are as follows: | |||
skipping to change at page 13, line 41 | skipping to change at page 14, line 11 | |||
Tag=value pairs that represent the default value MAY be included to | Tag=value pairs that represent the default value MAY be included to | |||
aid legibility. | aid legibility. | |||
Unrecognized tags MUST be ignored. | Unrecognized tags MUST be ignored. | |||
Tags that have an empty value are not the same as omitted tags. An | 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 | omitted tag is treated as having the default value; a tag with an | |||
empty value explicitly designates the empty string as the value. | empty value explicitly designates the empty string as the value. | |||
3.3. Signing and Verification Algorithms | 4.3. Signing and Verification Algorithms | |||
DKIM supports multiple digital signature algorithms. Two algorithms | DKIM supports multiple digital signature algorithms. Two algorithms | |||
are defined by this specification at this time: rsa-sha1 and rsa- | are defined by this specification at this time: rsa-sha1 and rsa- | |||
sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | sha256. Signers MUST implement and SHOULD sign using rsa-sha256. | |||
Verifiers MUST implement rsa-sha256. | Verifiers MUST implement rsa-sha256. | |||
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some | INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some | |||
senders of low-security messages (such as routine newsletters) may | senders of low-security messages (such as routine newsletters) may | |||
prefer to use sha1 because of reduced CPU requirements to compute | prefer to use rsa-sha1 because of reduced CPU requirements to | |||
a sha1 hash. In general, sha256 should always be used whenever | compute a SHA1 hash. MTAs with compliant verifierst that do not | |||
possible. | implement rsa-sha1 will treat such messages as unsigned. {DKIM 13} | |||
In general, rsa-sha256 should always be used whenever possible. | ||||
3.3.1. The rsa-sha1 Signing Algorithm | 4.3.1. The rsa-sha1 Signing Algorithm | |||
The rsa-sha1 Signing Algorithm computes a message hash as described | 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. | in Section 4.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 | 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 | (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 | signer's private key. The hash MUST NOT be truncated or converted | |||
into any form other than the native binary form before being signed. | into any form other than the native binary form before being signed. | |||
The signing algorithm SHOULD use a public exponent of 65537. | The signing algorithm SHOULD use a public exponent of 65537. | |||
3.3.2. The rsa-sha256 Signing Algorithm | 4.3.2. The rsa-sha256 Signing Algorithm | |||
The rsa-sha256 Signing Algorithm computes a message hash as described | 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. | in Section 4.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 | 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 | (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 | signer's private key. The hash MUST NOT be truncated or converted | |||
into any form other than the native binary form before being signed. | into any form other than the native binary form before being signed. | |||
3.3.3. Key Sizes | 4.3.3. Key Sizes | |||
Selecting appropriate key sizes is a trade-off between cost, | Selecting appropriate key sizes is a trade-off between cost, | |||
performance, and risk. Since short RSA keys more easily succumb to | 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 | 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 | 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 | keys ranging from 512 bits to 2048 bits, and they MAY be able to | |||
validate signatures with larger keys. Verifier policies may use the | validate signatures with larger keys. Verifier policies may use the | |||
length of the signing key as one metric for determining whether a | length of the signing key as one metric for determining whether a | |||
signature is acceptable. | signature is acceptable. | |||
skipping to change at page 15, line 10 | skipping to change at page 15, line 25 | |||
o Larger keys impose higher CPU costs to verify and sign email | o Larger keys impose higher CPU costs to verify and sign email | |||
o Keys can be replaced on a regular basis, thus their lifetime can | o Keys can be replaced on a regular basis, thus their lifetime can | |||
be relatively short | be relatively short | |||
o The security goals of this specification are modest compared to | o The security goals of this specification are modest compared to | |||
typical goals of other systems that employ digital signatures | typical goals of other systems that employ digital signatures | |||
See [RFC3766] for further discussion on selecting key sizes. | See [RFC3766] for further discussion on selecting key sizes. | |||
3.3.4. Other Algorithms | 4.3.4. Other Algorithms | |||
Other algorithms MAY be defined in the future. Verifiers MUST ignore | Other algorithms MAY be defined in the future. Verifiers MUST ignore | |||
any signatures using algorithms that they do not implement. | any signatures using algorithms that they do not implement. | |||
3.4. Canonicalization | 4.4. Canonicalization | |||
Some mail systems modify email in transit, potentially invalidating a | Some mail systems modify email in transit, potentially invalidating a | |||
signature. For most signers, mild modification of email is | signature. For most signers, mild modification of email is | |||
immaterial to validation of the DKIM domain name's use. For such | immaterial to validation of the DKIM domain name's use. For such | |||
signers, a canonicalization algorithm that survives modest in-transit | signers, a canonicalization algorithm that survives modest in-transit | |||
modification is preferred. | modification is preferred. | |||
Other signers demand that any modification of the email, however | Other signers demand that any modification of the email, however | |||
minor, result in a signature verification failure. These signers | minor, result in a signature verification failure. These signers | |||
prefer a canonicalization algorithm that does not tolerate in-transit | prefer a canonicalization algorithm that does not tolerate in-transit | |||
skipping to change at page 15, line 52 | skipping to change at page 16, line 19 | |||
algorithms MAY be defined in the future; verifiers MUST ignore any | algorithms MAY be defined in the future; verifiers MUST ignore any | |||
signatures that use unrecognized canonicalization algorithms. | signatures that use unrecognized canonicalization algorithms. | |||
Canonicalization simply prepares the email for presentation to the | Canonicalization simply prepares the email for presentation to the | |||
signing or verification algorithm. It MUST NOT change the | signing or verification algorithm. It MUST NOT change the | |||
transmitted data in any way. Canonicalization of header fields and | transmitted data in any way. Canonicalization of header fields and | |||
body are described below. | body are described below. | |||
NOTE: This section assumes that the message is already in "network | NOTE: This section assumes that the message is already in "network | |||
normal" format (text is ASCII encoded, lines are separated with CRLF | normal" format (text is ASCII encoded, lines are separated with CRLF | |||
characters, etc.). See also Section 5.3 for information about | characters, etc.). See also Section 6.3 for information about | |||
normalizing the message. | normalizing the message. | |||
3.4.1. The "simple" Header Canonicalization Algorithm | 4.4.1. The "simple" Header Canonicalization Algorithm | |||
The "simple" header canonicalization algorithm does not change header | The "simple" header canonicalization algorithm does not change header | |||
fields in any way. Header fields MUST be presented to the signing or | fields in any way. Header fields MUST be presented to the signing or | |||
verification algorithm exactly as they are in the message being | verification algorithm exactly as they are in the message being | |||
signed or verified. In particular, header field names MUST NOT be | signed or verified. In particular, header field names MUST NOT be | |||
case folded and whitespace MUST NOT be changed. | case folded and whitespace MUST NOT be changed. | |||
3.4.2. The "relaxed" Header Canonicalization Algorithm | 4.4.2. The "relaxed" Header Canonicalization Algorithm | |||
The "relaxed" header canonicalization algorithm MUST apply the | The "relaxed" header canonicalization algorithm MUST apply the | |||
following steps in order: | following steps in order: | |||
o Convert all header field names (not the header field values) to | o Convert all header field names (not the header field values) to | |||
lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". | lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". | |||
o Unfold all header field continuation lines as described in | o Unfold all header field continuation lines as described in | |||
[RFC5322]; in particular, lines with terminators embedded in | [RFC5322]; in particular, lines with terminators embedded in | |||
continued header field values (that is, CRLF sequences followed by | continued header field values (that is, CRLF sequences followed by | |||
skipping to change at page 16, line 39 | skipping to change at page 17, line 9 | |||
character. WSP characters here include those before and after a | character. WSP characters here include those before and after a | |||
line folding boundary. | line folding boundary. | |||
o Delete all WSP characters at the end of each unfolded header field | o Delete all WSP characters at the end of each unfolded header field | |||
value. | value. | |||
o Delete any WSP characters remaining before and after the colon | o Delete any WSP characters remaining before and after the colon | |||
separating the header field name from the header field value. The | separating the header field name from the header field value. The | |||
colon separator MUST be retained. | colon separator MUST be retained. | |||
3.4.3. The "simple" Body Canonicalization Algorithm | 4.4.3. The "simple" Body Canonicalization Algorithm | |||
The "simple" body canonicalization algorithm ignores all empty lines | The "simple" body canonicalization algorithm ignores all empty lines | |||
at the end of the message body. An empty line is a line of zero | 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 | 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 | no trailing CRLF on the message body, a CRLF is added. It makes no | |||
other changes to the message body. In more formal terms, the | other changes to the message body. In more formal terms, the | |||
"simple" body canonicalization algorithm converts "0*CRLF" at the end | "simple" body canonicalization algorithm converts "0*CRLF" at the end | |||
of the body to a single "CRLF". | of the body to a single "CRLF". | |||
Note that a completely empty or missing body is canonicalized as a | Note that a completely empty or missing body is canonicalized as a | |||
single "CRLF"; that is, the canonicalized length will be 2 octets. | single "CRLF"; that is, the canonicalized length will be 2 octets. | |||
The sha1 value (in base64) for an empty body (canonicalized to a | The sha1 value (in base64) for an empty body (canonicalized to a | |||
"CRLF") is: | "CRLF") is: | |||
uoq1oCgLlTqpdDX/iUbLy7J1Wic= | uoq1oCgLlTqpdDX/iUbLy7J1Wic= | |||
The sha256 value is: | The sha256 value is: | |||
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= | frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= | |||
3.4.4. The "relaxed" Body Canonicalization Algorithm | 4.4.4. The "relaxed" Body Canonicalization Algorithm | |||
The "relaxed" body canonicalization algorithm MUST apply the | The "relaxed" body canonicalization algorithm MUST apply the | |||
following steps (a) and (b) in order: | following steps (a) and (b) in order: | |||
a. Reduce whitespace: | a. Reduce whitespace: | |||
* Ignore all whitespace at the end of lines. Implementations | * Ignore all whitespace at the end of lines. Implementations | |||
MUST NOT remove the CRLF at the end of the line. | MUST NOT remove the CRLF at the end of the line. | |||
* Reduce all sequences of WSP within a line to a single SP | * Reduce all sequences of WSP within a line to a single SP | |||
skipping to change at page 17, line 35 | skipping to change at page 18, line 4 | |||
line" is defined in Section 3.4.3. If the body is non-empty, but | line" is defined in Section 3.4.3. If the body is non-empty, but | |||
does not end with a CRLF, a CRLF is added. (For email, this is | does not end with a CRLF, a CRLF is added. (For email, this is | |||
only possible when using extensions to SMTP or non-SMTP transport | only possible when using extensions to SMTP or non-SMTP transport | |||
mechanisms.) | mechanisms.) | |||
The sha1 value (in base64) for an empty body (canonicalized to a null | The sha1 value (in base64) for an empty body (canonicalized to a null | |||
input) is: | input) is: | |||
2jmj7l5rSw0yVb/vlWAYkK/YBwk= | 2jmj7l5rSw0yVb/vlWAYkK/YBwk= | |||
The sha256 value is: | The sha256 value is: | |||
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= | 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= | |||
INFORMATIVE NOTE: It should be noted that the relaxed body | INFORMATIVE NOTE: It should be noted that the relaxed body | |||
canonicalization algorithm may enable certain types of extremely | canonicalization algorithm may enable certain types of extremely | |||
crude "ASCII Art" attacks where a message may be conveyed by | crude "ASCII Art" attacks where a message may be conveyed by | |||
adjusting the spacing between words. If this is a concern, the | adjusting the spacing between words. If this is a concern, the | |||
"simple" body canonicalization algorithm should be used instead. | "simple" body canonicalization algorithm should be used instead. | |||
3.4.5. Body Length Limits | 4.4.5. Body Length Limits | |||
A body length count MAY be specified to limit the signature | A body length count MAY be specified to limit the signature | |||
calculation to an initial prefix of the body text, measured in | calculation to an initial prefix of the body text, measured in | |||
octets. If the body length count is not specified, the entire | octets. If the body length count is not specified, the entire | |||
message body is signed. | message body is signed. | |||
INFORMATIVE RATIONALE: This capability is provided because it is | INFORMATIVE RATIONALE: This capability is provided because it is | |||
very common for mailing lists to add trailers to messages (e.g., | very common for mailing lists to add trailers to messages (e.g., | |||
instructions how to get off the list). Until those messages are | instructions how to get off the list). Until those messages are | |||
also signed, the body length count is a useful tool for the | also signed, the body length count is a useful tool for the | |||
verifier since it may as a matter of policy accept messages having | verifier since it may as a matter of policy accept messages having | |||
valid signatures with extraneous data. | valid signatures with extraneous data. | |||
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables | INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables | |||
an attack in which an attacker modifies a message to include | an attack in which an attacker modifies a message to include | |||
content that solely benefits the attacker. It is possible for the | content that solely benefits the attacker. It is possible for the | |||
appended content to completely replace the original content in the | appended content to completely replace the original content in the | |||
end recipient's eyes and to defeat duplicate message detection | end recipient's eyes and to defeat duplicate message detection | |||
algorithms. To avoid this attack, signers should be wary of using | algorithms. To avoid this attack, signers should be wary of using | |||
this tag, and verifiers might wish to ignore the tag or remove | this tag, and verifiers might wish to ignore the tag, {DKIM 2} | |||
text that appears after the specified content length, perhaps | perhaps based on other criteria. | |||
based on other criteria. | ||||
The body length count allows the signer of a message to permit data | 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 | to be appended to the end of the body of a signed message. The body | |||
length count MUST be calculated following the canonicalization | length count MUST be calculated following the canonicalization | |||
algorithm; for example, any whitespace ignored by a canonicalization | algorithm; for example, any whitespace ignored by a canonicalization | |||
algorithm is not included as part of the body length count. Signers | 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 | of MIME messages that include a body length count SHOULD be sure that | |||
the length extends to the closing MIME boundary string. | the length extends to the closing MIME boundary string. | |||
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that | INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that | |||
skipping to change at page 18, line 42 | skipping to change at page 19, line 10 | |||
only works for some MIME types, e.g., multipart/mixed but not | only works for some MIME types, e.g., multipart/mixed but not | |||
multipart/signed. | multipart/signed. | |||
A body length count of zero means that the body is completely | A body length count of zero means that the body is completely | |||
unsigned. | unsigned. | |||
Signers wishing to ensure that no modification of any sort can occur | Signers wishing to ensure that no modification of any sort can occur | |||
should specify the "simple" canonicalization algorithm for both | should specify the "simple" canonicalization algorithm for both | |||
header and body and omit the body length count. | header and body and omit the body length count. | |||
3.4.6. Canonicalization Examples (INFORMATIVE) | 4.4.6. Canonicalization Examples (INFORMATIVE) | |||
In the following examples, actual whitespace is used only for | In the following examples, actual whitespace is used only for | |||
clarity. The actual input and output text is designated using | clarity. The actual input and output text is designated using | |||
bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | |||
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | |||
For example, "X <SP> Y" and "X<SP>Y" represent the same three | For example, "X <SP> Y" and "X<SP>Y" represent the same three | |||
characters. | characters. | |||
Example 1: A message reading: | Example 1: A message reading: | |||
A: <SP> X <CRLF> | A: <SP> X <CRLF> | |||
skipping to change at page 19, line 45 | skipping to change at page 20, line 14 | |||
Example 3: When processed using relaxed header canonicalization and | Example 3: When processed using relaxed header canonicalization and | |||
simple body canonicalization, the canonicalized version has a header | simple body canonicalization, the canonicalized version has a header | |||
of: | of: | |||
a:X <CRLF> | a:X <CRLF> | |||
b:Y <SP> Z <CRLF> | b:Y <SP> Z <CRLF> | |||
and a body reading: | and a body reading: | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><HTAB><SP> E <CRLF> | D <SP><HTAB><SP> E <CRLF> | |||
3.5. The DKIM-Signature Header Field | 4.5. The DKIM-Signature Header Field | |||
The signature of the email is stored in the DKIM-Signature header | The signature of the email is stored in the DKIM-Signature header | |||
field. This header field contains all of the signature and key- | field. This header field contains all of the signature and key- | |||
fetching data. The DKIM-Signature value is a tag-list as described | fetching data. The DKIM-Signature value is a tag-list as described | |||
in Section 3.2. | in Section 4.2. | |||
The DKIM-Signature header field SHOULD be treated as though it were a | The DKIM-Signature header field SHOULD be treated as though it were a | |||
trace header field as defined in Section 3.6 of [RFC5322], and hence | trace header field as defined in Section 3.6 of [RFC5322], and hence | |||
SHOULD NOT be reordered and SHOULD be prepended to the message. | SHOULD NOT be reordered and SHOULD be prepended to the message. | |||
The DKIM-Signature header field being created or verified is always | The DKIM-Signature header field being created or verified is always | |||
included in the signature calculation, after the rest of the header | included in the signature calculation, after the rest of the header | |||
fields being signed; however, when calculating or verifying the | fields being signed; however, when calculating or verifying the | |||
signature, the value of the "b=" tag (signature value) of that DKIM- | signature, the value of the "b=" tag (signature value) of that DKIM- | |||
Signature header field MUST be treated as though it were an empty | Signature header field MUST be treated as though it were an empty | |||
string. Unknown tags in the DKIM-Signature header field MUST be | string. Unknown tags in the DKIM-Signature header field MUST be | |||
included in the signature calculation but MUST be otherwise ignored | included in the signature calculation but MUST be otherwise ignored | |||
by verifiers. Other DKIM-Signature header fields that are included | by verifiers. Other DKIM-Signature header fields that are included | |||
in the signature should be treated as normal header fields; in | in the signature should be treated as normal header fields; in | |||
particular, the "b=" tag is not treated specially. | particular, the "b=" tag is not treated specially. | |||
The encodings for each field type are listed below. Tags described | 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 | as qp-section are encoded as described in Section 6.7 of MIME Part | |||
One [RFC2045], with the additional conversion of semicolon characters | One [RFC2045], with the additional conversion of semicolon characters | |||
to "=3B"; intuitively, this is one line of quoted-printable encoded | to "=3B"; intuitively, this is one line of quoted-printable encoded | |||
text. The dkim-quoted-printable syntax is defined in Section 2.11. | text. The dkim-quoted-printable syntax is defined in Section 3.11. | |||
Tags on the DKIM-Signature header field along with their type and | Tags on the DKIM-Signature header field along with their type and | |||
requirement status are shown below. Unrecognized tags MUST be | requirement status are shown below. Unrecognized tags MUST be | |||
ignored. | ignored. | |||
v= Version (MUST be included). This tag defines the version of this | v= Version (MUST be included). This tag defines the version of this | |||
specification that applies to the signature record. It MUST have | specification that applies to the signature record. It MUST have | |||
the value "1". Note that verifiers must do a string comparison on | the value "1". Note that verifiers must do a string comparison on | |||
this value; for example, "1" is not the same as "1.0". | this value; for example, "1" is not the same as "1.0". | |||
skipping to change at page 21, line 20 | skipping to change at page 21, line 31 | |||
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h | sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h | |||
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | |||
; for later extension | ; for later extension | |||
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) | x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) | |||
; for later extension | ; for later extension | |||
b= The signature data (base64; REQUIRED). Whitespace is ignored in | b= The signature data (base64; REQUIRED). Whitespace is ignored in | |||
this value and MUST be ignored when reassembling the original | this value and MUST be ignored when reassembling the original | |||
signature. In particular, the signing process can safely insert | signature. In particular, the signing process can safely insert | |||
FWS in this value in arbitrary places to conform to line-length | FWS in this value in arbitrary places to conform to line-length | |||
limits. See Signer Actions (Section 5) for how the signature is | limits. See Signer Actions (Section 6) for how the signature is | |||
computed. | computed. | |||
ABNF: | ABNF: | |||
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data | |||
sig-b-tag-data = base64string | sig-b-tag-data = base64string | |||
bh= The hash of the canonicalized body part of the message as | bh= The hash of the canonicalized body part of the message as | |||
limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored | limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored | |||
in this value and MUST be ignored when reassembling the original | in this value and MUST be ignored when reassembling the original | |||
signature. In particular, the signing process can safely insert | signature. In particular, the signing process can safely insert | |||
FWS in this value in arbitrary places to conform to line-length | FWS in this value in arbitrary places to conform to line-length | |||
limits. See Section 3.7 for how the body hash is computed. | limits. See Section 4.7 for how the body hash is computed. | |||
ABNF: | ABNF: | |||
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data | sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data | |||
sig-bh-tag-data = base64string | sig-bh-tag-data = base64string | |||
c= Message canonicalization (plain-text; OPTIONAL, default is | c= Message canonicalization (plain-text; OPTIONAL, default is | |||
"simple/simple"). This tag informs the verifier of the type of | "simple/simple"). This tag informs the verifier of the type of | |||
canonicalization used to prepare the message for signing. It | canonicalization used to prepare the message for signing. It | |||
consists of two names separated by a "slash" (%d47) character, | consists of two names separated by a "slash" (%d47) character, | |||
corresponding to the header and body canonicalization algorithms | corresponding to the header and body canonicalization algorithms | |||
respectively. These algorithms are described in Section 3.4. If | respectively. These algorithms are described in Section 4.4. If | |||
only one algorithm is named, that algorithm is used for the header | only one algorithm is named, that algorithm is used for the header | |||
and "simple" is used for the body. For example, "c=relaxed" is | and "simple" is used for the body. For example, "c=relaxed" is | |||
treated the same as "c=relaxed/simple". | treated the same as "c=relaxed/simple". | |||
ABNF: | ABNF: | |||
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg | |||
["/" sig-c-tag-alg] | ["/" sig-c-tag-alg] | |||
sig-c-tag-alg = "simple" / "relaxed" / x-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 | x-sig-c-tag-alg = hyphenated-word ; for later extension | |||
skipping to change at page 22, line 26 | skipping to change at page 23, line 6 | |||
into the mail stream (plain-text; REQUIRED). Hence, the SDID | into the mail stream (plain-text; REQUIRED). Hence, the SDID | |||
value is used to form the query for the public key. The SDID MUST | value is used to form the query for the public key. The SDID MUST | |||
correspond to a valid DNS name under which the DKIM key record is | correspond to a valid DNS name under which the DKIM key record is | |||
published. The conventions and semantics used by a signer to | published. The conventions and semantics used by a signer to | |||
create and use a specific SDID are outside the scope of the DKIM | create and use a specific SDID are outside the scope of the DKIM | |||
Signing specification, as is any use of those conventions and | Signing specification, as is any use of those conventions and | |||
semantics. When presented with a signature that does not meet | semantics. When presented with a signature that does not meet | |||
these requirements, verifiers MUST consider the signature invalid. | these requirements, verifiers MUST consider the signature invalid. | |||
Internationalized domain names MUST be encoded as described in | Internationalized domain names MUST be encoded as described in | |||
[RFC3490]. | Section 2.3 of [RFC5890] to "A-Labels". {DKIM 4}. | |||
ABNF: | ABNF: | |||
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | sig-d-tag = %x64 [FWS] "=" [FWS] domain-name | |||
domain-name = sub-domain 1*("." sub-domain) | domain-name = sub-domain 1*("." sub-domain) | |||
; from RFC 5321 Domain, but excluding address-literal | ; from RFC5321 Domain, excluding address-literal | |||
h= Signed header fields (plain-text, but see description; REQUIRED). | h= Signed header fields (plain-text, but see description; REQUIRED). | |||
A colon-separated list of header field names that identify the | A colon-separated list of header field names that identify the | |||
header fields presented to the signing algorithm. The field MUST | header fields presented to the signing algorithm. The field MUST | |||
contain the complete list of header fields in the order presented | contain the complete list of header fields in the order presented | |||
to the signing algorithm. The field MAY contain names of header | to the signing algorithm. The field MAY contain names of header | |||
fields that do not exist when signed; nonexistent header fields do | fields that do not exist when signed; nonexistent header fields do | |||
not contribute to the signature computation (that is, they are | not contribute to the signature computation (that is, they are | |||
treated as the null input, including the header field name, the | treated as the null input, including the header field name, the | |||
separating colon, the header field value, and any CRLF | separating colon, the header field value, and any CRLF | |||
terminator). The field MUST NOT include the DKIM-Signature header | terminator). The field MUST NOT include the DKIM-Signature header | |||
field that is being created or verified, but may include others. | field that is being created or verified, but may include others. | |||
Folding whitespace (FWS) MAY be included on either side of the | Folding whitespace (FWS) MAY be included on either side of the | |||
colon separator. Header field names MUST be compared against | colon separator. Header field names MUST be compared against | |||
actual header field names in a case-insensitive manner. This list | actual header field names in a case-insensitive manner. This list | |||
MUST NOT be empty. See Section 5.4 for a discussion of choosing | MUST NOT be empty. See Section 6.4 for a discussion of choosing | |||
header fields to sign. | header fields to sign. | |||
ABNF: | ABNF: | |||
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name | |||
0*( [FWS] ":" [FWS] hdr-name ) | 0*( [FWS] ":" [FWS] hdr-name ) | |||
INFORMATIVE EXPLANATION: By "signing" header fields that do not | INFORMATIVE EXPLANATION: By "signing" header fields that do not | |||
actually exist, a signer can prevent insertion of those header | actually exist, a signer can prevent insertion of those header | |||
fields before verification. However, since a signer cannot | fields before verification. However, since a signer cannot | |||
possibly know what header fields might be created in the | possibly know what header fields might be created in the | |||
skipping to change at page 23, line 37 | skipping to change at page 24, line 19 | |||
i= The Agent or User Identifier (AUID) on behalf of which the SDID is | i= The Agent or User Identifier (AUID) on behalf of which the SDID is | |||
taking responsibility (dkim-quoted-printable; OPTIONAL, default is | taking responsibility (dkim-quoted-printable; OPTIONAL, default is | |||
an empty Local-part followed by an "@" followed by the domain from | an empty Local-part followed by an "@" followed by the domain from | |||
the "d=" tag). | the "d=" tag). | |||
The syntax is a standard email address where the Local-part MAY be | 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 | omitted. The domain part of the address MUST be the same as, or a | |||
subdomain of, the value of the "d=" tag. | subdomain of, the value of the "d=" tag. | |||
Internationalized domain names MUST be converted using the steps | Internationalized domain names MUST be converted as described in | |||
listed in Section 4 of [RFC3490] using the "ToASCII" function. | Section 2.3 of [RFC5890] to "A-Labels" {DKIM 4}. | |||
ABNF: | ABNF: | |||
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] | sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] | |||
"@" domain-name | "@" domain-name | |||
The AUID is specified as having the same syntax as an email | The AUID is specified as having the same syntax as an email | |||
address, but is not required to have the same semantics. Notably, | address, but is not required to have the same semantics. Notably, | |||
the domain name is not required to be registered in the DNS -- so | the domain name is not required to be registered in the DNS -- so | |||
it might not resolve in a query -- and the Local-part MAY be drawn | it might not resolve in a query -- and the Local-part MAY be drawn | |||
skipping to change at page 25, line 17 | skipping to change at page 25, line 43 | |||
allow display of fraudulent content without appropriate warning | allow display of fraudulent content without appropriate warning | |||
to end users. The "l=" tag is intended for increasing | to end users. The "l=" tag is intended for increasing | |||
signature robustness when sending to mailing lists that both | signature robustness when sending to mailing lists that both | |||
modify their content and do not sign their messages. However, | modify their content and do not sign their messages. However, | |||
using the "l=" tag enables attacks in which an intermediary | using the "l=" tag enables attacks in which an intermediary | |||
with malicious intent modifies a message to include content | with malicious intent modifies a message to include content | |||
that solely benefits the attacker. It is possible for the | that solely benefits the attacker. It is possible for the | |||
appended content to completely replace the original content in | appended content to completely replace the original content in | |||
the end recipient's eyes and to defeat duplicate message | the end recipient's eyes and to defeat duplicate message | |||
detection algorithms. Examples are described in Security | detection algorithms. Examples are described in Security | |||
Considerations Section 8. To avoid this attack, signers should | Considerations Section 9. To avoid this attack, signers should | |||
be extremely wary of using this tag, and verifiers might wish | be extremely wary of using this tag, and verifiers might wish | |||
to ignore the tag or remove text that appears after the | to ignore the tag. {DKIM 2} | |||
specified content length. | ||||
INFORMATIVE NOTE: The value of the "l=" tag is constrained to | INFORMATIVE NOTE: The value of the "l=" tag is constrained to | |||
76 decimal digits. This constraint is not intended to predict | 76 decimal digits. This constraint is not intended to predict | |||
the size of future messages or to require implementations to | the size of future messages or to require implementations to | |||
use an integer representation large enough to represent the | use an integer representation large enough to represent the | |||
maximum possible value, but is intended to remind the | maximum possible value, but is intended to remind the | |||
implementer to check the length of this and all other tags | implementer to check the length of this and all other tags | |||
during verification and to test for integer overflow when | during verification and to test for integer overflow when | |||
decoding the value. Implementers may need to limit the actual | decoding the value. Implementers may need to limit the actual | |||
value expressed to a value smaller than 10^76, e.g., to allow a | value expressed to a value smaller than 10^76, e.g., to allow a | |||
message to fit within the available storage space. | message to fit within the available storage space. | |||
skipping to change at page 28, line 10 | skipping to change at page 28, line 38 | |||
header field value. After encoding, FWS MAY be added at arbitrary | header field value. After encoding, FWS MAY be added at arbitrary | |||
locations in order to avoid excessively long lines; such | locations in order to avoid excessively long lines; such | |||
whitespace is NOT part of the value of the header field, and MUST | whitespace is NOT part of the value of the header field, and MUST | |||
be removed before decoding. | be removed before decoding. | |||
The header fields referenced by the "h=" tag refer to the fields | The header fields referenced by the "h=" tag refer to the fields | |||
in the [RFC5322] header of the message, not to any copied fields | in the [RFC5322] header of the message, not to any copied fields | |||
in the "z=" tag. Copied header field values are for diagnostic | in the "z=" tag. Copied header field values are for diagnostic | |||
use. | use. | |||
Header fields with characters requiring conversion (perhaps from | ||||
legacy MTAs that are not [RFC5322] compliant) SHOULD be converted | ||||
as described in MIME Part Three [RFC2047]. | ||||
ABNF: | ABNF: | |||
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy | sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy | |||
*( "|" [FWS] sig-z-tag-copy ) | *( "|" [FWS] sig-z-tag-copy ) | |||
sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value | sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value | |||
INFORMATIVE EXAMPLE of a signature header field spread across | INFORMATIVE EXAMPLE of a signature header field spread across | |||
multiple continuation lines: | multiple continuation lines: | |||
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; | DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; | |||
c=simple; q=dns/txt; i=@eng.example.net; | c=simple; q=dns/txt; i=@eng.example.net; | |||
t=1117574938; x=1118006938; | t=1117574938; x=1118006938; | |||
h=from:to:subject:date; | h=from:to:subject:date; | |||
z=From:foo@eng.example.net|To:joe@example.com| | z=From:foo@eng.example.net|To:joe@example.com| | |||
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | |||
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | |||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR | |||
skipping to change at page 28, line 30 | skipping to change at page 29, line 15 | |||
multiple continuation lines: | multiple continuation lines: | |||
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; | DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; | |||
c=simple; q=dns/txt; i=@eng.example.net; | c=simple; q=dns/txt; i=@eng.example.net; | |||
t=1117574938; x=1118006938; | t=1117574938; x=1118006938; | |||
h=from:to:subject:date; | h=from:to:subject:date; | |||
z=From:foo@eng.example.net|To:joe@example.com| | z=From:foo@eng.example.net|To:joe@example.com| | |||
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | |||
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | |||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR | |||
3.6. Key Management and Representation | 4.6. Key Management and Representation | |||
Signature applications require some level of assurance that the | Signature applications require some level of assurance that the | |||
verification public key is associated with the claimed signer. Many | verification public key is associated with the claimed signer. Many | |||
applications achieve this by using public key certificates issued by | applications achieve this by using public key certificates issued by | |||
a trusted third party. However, DKIM can achieve a sufficient level | a trusted third party. However, DKIM can achieve a sufficient level | |||
of security, with significantly enhanced scalability, by simply | of security, with significantly enhanced scalability, by simply | |||
having the verifier query the purported signer's DNS entry (or some | having the verifier query the purported signer's DNS entry (or some | |||
security-equivalent) in order to retrieve the public key. | security-equivalent) in order to retrieve the public key. | |||
DKIM keys can potentially be stored in multiple types of key servers | DKIM keys can potentially be stored in multiple types of key servers | |||
skipping to change at page 29, line 4 | skipping to change at page 29, line 32 | |||
having the verifier query the purported signer's DNS entry (or some | having the verifier query the purported signer's DNS entry (or some | |||
security-equivalent) in order to retrieve the public key. | security-equivalent) in order to retrieve the public key. | |||
DKIM keys can potentially be stored in multiple types of key servers | DKIM keys can potentially be stored in multiple types of key servers | |||
and in multiple formats. The storage and format of keys are | and in multiple formats. The storage and format of keys are | |||
irrelevant to the remainder of the DKIM algorithm. | irrelevant to the remainder of the DKIM algorithm. | |||
Parameters to the key lookup algorithm are the type of the lookup | 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- | (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- | |||
Signature header field), and the selector (the "s=" tag). | Signature header field), and the selector (the "s=" tag). | |||
public_key = dkim_find_key(q_val, d_val, s_val) | public_key = dkim_find_key(q_val, d_val, s_val) | |||
This document defines a single binding, using DNS TXT records to | This document defines a single binding, using DNS TXT records to | |||
distribute the keys. Other bindings may be defined in the future. | distribute the keys. Other bindings may be defined in the future. | |||
3.6.1. Textual Representation | 4.6.1. Textual Representation | |||
It is expected that many key servers will choose to present the keys | It is expected that many key servers will choose to present the keys | |||
in an otherwise unstructured text format (for example, an XML form | in an otherwise unstructured text format (for example, an XML form | |||
would not be considered to be unstructured text for this purpose). | would not be considered to be unstructured text for this purpose). | |||
The following definition MUST be used for any DKIM key represented in | The following definition MUST be used for any DKIM key represented in | |||
an otherwise unstructured textual form. | an otherwise unstructured textual form. | |||
The overall syntax is a tag-list as described in Section 3.2. The | The overall syntax is a tag-list as described in Section 4.2. The | |||
current valid tags are described below. Other tags MAY be present | current valid tags are described below. Other tags MAY be present | |||
and MUST be ignored by any implementation that does not understand | and MUST be ignored by any implementation that does not understand | |||
them. | them. | |||
v= Version of the DKIM key record (plain-text; RECOMMENDED, default | v= Version of the DKIM key record (plain-text; RECOMMENDED, default | |||
is "DKIM1"). If specified, this tag MUST be set to "DKIM1" | is "DKIM1"). If specified, this tag MUST be set to "DKIM1" | |||
(without the quotes). This tag MUST be the first tag in the | (without the quotes). This tag MUST be the first tag in the | |||
record. Records beginning with a "v=" tag with any other value | record. Records beginning with a "v=" tag with any other value | |||
MUST be discarded. Note that verifiers must do a string | MUST be discarded. Note that verifiers must do a string | |||
comparison on this value; for example, "DKIM1" is not the same as | comparison on this value; for example, "DKIM1" is not the same as | |||
"DKIM1.0". | "DKIM1.0". | |||
ABNF: | ABNF: | |||
key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 | key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 | |||
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | |||
allowing all algorithms). A colon-separated list of hash | allowing all algorithms). A colon-separated list of hash | |||
algorithms that might be used. Unrecognized algorithms MUST be | algorithms that might be used. Unrecognized algorithms MUST be | |||
ignored. Refer to Section 3.3 for a discussion of the hash | ignored. Refer to Section 4.3 for a discussion of the hash | |||
algorithms implemented by Signers and Verifiers. . The set of | algorithms implemented by Signers and Verifiers. The set of | |||
algorithms listed in this tag in each record is an operational | algorithms listed in this tag in each record is an operational | |||
choice made by the Signer. | choice made by the Signer. | |||
ABNF: | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | |||
0*( [FWS] ":" [FWS] key-h-tag-alg ) | 0*( [FWS] ":" [FWS] key-h-tag-alg ) | |||
key-h-tag-alg = "sha1" / "sha256" / x-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 | x-key-h-tag-alg = hyphenated-word ; for future extension | |||
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | |||
verifiers MUST support the "rsa" key type. The "rsa" key type | verifiers MUST support the "rsa" key type. The "rsa" key type | |||
indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | |||
[RFC3447] (see Sections Section 3.1 and A.1.1) is being used in | [RFC3447] (see Sections Section 4.1 and A.1.1) is being used in | |||
the "p=" tag. (Note: the "p=" tag further encodes the value using | the "p=" tag. (Note: the "p=" tag further encodes the value using | |||
the base64 algorithm.) Unrecognized key types MUST be ignored. | the base64 algorithm.) Unrecognized key types MUST be ignored. | |||
ABNF: | ABNF: | |||
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type | key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type | |||
key-k-tag-type = "rsa" / x-key-k-tag-type | key-k-tag-type = "rsa" / x-key-k-tag-type | |||
x-key-k-tag-type = hyphenated-word ; for future extension | x-key-k-tag-type = hyphenated-word ; for future extension | |||
n= Notes that might be of interest to a human (qp-section; OPTIONAL, | n= Notes that might be of interest to a human (qp-section; OPTIONAL, | |||
default is empty). No interpretation is made by any program. | default is empty). No interpretation is made by any program. | |||
This tag should be used sparingly in any key server mechanism that | This tag should be used sparingly in any key server mechanism that | |||
has space limitations (notably DNS). This is intended for use by | has space limitations (notably DNS). This is intended for use by | |||
administrators, not end users. | administrators, not end users. | |||
ABNF: | ABNF: | |||
key-n-tag = %x6e [FWS] "=" [FWS] qp-section | key-n-tag = %x6e [FWS] "=" [FWS] qp-section | |||
p= Public-key data (base64; REQUIRED). An empty value means that | p= Public-key data (base64; REQUIRED). An empty value means that | |||
skipping to change at page 32, line 11 | skipping to change at page 33, line 4 | |||
same domain value on the right-hand side of the "@" in the "i=" | 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 | 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 | NOT be a subdomain of "d=". Use of this flag is RECOMMENDED | |||
unless subdomaining is required. | unless subdomaining is required. | |||
ABNF: | ABNF: | |||
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | |||
0*( [FWS] ":" [FWS] key-t-tag-flag ) | 0*( [FWS] ":" [FWS] key-t-tag-flag ) | |||
key-t-tag-flag = "y" / "s" / x-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 | x-key-t-tag-flag = hyphenated-word ; for future extension | |||
Unrecognized flags MUST be ignored. | Unrecognized flags MUST be ignored. | |||
3.6.2. DNS Binding | 4.6.2. DNS Binding | |||
A binding using DNS TXT records as a key service is hereby defined. | A binding using DNS TXT records as a key service is hereby defined. | |||
All implementations MUST support this binding. | All implementations MUST support this binding. | |||
3.6.2.1. Namespace | 4.6.2.1. Namespace | |||
All DKIM keys are stored in a subdomain named "_domainkey". Given a | 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 | DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag | |||
of "foo.bar", the DNS query will be for | of "foo.bar", the DNS query will be for | |||
"foo.bar._domainkey.example.com". | "foo.bar._domainkey.example.com". | |||
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., | 4.6.2.2. Resource Record Types for Key Storage | |||
*.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. | ||||
3.6.2.2. Resource Record Types for Key Storage | ||||
The DNS Resource Record type used is specified by an option to the | The DNS Resource Record type used is specified by an option to the | |||
query-type ("q=") tag. The only option defined in this base | query-type ("q=") tag. The only option defined in this base | |||
specification is "txt", indicating the use of a TXT Resource Record | specification is "txt", indicating the use of a TXT Resource Record | |||
(RR). A later extension of this standard may define another RR type. | (RR). A later extension of this standard may define another RR type. | |||
Strings in a TXT RR MUST be concatenated together before use with no | Strings in a TXT RR MUST be concatenated together before use with no | |||
intervening whitespace. TXT RRs MUST be unique for a particular | intervening whitespace. TXT RRs MUST be unique for a particular | |||
selector name; that is, if there are multiple records in an RRset, | selector name; that is, if there are multiple records in an RRset, | |||
the results are undefined. | the results are undefined. | |||
TXT RRs are encoded as described in Section 3.6.1 | TXT RRs are encoded as described in Section 4.6.1 | |||
3.7. Computing the Message Hashes | 4.7. Computing the Message Hashes | |||
Both signing and verifying message signatures start with a step of | Both signing and verifying message signatures start with a step of | |||
computing two cryptographic hashes over the message. Signers will | computing two cryptographic hashes over the message. Signers will | |||
choose the parameters of the signature as described in Signer Actions | choose the parameters of the signature as described in Signer Actions | |||
Section 5; verifiers will use the parameters specified in the DKIM- | Section 6; verifiers will use the parameters specified in the DKIM- | |||
Signature header field being verified. In the following discussion, | Signature header field being verified. In the following discussion, | |||
the names of the tags in the DKIM-Signature header field that either | the names of the tags in the DKIM-Signature header field that either | |||
exists (when verifying) or will be created (when signing) are used. | exists (when verifying) or will be created (when signing) are used. | |||
Note that canonicalization (Section 3.4) is only used to prepare the | Note that canonicalization (Section 4.4) is only used to prepare the | |||
email for signing or verifying; it does not affect the transmitted | email for signing or verifying; it does not affect the transmitted | |||
email in any way. | email in any way. | |||
The signer/verifier MUST compute two hashes, one over the body of the | The signer/verifier MUST compute two hashes, one over the body of the | |||
message and one over the selected header fields of the message. | message and one over the selected header fields of the message. | |||
Signers MUST compute them in the order shown. Verifiers MAY compute | Signers MUST compute them in the order shown. Verifiers MAY compute | |||
them in any order convenient to the verifier, provided that the | them in any order convenient to the verifier, provided that the | |||
result is semantically identical to the semantics that would be the | result is semantically identical to the semantics that would be the | |||
case had they been computed in this order. | case had they been computed in this order. | |||
skipping to change at page 34, line 8 | skipping to change at page 34, line 36 | |||
All tags and their values in the DKIM-Signature header field are | All tags and their values in the DKIM-Signature header field are | |||
included in the cryptographic hash with the sole exception of the | included in the cryptographic hash with the sole exception of the | |||
value portion of the "b=" (signature) tag, which MUST be treated as | 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 | 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 | understood by the verifier. The header field MUST be presented to | |||
the hash algorithm after the body of the message rather than with the | 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 | rest of the header fields and MUST be canonicalized as specified in | |||
the "c=" (canonicalization) tag. The DKIM-Signature header field | the "c=" (canonicalization) tag. The DKIM-Signature header field | |||
MUST NOT be included in its own h= tag, although other DKIM-Signature | MUST NOT be included in its own h= tag, although other DKIM-Signature | |||
header fields MAY be signed (see Section 4). | header fields MAY be signed (see Section 5). | |||
When calculating the hash on messages that will be transmitted using | When calculating the hash on messages that will be transmitted using | |||
base64 or quoted-printable encoding, signers MUST compute the hash | base64 or quoted-printable encoding, signers MUST compute the hash | |||
after the encoding. Likewise, the verifier MUST incorporate the | after the encoding. Likewise, the verifier MUST incorporate the | |||
values into the hash before decoding the base64 or quoted-printable | values into the hash before decoding the base64 or quoted-printable | |||
text. However, the hash MUST be computed before transport level | text. However, the hash MUST be computed before transport level | |||
encodings such as SMTP "dot-stuffing" (the modification of lines | encodings such as SMTP "dot-stuffing" (the modification of lines | |||
beginning with a "." to avoid confusion with the SMTP end-of-message | beginning with a "." to avoid confusion with the SMTP end-of-message | |||
marker, as specified in [RFC5321]). | marker, as specified in [RFC5321]). | |||
With the exception of the canonicalization procedure described in | With the exception of the canonicalization procedure described in | |||
Section 3.4, the DKIM signing process treats the body of messages as | Section 4.4, the DKIM signing process treats the body of messages as | |||
simply a string of octets. DKIM messages MAY be either in plain-text | 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. | or in MIME format; no special treatment is afforded to MIME content. | |||
Message attachments in MIME format MUST be included in the content | Message attachments in MIME format MUST be included in the content | |||
that is signed. | that is signed. | |||
More formally, pseudo-code for the signature algorithm is: | More formally, pseudo-code for the signature algorithm is: | |||
body-hash = hash-alg (canon-body, l-param) | body-hash = hash-alg (canon-body, l-param) | |||
data-hash = hash-alg (h-headers, D-SIG, content-hash) | data-hash = hash-alg (h-headers, D-SIG, content-hash) | |||
signature = sig-alg (d-domain, selector, data-hash) | signature = sig-alg (d-domain, selector, data-hash) | |||
where: | where: | |||
body-hash: is the output from hashing the body, using hash-alg. | body-hash: is the output from hashing the body, using hash-alg. | |||
hash-alg: is the hashing algorithm specified in the "a" | hash-alg: is the hashing algorithm specified in the "a" | |||
parameter. | parameter. | |||
canon-body: is a canonicalized representation of the body, | canon-body: is a canonicalized representation of the body, | |||
produced by using the body algorithm specified in the "c" | produced by using the body algorithm specified in the "c" | |||
parameter, as defined in Section 3.4 and excluding the | parameter, as defined in Section 4.4 and excluding the | |||
DKIM-Signature field. | DKIM-Signature field. | |||
l-param: is the length-of-body value of the "l" parameter. | l-param: is the length-of-body value of the "l" parameter. | |||
data-hash: is the output from using the hash-alg algorithm, to | data-hash: is the output from using the hash-alg algorithm, to | |||
hash the header including the DKIM-Signature header, and the | hash the header including the DKIM-Signature header, and the | |||
body hash. | body hash. | |||
h-headers: is the list of headers to be signed, as specified in | h-headers: is the list of headers to be signed, as specified in | |||
the "h" parameter. | the "h" parameter. | |||
skipping to change at page 35, line 28 | skipping to change at page 36, line 5 | |||
d-domain: is the domain name specified in the "d" parameter. | d-domain: is the domain name specified in the "d" parameter. | |||
selector: is the selector value specified in the "s" parameter. | selector: is the selector value specified in the "s" parameter. | |||
NOTE: Many digital signature APIs provide both hashing and | NOTE: Many digital signature APIs provide both hashing and | |||
application of the RSA private key using a single "sign()" | application of the RSA private key using a single "sign()" | |||
primitive. When using such an API, the last two steps in the | primitive. When using such an API, the last two steps in the | |||
algorithm would probably be combined into a single call that would | algorithm would probably be combined into a single call that would | |||
perform both the "a-hash-alg" and the "sig-alg". | perform both the "a-hash-alg" and the "sig-alg". | |||
3.8. Input Requirements | 4.8. Input Requirements | |||
DKIM's design is predicated on valid input. Therefore, signers and | DKIM's design is predicated on valid input. Therefore, signers and | |||
verifiers SHOULD take reasonable steps to ensure that the messages | verifiers SHOULD take reasonable steps to ensure that the messages | |||
they are processing are valid according to [RFC5322], [RFC2045], and | they are processing are valid according to [RFC5322], [RFC2045], and | |||
any other relevant message format standards. See Section 8.15 for | any other relevant message format standards. See Section 9.15 for | |||
additional discussion and references. | additional discussion and references. | |||
3.9. Signing by Parent Domains | 4.9. Signing by Parent Domains | |||
In some circumstances, it is desirable for a domain to apply a | In some circumstances, it is desirable for a domain to apply a | |||
signature on behalf of any of its subdomains without the need to | signature on behalf of any of its subdomains without the need to | |||
maintain separate selectors (key records) in each subdomain. By | maintain separate selectors (key records) in each subdomain. By | |||
default, private keys corresponding to key records can be used to | default, private keys corresponding to key records can be used to | |||
sign messages for any subdomain of the domain in which they reside; | sign messages for any subdomain of the domain in which they reside; | |||
for example, a key record for the domain example.com can be used to | for example, a key record for the domain example.com can be used to | |||
verify messages where the AUID ("i=" tag of the signature) is | verify messages where the AUID ("i=" tag of the signature) is | |||
sub.example.com, or even sub1.sub2.example.com. In order to limit | 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 | 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 | MAY be set in the "t=" tag of the key record, to constrain the | |||
validity of the domain of the AUID. If the referenced key record | validity of the domain of the AUID. If the referenced key record | |||
contains the "s" flag as part of the "t=" tag, the domain of the AUID | contains the "s" flag as part of the "t=" tag, the domain of the AUID | |||
("i=" flag) MUST be the same as that of the SDID (d=) domain. If | ("i=" flag) MUST be the same as that of the SDID (d=) domain. If | |||
this flag is absent, the domain of the AUID MUST be the same as, or a | this flag is absent, the domain of the AUID MUST be the same as, or a | |||
subdomain of, the SDID. | subdomain of, the SDID. | |||
3.10. Relationship between SDID and AUID | 4.10. Relationship between SDID and AUID | |||
DKIM's primary task is to communicate from the Signer to a recipient- | DKIM's primary task is to communicate from the Signer to a recipient- | |||
side Identity Assessor a single Signing Domain Identifier (SDID) that | side Identity Assessor a single Signing Domain Identifier (SDID) that | |||
refers to a responsible identity. DKIM MAY optionally provide a | refers to a responsible identity. DKIM MAY optionally provide a | |||
single responsible Agent or User Identifier (AUID). | single responsible Agent or User Identifier (AUID). | |||
Hence, DKIM's mandatory output to a receive-side Identity Assessor is | Hence, DKIM's mandatory output to a receive-side Identity Assessor is | |||
a single domain name. Within the scope of its use as DKIM output, | a single domain name. Within the scope of its use as DKIM output, | |||
the name has only basic domain name semantics; any possible owner- | the name has only basic domain name semantics; any possible owner- | |||
specific semantics are outside the scope of DKIM. That is, within | specific semantics are outside the scope of DKIM. That is, within | |||
skipping to change at page 36, line 47 | skipping to change at page 37, line 25 | |||
is a broad and complex topic and trust mechanisms are subject to | is a broad and complex topic and trust mechanisms are subject to | |||
highly creative attacks. The real-world efficacy of any but the | highly creative attacks. The real-world efficacy of any but the | |||
most basic bindings between the SDID or AUID and other identities | most basic bindings between the SDID or AUID and other identities | |||
is not well established, nor is its vulnerability to subversion by | is not well established, nor is its vulnerability to subversion by | |||
an attacker. Hence, reliance on the use of such bindings should | an attacker. Hence, reliance on the use of such bindings should | |||
be strictly limited. In particular, it is not at all clear to | be strictly limited. In particular, it is not at all clear to | |||
what extent a typical end-user recipient can rely on any | what extent a typical end-user recipient can rely on any | |||
assurances that might be made by successful use of the SDID or | assurances that might be made by successful use of the SDID or | |||
AUID. | AUID. | |||
4. Semantics of Multiple Signatures | 5. Semantics of Multiple Signatures | |||
4.1. Example Scenarios | ||||
5.1. Example Scenarios | ||||
There are many reasons why a message might have multiple signatures. | There are many reasons why a message might have multiple signatures. | |||
For example, a given signer might sign multiple times, perhaps with | For example, a given signer might sign multiple times, perhaps with | |||
different hashing or signing algorithms during a transition phase. | different hashing or signing algorithms during a transition phase. | |||
INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | |||
insufficiently strong, and DKIM usage transitions to SHA-1024. A | insufficiently strong, and DKIM usage transitions to SHA-1024. A | |||
signer might immediately sign using the newer algorithm, but | signer might immediately sign using the newer algorithm, but | |||
continue to sign using the older algorithm for interoperability | continue to sign using the older algorithm for interoperability | |||
with verifiers that had not yet upgraded. The signer would do | with verifiers that had not yet upgraded. The signer would do | |||
skipping to change at page 38, line 13 | skipping to change at page 38, line 38 | |||
services, such as those commonly associated with academic alumni | services, such as those commonly associated with academic alumni | |||
sites. | sites. | |||
INFORMATIVE EXAMPLE: A recipient might have an address at | INFORMATIVE EXAMPLE: A recipient might have an address at | |||
members.example.org, a site that has anti-abuse protection that is | members.example.org, a site that has anti-abuse protection that is | |||
somewhat less effective than the recipient would prefer. Such a | somewhat less effective than the recipient would prefer. Such a | |||
recipient might have specific authors whose messages would be | recipient might have specific authors whose messages would be | |||
trusted absolutely, but messages from unknown authors that had | trusted absolutely, but messages from unknown authors that had | |||
passed the forwarder's scrutiny would have only medium trust. | passed the forwarder's scrutiny would have only medium trust. | |||
4.2. Interpretation | 5.2. Interpretation | |||
A signer that is adding a signature to a message merely creates a new | 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 | DKIM-Signature header, using the usual semantics of the h= option. A | |||
signer MAY sign previously existing DKIM-Signature header fields | signer MAY sign previously existing DKIM-Signature header fields | |||
using the method described in Section 5.4 to sign trace header | using the method described in Section 6.4 to sign trace header | |||
fields. | fields. | |||
INFORMATIVE NOTE: Signers should be cognizant that signing DKIM- | INFORMATIVE NOTE: Signers should be cognizant that signing DKIM- | |||
Signature header fields may result in signature failures with | Signature header fields may result in signature failures with | |||
intermediaries that do not recognize that DKIM-Signature header | intermediaries that do not recognize that DKIM-Signature header | |||
fields are trace header fields and unwittingly reorder them, thus | fields are trace header fields and unwittingly reorder them, thus | |||
breaking such signatures. For this reason, signing existing DKIM- | breaking such signatures. For this reason, signing existing DKIM- | |||
Signature header fields is unadvised, albeit legal. | Signature header fields is unadvised, albeit legal. | |||
INFORMATIVE NOTE: If a header field with multiple instances is | INFORMATIVE NOTE: If a header field with multiple instances is | |||
skipping to change at page 39, line 4 | skipping to change at page 39, line 29 | |||
messages they are signing, even if they know that the signatures | messages they are signing, even if they know that the signatures | |||
cannot be verified. | cannot be verified. | |||
When evaluating a message with multiple signatures, a verifier SHOULD | When evaluating a message with multiple signatures, a verifier SHOULD | |||
evaluate signatures independently and on their own merits. For | evaluate signatures independently and on their own merits. For | |||
example, a verifier that by policy chooses not to accept signatures | example, a verifier that by policy chooses not to accept signatures | |||
with deprecated cryptographic algorithms would consider such | with deprecated cryptographic algorithms would consider such | |||
signatures invalid. Verifiers MAY process signatures in any order of | signatures invalid. Verifiers MAY process signatures in any order of | |||
their choice; for example, some verifiers might choose to process | their choice; for example, some verifiers might choose to process | |||
signatures corresponding to the From field in the message header | signatures corresponding to the From field in the message header | |||
before other signatures. See Section 6.1 for more information about | before other signatures. See Section 7.1 for more information about | |||
signature choices. | signature choices. | |||
INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate | INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate | |||
valid signatures with invalid signatures in an attempt to guess | valid signatures with invalid signatures in an attempt to guess | |||
why a signature failed are ill-advised. In particular, there is | why a signature failed are ill-advised. In particular, there is | |||
no general way that a verifier can determine that an invalid | no general way that a verifier can determine that an invalid | |||
signature was ever valid. | signature was ever valid. | |||
Verifiers SHOULD ignore failed signatures as though they were not | Verifiers SHOULD ignore failed signatures as though they were not | |||
present in the message. Verifiers SHOULD continue to check | present in the message. Verifiers SHOULD continue to check | |||
signatures until a signature successfully verifies to the | signatures until a signature successfully verifies to the | |||
satisfaction of the verifier. To limit potential denial-of-service | satisfaction of the verifier. To limit potential denial-of-service | |||
attacks, verifiers MAY limit the total number of signatures they will | attacks, verifiers MAY limit the total number of signatures they will | |||
attempt to verify. | attempt to verify. | |||
5. Signer Actions | 6. Signer Actions | |||
The following steps are performed in order by signers. | The following steps are performed in order by signers. | |||
5.1. Determine Whether the Email Should Be Signed and by Whom | 6.1. Determine Whether the Email Should Be Signed and by Whom | |||
A signer can obviously only sign email for domains for which it has a | A signer can obviously only sign email for domains for which it has a | |||
private key and the necessary knowledge of the corresponding public | private key and the necessary knowledge of the corresponding public | |||
key and selector information. However, there are a number of other | key and selector information. However, there are a number of other | |||
reasons beyond the lack of a private key why a signer could choose | reasons beyond the lack of a private key why a signer could choose | |||
not to sign an email. | not to sign an email. | |||
INFORMATIVE NOTE: Signing modules may be incorporated into any | INFORMATIVE NOTE: Signing modules may be incorporated into any | |||
portion of the mail system as deemed appropriate, including an | portion of the mail system as deemed appropriate, including an | |||
MUA, a SUBMISSION server, or an MTA. Wherever implemented, | MUA, a SUBMISSION server, or an MTA. Wherever implemented, | |||
skipping to change at page 40, line 5 | skipping to change at page 40, line 31 | |||
authenticated and authorized. | authenticated and authorized. | |||
INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign | INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign | |||
Received header fields if the outgoing gateway MTA obfuscates | Received header fields if the outgoing gateway MTA obfuscates | |||
Received header fields, for example, to hide the details of | Received header fields, for example, to hide the details of | |||
internal topology. | internal topology. | |||
If an email cannot be signed for some reason, it is a local policy | If an email cannot be signed for some reason, it is a local policy | |||
decision as to what to do with that email. | decision as to what to do with that email. | |||
5.2. Select a Private Key and Corresponding Selector Information | 6.2. Select a Private Key and Corresponding Selector Information | |||
This specification does not define the basis by which a signer should | This specification does not define the basis by which a signer should | |||
choose which private key and selector information to use. Currently, | choose which private key and selector information to use. Currently, | |||
all selectors are equal as far as this specification is concerned, so | all selectors are equal as far as this specification is concerned, so | |||
the decision should largely be a matter of administrative | the decision should largely be a matter of administrative | |||
convenience. Distribution and management of private keys is also | convenience. Distribution and management of private keys is also | |||
outside the scope of this document. | outside the scope of this document. | |||
INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | |||
private key when the selector containing the corresponding public | private key when the selector containing the corresponding public | |||
key is expected to be revoked or removed before the verifier has | key is expected to be revoked or removed before the verifier has | |||
an opportunity to validate the signature. The signer should | an opportunity to validate the signature. The signer should | |||
anticipate that verifiers may choose to defer validation, perhaps | anticipate that verifiers may choose to defer validation, perhaps | |||
until the message is actually read by the final recipient. In | until the message is actually read by the final recipient. In | |||
particular, when rotating to a new key pair, signing should | particular, when rotating to a new key pair, signing should | |||
immediately commence with the new private key and the old public | immediately commence with the new private key and the old public | |||
key should be retained for a reasonable validation interval before | key should be retained for a reasonable validation interval before | |||
being removed from the key server. | being removed from the key server. | |||
5.3. Normalize the Message to Prevent Transport Conversions | 6.3. Normalize the Message to Prevent Transport Conversions | |||
Some messages, particularly those using 8-bit characters, are subject | Some messages, particularly those using 8-bit characters, are subject | |||
to modification during transit, notably conversion to 7-bit form. | to modification during transit, notably conversion to 7-bit form. | |||
Such conversions will break DKIM signatures. In order to minimize | Such conversions will break DKIM signatures. In order to minimize | |||
the chances of such breakage, signers SHOULD convert the message to a | the chances of such breakage, signers SHOULD convert the message to a | |||
suitable MIME content transfer encoding such as quoted-printable or | suitable MIME content transfer encoding such as quoted-printable or | |||
base64 as described in [RFC2045] before signing. Such conversion is | base64 as described in [RFC2045] before signing. Such conversion is | |||
outside the scope of DKIM; the actual message SHOULD be converted to | 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 | 7-bit MIME by an MUA or MSA prior to presentation to the DKIM | |||
algorithm. | algorithm. | |||
skipping to change at page 41, line 9 | skipping to change at page 41, line 38 | |||
bare CR or LF characters (used by some systems as a local line | bare CR or LF characters (used by some systems as a local line | |||
separator convention) MUST be converted to the SMTP-standard CRLF | separator convention) MUST be converted to the SMTP-standard CRLF | |||
sequence before the message is signed. Any conversion of this sort | sequence before the message is signed. Any conversion of this sort | |||
SHOULD be applied to the message actually sent to the recipient(s), | SHOULD be applied to the message actually sent to the recipient(s), | |||
not just to the version presented to the signing algorithm. | not just to the version presented to the signing algorithm. | |||
More generally, the signer MUST sign the message as it is expected to | 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 | be received by the verifier rather than in some local or internal | |||
form. | form. | |||
5.4. Determine the Header Fields to Sign | 6.4. Determine the Header Fields to Sign | |||
The From header field MUST be signed (that is, included in the "h=" | The From header field MUST be signed (that is, included in the "h=" | |||
tag of the resulting DKIM-Signature header field). Signers SHOULD | tag of the resulting DKIM-Signature header field). Signers SHOULD | |||
NOT sign an existing header field likely to be legitimately modified | NOT sign an existing header field likely to be legitimately modified | |||
or removed in transit. In particular, [RFC5321] explicitly permits | or removed in transit. In particular, [RFC5321] explicitly permits | |||
modification or removal of the Return-Path header field in transit. | modification or removal of the Return-Path header field in transit. | |||
Signers MAY include any other header fields present at the time of | Signers MAY include any other header fields present at the time of | |||
signing at the discretion of the signer. | signing at the discretion of the signer. | |||
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to | INFORMATIVE OPERATIONS NOTE: The choice of which header fields to | |||
skipping to change at page 43, line 6 | skipping to change at page 43, line 37 | |||
instances by intermediate MTAs will cause DKIM signatures to be | instances by intermediate MTAs will cause DKIM signatures to be | |||
broken; such anti-social behavior should be avoided. | broken; such anti-social behavior should be avoided. | |||
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | |||
specification, all end-user visible header fields should be signed | specification, all end-user visible header fields should be signed | |||
to avoid possible "indirect spamming". For example, if the | to avoid possible "indirect spamming". For example, if the | |||
Subject header field is not signed, a spammer can resend a | Subject header field is not signed, a spammer can resend a | |||
previously signed mail, replacing the legitimate subject with a | previously signed mail, replacing the legitimate subject with a | |||
one-line spam. | one-line spam. | |||
5.5. Recommended Signature Content | 6.5. Recommended Signature Content | |||
In order to maximize compatibility with a variety of verifiers, it is | In order to maximize compatibility with a variety of verifiers, it is | |||
recommended that signers follow the practices outlined in this | recommended that signers follow the practices outlined in this | |||
section when signing a message. However, these are generic | section when signing a message. However, these are generic | |||
recommendations applying to the general case; specific senders may | recommendations applying to the general case; specific senders may | |||
wish to modify these guidelines as required by their unique | wish to modify these guidelines as required by their unique | |||
situations. Verifiers MUST be capable of verifying signatures even | situations. Verifiers MUST be capable of verifying signatures even | |||
if one or more of the recommended header fields is not signed (with | 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 | the exception of From, which must always be signed) or if one or more | |||
of the dis-recommended header fields is signed. Note that verifiers | of the dis-recommended header fields is signed. Note that verifiers | |||
skipping to change at page 44, line 38 | skipping to change at page 45, line 19 | |||
Signers SHOULD NOT use "l=" unless they intend to accommodate | Signers SHOULD NOT use "l=" unless they intend to accommodate | |||
intermediate mail processors that append text to a message. For | intermediate mail processors that append text to a message. For | |||
example, many mailing list processors append "unsubscribe" | example, many mailing list processors append "unsubscribe" | |||
information to message bodies. If signers use "l=", they SHOULD | information to message bodies. If signers use "l=", they SHOULD | |||
include the entire message body existing at the time of signing in | include the entire message body existing at the time of signing in | |||
computing the count. In particular, signers SHOULD NOT specify a | computing the count. In particular, signers SHOULD NOT specify a | |||
body length of 0 since this may be interpreted as a meaningless | body length of 0 since this may be interpreted as a meaningless | |||
signature by some verifiers. | signature by some verifiers. | |||
5.6. Compute the Message Hash and Signature | 6.6. Compute the Message Hash and Signature | |||
The signer MUST compute the message hash as described in Section 3.7 | The signer MUST compute the message hash as described in Section 4.7 | |||
and then sign it using the selected public-key algorithm. This will | and then sign it using the selected public-key algorithm. This will | |||
result in a DKIM-Signature header field that will include the body | result in a DKIM-Signature header field that will include the body | |||
hash and a signature of the header hash, where that header includes | hash and a signature of the header hash, where that header includes | |||
the DKIM-Signature header field itself. | the DKIM-Signature header field itself. | |||
Entities such as mailing list managers that implement DKIM and that | Entities such as mailing list managers that implement DKIM and that | |||
modify the message or a header field (for example, inserting | modify the message or a header field (for example, inserting | |||
unsubscribe information) before retransmitting the message SHOULD | unsubscribe information) before retransmitting the message SHOULD | |||
check any existing signature on input and MUST make such | check any existing signature on input and MUST make such | |||
modifications before re-signing the message. | modifications before re-signing the message. | |||
The signer MAY elect to limit the number of bytes of the body that | 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 | will be included in the hash and hence signed. The length actually | |||
hashed should be inserted in the "l=" tag of the DKIM-Signature | hashed should be inserted in the "l=" tag of the DKIM-Signature | |||
header field. | header field. | |||
5.7. Insert the DKIM-Signature Header Field | 6.7. Insert the DKIM-Signature Header Field | |||
Finally, the signer MUST insert the DKIM-Signature header field | Finally, the signer MUST insert the DKIM-Signature header field | |||
created in the previous step prior to transmitting the email. The | created in the previous step prior to transmitting the email. The | |||
DKIM-Signature header field MUST be the same as used to compute 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 | hash as described above, except that the value of the "b=" tag MUST | |||
be the appropriately signed hash computed in the previous step, | be the appropriately signed hash computed in the previous step, | |||
signed using the algorithm specified in the "a=" tag of the DKIM- | signed using the algorithm specified in the "a=" tag of the DKIM- | |||
Signature header field and using the private key corresponding to the | Signature header field and using the private key corresponding to the | |||
selector given in the "s=" tag of the DKIM-Signature header field, as | selector given in the "s=" tag of the DKIM-Signature header field, as | |||
chosen above in Section 5.2 | chosen above in Section 6.2 | |||
The DKIM-Signature header field MUST be inserted before any other | The DKIM-Signature header field MUST be inserted before any other | |||
DKIM-Signature fields in the header block. | DKIM-Signature fields in the header block. | |||
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this | INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this | |||
is to insert the DKIM-Signature header field at the beginning of | is to insert the DKIM-Signature header field at the beginning of | |||
the header block. In particular, it may be placed before any | the header block. In particular, it may be placed before any | |||
existing Received header fields. This is consistent with treating | existing Received header fields. This is consistent with treating | |||
DKIM-Signature as a trace header field. | DKIM-Signature as a trace header field. | |||
6. Verifier Actions | 7. Verifier Actions | |||
Since a signer MAY remove or revoke a public key at any time, it is | 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 | recommended that verification occur in a timely manner. In many | |||
configurations, the most timely place is during acceptance by the | configurations, the most timely place is during acceptance by the | |||
border MTA or shortly thereafter. In particular, deferring | border MTA or shortly thereafter. In particular, deferring | |||
verification until the message is accessed by the end user is | verification until the message is accessed by the end user is | |||
discouraged. | discouraged. | |||
A border or intermediate MTA MAY verify the message signature(s). An | A border or intermediate MTA MAY verify the message signature(s). An | |||
MTA who has performed verification MAY communicate the result of that | MTA who has performed verification MAY communicate the result of that | |||
skipping to change at page 46, line 10 | skipping to change at page 46, line 38 | |||
A verifying MTA MAY implement a policy with respect to unverifiable | A verifying MTA MAY implement a policy with respect to unverifiable | |||
mail, regardless of whether or not it applies the verification header | mail, regardless of whether or not it applies the verification header | |||
field to signed messages. | field to signed messages. | |||
Verifiers MUST produce a result that is semantically equivalent to | Verifiers MUST produce a result that is semantically equivalent to | |||
applying the following steps in the order listed. In practice, | applying the following steps in the order listed. In practice, | |||
several of these steps can be performed in parallel in order to | several of these steps can be performed in parallel in order to | |||
improve performance. | improve performance. | |||
6.1. Extract Signatures from the Message | 7.1. Extract Signatures from the Message | |||
The order in which verifiers try DKIM-Signature header fields is not | The order in which verifiers try DKIM-Signature header fields is not | |||
defined; verifiers MAY try signatures in any order they like. For | defined; verifiers MAY try signatures in any order they like. For | |||
example, one implementation might try the signatures in textual | example, one implementation might try the signatures in textual | |||
order, whereas another might try signatures by identities that match | order, whereas another might try signatures by identities that match | |||
the contents of the From header field before trying other signatures. | the contents of the From header field before trying other signatures. | |||
Verifiers MUST NOT attribute ultimate meaning to the order of | Verifiers MUST NOT attribute ultimate meaning to the order of | |||
multiple DKIM-Signature header fields. In particular, there is | multiple DKIM-Signature header fields. In particular, there is | |||
reason to believe that some relays will reorder the header fields in | reason to believe that some relays will reorder the header fields in | |||
potentially arbitrary ways. | potentially arbitrary ways. | |||
skipping to change at page 47, line 34 | skipping to change at page 48, line 15 | |||
the original submitter signature in place even though the exploder | the original submitter signature in place even though the exploder | |||
knows that it is modifying the message in some way that will break | knows that it is modifying the message in some way that will break | |||
that signature, and the exploder inserts its own signature. In | that signature, and the exploder inserts its own signature. In | |||
this case, the message should succeed even in the presence of the | this case, the message should succeed even in the presence of the | |||
known-broken signature. | known-broken signature. | |||
For each signature to be validated, the following steps should be | For each signature to be validated, the following steps should be | |||
performed in such a manner as to produce a result that is | performed in such a manner as to produce a result that is | |||
semantically equivalent to performing them in the indicated order. | semantically equivalent to performing them in the indicated order. | |||
6.1.1. Validate the Signature Header Field | 7.1.1. Validate the Signature Header Field | |||
Implementers MUST meticulously validate the format and values in the | Implementers MUST meticulously validate the format and values in the | |||
DKIM-Signature header field; any inconsistency or unexpected values | DKIM-Signature header field; any inconsistency or unexpected values | |||
MUST cause the header field to be completely ignored and the verifier | MUST cause the header field to be completely ignored and the verifier | |||
to return PERMFAIL (signature syntax error). Being "liberal in what | to return PERMFAIL (signature syntax error). Being "liberal in what | |||
you accept" is definitely a bad strategy in this security context. | you accept" is definitely a bad strategy in this security context. | |||
Note however that this does not include the existence of unknown tags | Note however that this does not include the existence of unknown tags | |||
in a DKIM-Signature header field, which are explicitly permitted. | in a DKIM-Signature header field, which are explicitly permitted. | |||
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag | Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag | |||
that is inconsistent with this specification and return PERMFAIL | that is inconsistent with this specification and return PERMFAIL | |||
(incompatible version). | (incompatible version). | |||
INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, | INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, | |||
choose to also verify signatures generated by older versions of | choose to also verify signatures generated by older versions of | |||
this specification. | this specification. | |||
If any tag listed as "required" in Section 3.5 is omitted from the | If any tag listed as "required" in Section 4.5 is omitted from the | |||
DKIM-Signature header field, the verifier MUST ignore the DKIM- | DKIM-Signature header field, the verifier MUST ignore the DKIM- | |||
Signature header field and return PERMFAIL (signature missing | Signature header field and return PERMFAIL (signature missing | |||
required tag). | required tag). | |||
INFORMATIONAL NOTE: The tags listed as required in Section 3.5 are | INFORMATIONAL NOTE: The tags listed as required in Section 4.5 are | |||
"v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a | "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a | |||
conflict between this note and Section 3.5, Section 3.5 is | conflict between this note and Section 4.5, Section 4.5 is | |||
normative. | normative. | |||
If the DKIM-Signature header field does not contain the "i=" tag, the | 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 | verifier MUST behave as though the value of that tag were "@d", where | |||
"d" is the value from the "d=" tag. | "d" is the value from the "d=" tag. | |||
Verifiers MUST confirm that the domain specified in the "d=" tag is | 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. | 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 | If not, the DKIM-Signature header field MUST be ignored and the | |||
verifier should return PERMFAIL (domain mismatch). | verifier should return PERMFAIL (domain mismatch). | |||
skipping to change at page 48, line 43 | skipping to change at page 49, line 24 | |||
"com" and "co.uk" may be ignored. The list of unacceptable domains | "com" and "co.uk" may be ignored. The list of unacceptable domains | |||
SHOULD be configurable. | SHOULD be configurable. | |||
Verifiers MAY ignore the DKIM-Signature header field and return | Verifiers MAY ignore the DKIM-Signature header field and return | |||
PERMFAIL (unacceptable signature header) for any other reason, for | PERMFAIL (unacceptable signature header) for any other reason, for | |||
example, if the signature does not sign header fields that the | example, if the signature does not sign header fields that the | |||
verifier views to be essential. As a case in point, if MIME header | verifier views to be essential. As a case in point, if MIME header | |||
fields are not signed, certain attacks may be possible that the | fields are not signed, certain attacks may be possible that the | |||
verifier would prefer to avoid. | verifier would prefer to avoid. | |||
6.1.2. Get the Public Key | 7.1.2. Get the Public Key | |||
The public key for a signature is needed to complete the verification | The public key for a signature is needed to complete the verification | |||
process. The process of retrieving the public key depends on the | process. The process of retrieving the public key depends on the | |||
query type as defined by the "q=" tag in the DKIM-Signature header | 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 | field. Obviously, a public key need only be retrieved if the process | |||
of extracting the signature information is completely successful. | of extracting the signature information is completely successful. | |||
Details of key management and representation are described in | Details of key management and representation are described in | |||
Section 3.6. The verifier MUST validate the key record and MUST | Section 4.6. The verifier MUST validate the key record and MUST | |||
ignore any public key records that are malformed. | ignore any public key records that are malformed. | |||
NOTE: The use of a wildcard TXT record that covers a queried DKIM | NOTE: The use of a wildcard TXT record that covers a queried DKIM | |||
domain name will produce a response to a DKIM query that is | domain name will produce a response to a DKIM query that is | |||
unlikely to be valid DKIM key record. This problem is not | unlikely to be valid DKIM key record. This problem is not | |||
specific to DKIM and applies to many other types of queries. | specific to DKIM and applies to many other types of queries. | |||
Client software that processes DNS responses needs to take this | Client software that processes DNS responses needs to take this | |||
problem into account. | problem into account. | |||
When validating a message, a verifier MUST perform the following | When validating a message, a verifier MUST perform the following | |||
steps in a manner that is semantically the same as performing them in | steps in a manner that is semantically the same as performing them in | |||
the order indicated -- in some cases the implementation may | the order indicated -- in some cases the implementation may | |||
parallelize or reorder these steps, as long as the semantics remain | parallelize or reorder these steps, as long as the semantics remain | |||
unchanged: | unchanged: | |||
1. Retrieve the public key as described in Section 3.6 using the | 1. Retrieve the public key as described in Section 4.6 using the | |||
algorithm in the "q=" tag, the domain from the "d=" tag, and the | algorithm in the "q=" tag, the domain from the "d=" tag, and the | |||
selector from the "s=" tag. | selector from the "s=" tag. | |||
2. If the query for the public key fails to respond, the verifier | 2. If the query for the public key fails to respond, the verifier | |||
MAY defer acceptance of this email and return TEMPFAIL (key | MAY defer acceptance of this email and return TEMPFAIL (key | |||
unavailable). If verification is occurring during the incoming | unavailable). If verification is occurring during the incoming | |||
SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply | SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply | |||
code. Alternatively, the verifier MAY store the message in the | code. Alternatively, the verifier MAY store the message in the | |||
local queue for later trial or ignore the signature. Note that | local queue for later trial or ignore the signature. Note that | |||
storing a message in the local queue is subject to denial-of- | storing a message in the local queue is subject to denial-of- | |||
skipping to change at page 50, line 22 | skipping to change at page 51, line 5 | |||
been revoked and the verifier MUST treat this as a failed | been revoked and the verifier MUST treat this as a failed | |||
signature check and return PERMFAIL (key revoked). There is no | signature check and return PERMFAIL (key revoked). There is no | |||
defined semantic difference between a key that has been revoked | defined semantic difference between a key that has been revoked | |||
and a key record that has been removed. | and a key record that has been removed. | |||
8. If the public key data is not suitable for use with the algorithm | 8. 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- | and key types defined by the "a=" and "k=" tags in the DKIM- | |||
Signature header field, the verifier MUST immediately return | Signature header field, the verifier MUST immediately return | |||
PERMFAIL (inappropriate key algorithm). | PERMFAIL (inappropriate key algorithm). | |||
6.1.3. Compute the Verification | 7.1.3. Compute the Verification | |||
Given a signer and a public key, verifying a signature consists of | Given a signer and a public key, verifying a signature consists of | |||
actions semantically equivalent to the following steps. | actions semantically equivalent to the following steps. | |||
1. Based on the algorithm defined in the "c=" tag, the body length | 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=" | specified in the "l=" tag, and the header field names in the "h=" | |||
tag, prepare a canonicalized version of the message as is | tag, prepare a canonicalized version of the message as is | |||
described in Section 3.7 (note that this version does not | described in Section 4.7 (note that this version does not | |||
actually need to be instantiated). When matching header field | actually need to be instantiated). When matching header field | |||
names in the "h=" tag against the actual message header field, | names in the "h=" tag against the actual message header field, | |||
comparisons MUST be case-insensitive. | comparisons MUST be case-insensitive. | |||
2. Based on the algorithm indicated in the "a=" tag, compute the | 2. Based on the algorithm indicated in the "a=" tag, compute the | |||
message hashes from the canonical copy as described in | message hashes from the canonical copy as described in | |||
Section 3.7. | Section 4.7. | |||
3. Verify that the hash of the canonicalized message body computed | 3. Verify that the hash of the canonicalized message body computed | |||
in the previous step matches the hash value conveyed in the "bh=" | in the previous step matches the hash value conveyed in the "bh=" | |||
tag. If the hash does not match, the verifier SHOULD ignore the | tag. If the hash does not match, the verifier SHOULD ignore the | |||
signature and return PERMFAIL (body hash did not verify). | signature and return PERMFAIL (body hash did not verify). | |||
4. Using the signature conveyed in the "b=" tag, verify the | 4. Using the signature conveyed in the "b=" tag, verify the | |||
signature against the header hash using the mechanism appropriate | signature against the header hash using the mechanism appropriate | |||
for the public key algorithm described in the "a=" tag. If the | for the public key algorithm described in the "a=" tag. If the | |||
signature does not validate, the verifier SHOULD ignore the | signature does not validate, the verifier SHOULD ignore the | |||
skipping to change at page 51, line 18 | skipping to change at page 51, line 48 | |||
calculated. Implementations may also verify the signature on the | calculated. Implementations may also verify the signature on the | |||
message header before validating that the message hash listed in | message header before validating that the message hash listed in | |||
the "bh=" tag in the DKIM-Signature header field matches that of | 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 actual message body; however, if the body hash does not match, | |||
the entire signature must be considered to have failed. | the entire signature must be considered to have failed. | |||
A body length specified in the "l=" tag of the signature limits the | A body length specified in the "l=" tag of the signature limits the | |||
number of bytes of the body passed to the verification algorithm. | number of bytes of the body passed to the verification algorithm. | |||
All data beyond that limit is not validated by DKIM. Hence, | All data beyond that limit is not validated by DKIM. Hence, | |||
verifiers might treat a message that contains bytes beyond the | verifiers might treat a message that contains bytes beyond the | |||
indicated body length with suspicion, such as by truncating the | indicated body length with suspicion, such as by declaring the | |||
message at the indicated body length, declaring the signature invalid | signature invalid (e.g., by returning PERMFAIL (unsigned content)), | |||
(e.g., by returning PERMFAIL (unsigned content)), or conveying the | or conveying the partial verification to the policy module. {DKIM 2} | |||
partial verification to the policy module. | ||||
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. | ||||
6.2. Communicate Verification Results | 7.2. Communicate Verification Results | |||
Verifiers wishing to communicate the results of verification to other | Verifiers wishing to communicate the results of verification to other | |||
parts of the mail system may do so in whatever manner they see fit. | parts of the mail system may do so in whatever manner they see fit. | |||
For example, implementations might choose to add an email header | For example, implementations might choose to add an email header | |||
field to the message before passing it on. Any such header field | field to the message before passing it on. Any such header field | |||
SHOULD be inserted before any existing DKIM-Signature or preexisting | SHOULD be inserted before any existing DKIM-Signature or preexisting | |||
authentication status header fields in the header field block. The | authentication status header fields in the header field block. The | |||
Authentication-Results: header field ([RFC5451]) MAY be used for this | Authentication-Results: header field ([RFC5451]) MAY be used for this | |||
purpose. | purpose. | |||
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | |||
search for results header fields to visibly mark authenticated | search for results header fields to visibly mark authenticated | |||
mail for end users should verify that such header field was added | mail for end users should verify that such header field was added | |||
by the appropriate verifying domain and that the verified identity | by the appropriate verifying domain and that the verified identity | |||
matches the author identity that will be displayed by the MUA. In | matches the author identity that will be displayed by the MUA. In | |||
particular, MUA filters should not be influenced by bogus results | particular, MUA filters should not be influenced by bogus results | |||
header fields added by attackers. To circumvent this attack, | header fields added by attackers. To circumvent this attack, | |||
verifiers may wish to delete existing results header fields after | verifiers may wish to delete existing results header fields after | |||
verification and before adding a new header field. | verification and before adding a new header field. | |||
6.3. Interpret Results/Apply Local Policy | 7.3. Interpret Results/Apply Local Policy | |||
It is beyond the scope of this specification to describe what actions | It is beyond the scope of this specification to describe what actions | |||
an Identity Assessor can make, but mail carrying a validated SDID | an Identity Assessor can make, but mail carrying a validated SDID | |||
presents an opportunity to an Identity Assessor that unauthenticated | presents an opportunity to an Identity Assessor that unauthenticated | |||
email does not. Specifically, an authenticated email creates a | email does not. Specifically, an authenticated email creates a | |||
predictable identifier by which other decisions can reliably be | predictable identifier by which other decisions can reliably be | |||
managed, such as trust and reputation. Conversely, unauthenticated | managed, such as trust and reputation. Conversely, unauthenticated | |||
email lacks a reliable identifier that can be used to assign trust | email lacks a reliable identifier that can be used to assign trust | |||
and reputation. It is reasonable to treat unauthenticated email as | and reputation. It is reasonable to treat unauthenticated email as | |||
lacking any trust and having no positive reputation. | lacking any trust and having no positive reputation. | |||
skipping to change at page 52, line 44 | skipping to change at page 53, line 15 | |||
SMTP reply code. In particular, cryptographic signature verification | SMTP reply code. In particular, cryptographic signature verification | |||
failures MUST NOT return 4xx SMTP replies. | failures MUST NOT return 4xx SMTP replies. | |||
Once the signature has been verified, that information MUST be | Once the signature has been verified, that information MUST be | |||
conveyed to the Identity Assessor (such as an explicit allow/ | conveyed to the Identity Assessor (such as an explicit allow/ | |||
whitelist and reputation system) and/or to the end user. If the SDID | whitelist and reputation system) and/or to the end user. If the SDID | |||
is not the same as the address in the From: header field, the mail | is not the same as the address in the From: header field, the mail | |||
system SHOULD take pains to ensure that the actual SDID is clear to | system SHOULD take pains to ensure that the actual SDID is clear to | |||
the reader. | the reader. | |||
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. | ||||
While the symptoms of a failed verification are obvious -- the | While the symptoms of a failed verification are obvious -- the | |||
signature doesn't verify -- establishing the exact cause can be more | signature doesn't verify -- establishing the exact cause can be more | |||
difficult. If a selector cannot be found, is that because the | difficult. If a selector cannot be found, is that because the | |||
selector has been removed, or was the value changed somehow in | selector has been removed, or was the value changed somehow in | |||
transit? If the signature line is missing, is that because it was | transit? If the signature line is missing, is that because it was | |||
never there, or was it removed by an overzealous filter? For | never there, or was it removed by an overzealous filter? For | |||
diagnostic purposes, the exact reason why the verification fails | diagnostic purposes, the exact reason why the verification fails | |||
SHOULD be made available to the policy module and possibly recorded | SHOULD be made available to the policy module and possibly recorded | |||
in the system logs. If the email cannot be verified, then it SHOULD | 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 | be treated {DKIM 2} the same as all unverified email regardless of | |||
not it looks like it was signed. | whether or not it looks like it was signed. | |||
7. IANA Considerations | 8. IANA Considerations | |||
DKIM has registered namespaces with IANA. In all cases, new values | DKIM has registered namespaces with IANA. In all cases, new values | |||
are assigned only for values that have been documented in a published | are assigned only for values that have been documented in a published | |||
RFC that has IETF Consensus [RFC5226]. | RFC that has IETF Consensus [RFC5226]. | |||
This memo updates these registries as described below. Of note is | This memo updates these registries as described below. Of note is | |||
the addition of a new "status" column. All registrations into these | the addition of a new "status" column. All registrations into these | |||
namespaces MUST include the name being registered, the document in | namespaces MUST include the name being registered, the document in | |||
which it was registered or updated, and an indication of its current | which it was registered or updated, and an indication of its current | |||
status which MUST be one of "active" (in current use) or "historic" | status which MUST be one of "active" (in current use) or "historic" | |||
(no longer in current use). | (no longer in current use). | |||
7.1. DKIM-Signature Tag Specifications | 8.1. DKIM-Signature Tag Specifications | |||
A DKIM-Signature provides for a list of tag specifications. IANA has | A DKIM-Signature provides for a list of tag specifications. IANA has | |||
established the DKIM-Signature Tag Specification Registry for tag | established the DKIM-Signature Tag Specification Registry for tag | |||
specifications that can be used in DKIM-Signature fields. | specifications that can be used in DKIM-Signature fields. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
skipping to change at page 54, line 26 | skipping to change at page 54, line 26 | |||
| l | (this document) | active | | | l | (this document) | active | | |||
| q | (this document) | active | | | q | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
| t | (this document) | active | | | t | (this document) | active | | |||
| x | (this document) | active | | | x | (this document) | active | | |||
| z | (this document) | active | | | z | (this document) | active | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
Table 1: DKIM-Signature Tag Specification Registry Updated Values | Table 1: DKIM-Signature Tag Specification Registry Updated Values | |||
7.2. DKIM-Signature Query Method Registry | 8.2. DKIM-Signature Query Method Registry | |||
The "q=" tag-spec (specified in Section 3.5) provides for a list of | The "q=" tag-spec (specified in Section 4.5) provides for a list of | |||
query methods. | query methods. | |||
IANA has established the DKIM-Signature Query Method Registry for | IANA has established the DKIM-Signature Query Method Registry for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM. | validation processing of a message signed using DKIM. | |||
The updated entry in the registry comprises: | The updated entry in the registry comprises: | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
| TYPE | OPTION | REFERENCE | STATUS | | | TYPE | OPTION | REFERENCE | STATUS | | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
| dns | txt | (this document) | active | | | dns | txt | (this document) | active | | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
DKIM-Signature Query Method Registry Updated Values | DKIM-Signature Query Method Registry Updated Values | |||
7.3. DKIM-Signature Canonicalization Registry | 8.3. DKIM-Signature Canonicalization Registry | |||
The "c=" tag-spec (specified in Section 3.5) provides for a specifier | The "c=" tag-spec (specified in Section 4.5) provides for a specifier | |||
for canonicalization algorithms for the header and body of the | for canonicalization algorithms for the header and body of the | |||
message. | message. | |||
IANA has established the DKIM-Signature Canonicalization Algorithm | IANA has established the DKIM-Signature Canonicalization Algorithm | |||
Registry for algorithms for converting a message into a canonical | Registry for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM. | form before signing or verifying using DKIM. | |||
The updated entries in the header registry comprise: | The updated entries in the header registry comprise: | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
skipping to change at page 55, line 30 | skipping to change at page 55, line 30 | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| simple | (this document) | active | | | simple | (this document) | active | | |||
| relaxed | (this document) | active | | | relaxed | (this document) | active | | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
DKIM-Signature Body Canonicalization Algorithm Registry | DKIM-Signature Body Canonicalization Algorithm Registry | |||
Updated Values | Updated Values | |||
7.4. _domainkey DNS TXT Record Tag Specifications | 8.4. _domainkey DNS TXT Record Tag Specifications | |||
A _domainkey DNS TXT record provides for a list of tag | A _domainkey DNS TXT record provides for a list of tag | |||
specifications. IANA has established the DKIM _domainkey DNS TXT Tag | specifications. IANA has established the DKIM _domainkey DNS TXT Tag | |||
Specification Registry for tag specifications that can be used in DNS | Specification Registry for tag specifications that can be used in DNS | |||
TXT Records. | TXT Records. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+----------+ | +------+-----------------+----------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
skipping to change at page 56, line 8 | skipping to change at page 56, line 8 | |||
| k | (this document) | active | | | k | (this document) | active | | |||
| n | (this document) | active | | | n | (this document) | active | | |||
| p | (this document) | active | | | p | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
| t | (this document) | active | | | t | (this document) | active | | |||
+------+-----------------+----------+ | +------+-----------------+----------+ | |||
DKIM _domainkey DNS TXT Record Tag Specification Registry | DKIM _domainkey DNS TXT Record Tag Specification Registry | |||
Updated Values | Updated Values | |||
7.5. DKIM Key Type Registry | 8.5. DKIM Key Type Registry | |||
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "k=" <key-k-tag> (specified in Section 4.6.1) and the "a=" <sig- | |||
a-tag-k> (specified in Section 3.5) tags provide for a list of | a-tag-k> (specified in Section 4.5) tags provide for a list of | |||
mechanisms that can be used to decode a DKIM signature. | mechanisms that can be used to decode a DKIM signature. | |||
IANA has established the DKIM Key Type Registry for such mechanisms. | IANA has established the DKIM Key Type Registry for such mechanisms. | |||
The updated entry in the registry comprises: | The updated entry in the registry comprises: | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
| rsa | [RFC3447] | active | | | rsa | [RFC3447] | active | | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
DKIM Key Type Updated Values | DKIM Key Type Updated Values | |||
7.6. DKIM Hash Algorithms Registry | 8.6. DKIM Hash Algorithms Registry | |||
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "h=" <key-h-tag> (specified in Section 4.6.1) and the "a=" <sig- | |||
a-tag-h> (specified in Section 3.5) tags provide for a list of | a-tag-h> (specified in Section 4.5) tags provide for a list of | |||
mechanisms that can be used to produce a digest of message data. | mechanisms that can be used to produce a digest of message data. | |||
IANA has established the DKIM Hash Algorithms Registry for such | IANA has established the DKIM Hash Algorithms Registry for such | |||
mechanisms. | mechanisms. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
| sha1 | [FIPS-180-2-2002] | active | | | sha1 | [FIPS-180-2-2002] | active | | |||
| sha256 | [FIPS-180-2-2002] | active | | | sha256 | [FIPS-180-2-2002] | active | | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
DKIM Hash Algorithms Updated Values | DKIM Hash Algorithms Updated Values | |||
7.7. DKIM Service Types Registry | 8.7. DKIM Service Types Registry | |||
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | The "s=" <key-s-tag> tag (specified in Section 4.6.1) provides for a | |||
list of service types to which this selector may apply. | list of service types to which this selector may apply. | |||
IANA has established the DKIM Service Types Registry for service | IANA has established the DKIM Service Types Registry for service | |||
types. | types. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
| email | (this document) | active | | | email | (this document) | active | | |||
| * | (this document) | active | | | * | (this document) | active | | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
DKIM Service Types Registry Updated Values | DKIM Service Types Registry Updated Values | |||
7.8. DKIM Selector Flags Registry | 8.8. DKIM Selector Flags Registry | |||
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> tag (specified in Section 4.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA has established the DKIM Selector Flags Registry for additional | IANA has established the DKIM Selector Flags Registry for additional | |||
flags. | flags. | |||
The updated entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| y | (this document) | active | | | y | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
DKIM Selector Flags Registry Updated Values | DKIM Selector Flags Registry Updated Values | |||
7.9. DKIM-Signature Header Field | 8.9. DKIM-Signature Header Field | |||
IANA has added DKIM-Signature to the "Permanent Message Header | IANA has added DKIM-Signature to the "Permanent Message Header | |||
Fields" registry (see [RFC3864]) for the "mail" protocol, using this | Fields" registry (see [RFC3864]) for the "mail" protocol, using this | |||
document as the reference. | document as the reference. | |||
8. Security Considerations | 9. Security Considerations | |||
It has been observed that any mechanism that is introduced that | It has been observed that any mechanism that is introduced that | |||
attempts to stem the flow of spam is subject to intensive attack. | attempts to stem the flow of spam is subject to intensive attack. | |||
DKIM needs to be carefully scrutinized to identify potential attack | DKIM needs to be carefully scrutinized to identify potential attack | |||
vectors and the vulnerability to each. See also [RFC4686]. | vectors and the vulnerability to each. See also [RFC4686]. | |||
8.1. Misuse of Body Length Limits ("l=" Tag) | 9.1. Misuse of Body Length Limits ("l=" Tag) | |||
Body length limits (in the form of the "l=" tag) are subject to | Body length limits (in the form of the "l=" tag) are subject to | |||
several potential attacks. | several potential attacks. | |||
8.1.1. Addition of New MIME Parts to Multipart/* | 9.1.1. Addition of New MIME Parts to Multipart/* | |||
If the body length limit does not cover a closing MIME multipart | If the body length limit does not cover a closing MIME multipart | |||
section (including the trailing "--CRLF" portion), then it is | section (including the trailing "--CRLF" portion), then it is | |||
possible for an attacker to intercept a properly signed multipart | possible for an attacker to intercept a properly signed multipart | |||
message and add a new body part. Depending on the details of the | message and add a new body part. Depending on the details of the | |||
MIME type and the implementation of the verifying MTA and the | MIME type and the implementation of the verifying MTA and the | |||
receiving MUA, this could allow an attacker to change the information | receiving MUA, this could allow an attacker to change the information | |||
displayed to an end user from an apparently trusted source. | displayed to an end user from an apparently trusted source. | |||
For example, if attackers can append information to a "text/html" | 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 | 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 | continue to read after a "</html>" marker, and thus display HTML text | |||
on top of already displayed text. If a message has a "multipart/ | 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 | alternative" body part, they might be able to add a new body part | |||
that is preferred by the displaying MUA. | that is preferred by the displaying MUA. | |||
8.1.2. Addition of new HTML content to existing content | 9.1.2. Addition of new HTML content to existing content | |||
Several receiving MUA implementations do not cease display after a | Several receiving MUA implementations do not cease display after a | |||
""</html>"" tag. In particular, this allows attacks involving | ""</html>"" tag. In particular, this allows attacks involving | |||
overlaying images on top of existing text. | overlaying images on top of existing text. | |||
INFORMATIVE EXAMPLE: Appending the following text to an existing, | INFORMATIVE EXAMPLE: Appending the following text to an existing, | |||
properly closed message will in many MUAs result in inappropriate | properly closed message will in many MUAs result in inappropriate | |||
data being rendered on top of existing, correct data: | data being rendered on top of existing, correct data: | |||
<div style="position: relative; bottom: 350px; z-index: 2;"> | <div style="position:relative; bottom:350px; z-index:2;"> | |||
<img src="http://www.ietf.org/images/ietflogo2e.gif" width=578 height=370> </div> | <img src="http://www.ietf.org/images/ietflogo2e.gif" | |||
width=578 height=370> </div> | ||||
8.2. Misappropriated Private Key | 9.2. Misappropriated Private Key | |||
If the private key for a user is resident on their computer and is | If the private key for a user is resident on their computer and is | |||
not protected by an appropriately secure mechanism, it is possible | not protected by an appropriately secure mechanism, it is possible | |||
for malware to send mail as that user and any other user sharing the | 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 | same private key. The malware would not, however, be able to | |||
generate signed spoofs of other signers' addresses, which would aid | generate signed spoofs of other signers' addresses, which would aid | |||
in identification of the infected user and would limit the | in identification of the infected user and would limit the | |||
possibilities for certain types of attacks involving socially | possibilities for certain types of attacks involving socially | |||
engineered messages. This threat applies mainly to MUA-based | engineered messages. This threat applies mainly to MUA-based | |||
implementations; protection of private keys on servers can be easily | implementations; protection of private keys on servers can be easily | |||
skipping to change at page 59, line 28 | skipping to change at page 59, line 29 | |||
A somewhat more effective countermeasure is to send messages through | A somewhat more effective countermeasure is to send messages through | |||
an outgoing MTA that can authenticate the submitter using existing | an outgoing MTA that can authenticate the submitter using existing | |||
techniques (e.g., SMTP Authentication), possibly validate the message | techniques (e.g., SMTP Authentication), possibly validate the message | |||
itself (e.g., verify that the header is legitimate and that the | itself (e.g., verify that the header is legitimate and that the | |||
content passes a spam content check), and sign the message using a | content passes a spam content check), and sign the message using a | |||
key appropriate for the submitter address. Such an MTA can also | key appropriate for the submitter address. Such an MTA can also | |||
apply controls on the volume of outgoing mail each user is permitted | apply controls on the volume of outgoing mail each user is permitted | |||
to originate in order to further limit the ability of malware to | to originate in order to further limit the ability of malware to | |||
generate bulk email. | generate bulk email. | |||
8.3. Key Server Denial-of-Service Attacks | 9.3. Key Server Denial-of-Service Attacks | |||
Since the key servers are distributed (potentially separate for each | Since the key servers are distributed (potentially separate for each | |||
domain), the number of servers that would need to be attacked to | domain), the number of servers that would need to be attacked to | |||
defeat this mechanism on an Internet-wide basis is very large. | defeat this mechanism on an Internet-wide basis is very large. | |||
Nevertheless, key servers for individual domains could be attacked, | Nevertheless, key servers for individual domains could be attacked, | |||
impeding the verification of messages from that domain. This is not | impeding the verification of messages from that domain. This is not | |||
significantly different from the ability of an attacker to deny | significantly different from the ability of an attacker to deny | |||
service to the mail exchangers for a given domain, although it | service to the mail exchangers for a given domain, although it | |||
affects outgoing, not incoming, mail. | affects outgoing, not incoming, mail. | |||
A variation on this attack is that if a very large amount of 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 | were to be sent using spoofed addresses from a given domain, the key | |||
servers for that domain could be overwhelmed with requests. However, | servers for that domain could be overwhelmed with requests. However, | |||
given the low overhead of verification compared with handling of the | given the low overhead of verification compared with handling of the | |||
email message itself, such an attack would be difficult to mount. | email message itself, such an attack would be difficult to mount. | |||
8.4. Attacks Against the DNS | 9.4. Attacks Against the DNS | |||
Since the DNS is a required binding for key services, specific | Since the DNS is a required binding for key services, specific | |||
attacks against the DNS must be considered. | attacks against the DNS must be considered. | |||
While the DNS is currently insecure [RFC3833], these security | While the DNS is currently insecure [RFC3833], these security | |||
problems are the motivation behind DNS Security (DNSSEC) [RFC4033], | problems are the motivation behind DNS Security (DNSSEC) [RFC4033], | |||
and all users of the DNS will reap the benefit of that work. | and all users of the DNS will reap the benefit of that work. | |||
DKIM is only intended as a "sufficient" method of proving | DKIM is only intended as a "sufficient" method of proving | |||
authenticity. It is not intended to provide strong cryptographic | authenticity. It is not intended to provide strong cryptographic | |||
skipping to change at page 60, line 27 | skipping to change at page 60, line 28 | |||
A specific DNS security issue that should be considered by DKIM | A specific DNS security issue that should be considered by DKIM | |||
verifiers is the name chaining attack described in Section 2.3 of | verifiers is the name chaining attack described in Section 2.3 of | |||
[RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header | [RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header | |||
field, could be prompted to retrieve a key record of an attacker's | field, could be prompted to retrieve a key record of an attacker's | |||
choosing. This threat can be minimized by ensuring that name | choosing. This threat can be minimized by ensuring that name | |||
servers, including recursive name servers, used by the verifier | servers, including recursive name servers, used by the verifier | |||
enforce strict checking of "glue" and other additional information in | enforce strict checking of "glue" and other additional information in | |||
DNS responses and are therefore not vulnerable to this attack. | DNS responses and are therefore not vulnerable to this attack. | |||
8.5. Replay Attacks | 9.5. Replay Attacks | |||
In this attack, a spammer sends a message to be spammed to an | In this attack, a spammer sends a message to be spammed to an | |||
accomplice, which results in the message being signed by the | accomplice, which results in the message being signed by the | |||
originating MTA. The accomplice resends the message, including the | originating MTA. The accomplice resends the message, including the | |||
original signature, to a large number of recipients, possibly by | original signature, to a large number of recipients, possibly by | |||
sending the message to many compromised machines that act as MTAs. | sending the message to many compromised machines that act as MTAs. | |||
The messages, not having been modified by the accomplice, have valid | The messages, not having been modified by the accomplice, have valid | |||
signatures. | signatures. | |||
Partial solutions to this problem involve the use of reputation | Partial solutions to this problem involve the use of reputation | |||
skipping to change at page 61, line 5 | skipping to change at page 61, line 5 | |||
spam. This requires a real-time detection mechanism in order to | spam. This requires a real-time detection mechanism in order to | |||
react quickly enough. However, such measures might be prone to | react quickly enough. However, such measures might be prone to | |||
abuse, if for example an attacker resent a large number of messages | 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. | received from a victim in order to make them appear to be a spammer. | |||
Large verifiers might be able to detect unusually large volumes of | Large verifiers might be able to detect unusually large volumes of | |||
mails with the same signature in a short time period. Smaller | mails with the same signature in a short time period. Smaller | |||
verifiers can get substantially the same volume of information via | verifiers can get substantially the same volume of information via | |||
existing collaborative systems. | existing collaborative systems. | |||
8.6. Limits on Revoking Keys | 9.6. Limits on Revoking Keys | |||
When a large domain detects undesirable behavior on the part of one | 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 | 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 | user's messages in order to disavow responsibility for messages that | |||
have not yet been verified or that are the subject of a replay | 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 | 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 | if the same key, for scalability reasons, is used to sign messages | |||
for many other users. Mechanisms for explicitly revoking keys on a | for many other users. Mechanisms for explicitly revoking keys on a | |||
per-address basis have been proposed but require further study as to | per-address basis have been proposed but require further study as to | |||
their utility and the DNS load they represent. | their utility and the DNS load they represent. | |||
8.7. Intentionally Malformed Key Records | 9.7. Intentionally Malformed Key Records | |||
It is possible for an attacker to publish key records in DNS that are | It is possible for an attacker to publish key records in DNS that are | |||
intentionally malformed, with the intent of causing a denial-of- | intentionally malformed, with the intent of causing a denial-of- | |||
service attack on a non-robust verifier implementation. The attacker | service attack on a non-robust verifier implementation. The attacker | |||
could then cause a verifier to read the malformed key record by | could then cause a verifier to read the malformed key record by | |||
sending a message to one of its users referencing the malformed | sending a message to one of its users referencing the malformed | |||
record in a (not necessarily valid) signature. Verifiers MUST | record in a (not necessarily valid) signature. Verifiers MUST | |||
thoroughly verify all key records retrieved from the DNS and be | thoroughly verify all key records retrieved from the DNS and be | |||
robust against intentionally as well as unintentionally malformed key | robust against intentionally as well as unintentionally malformed key | |||
records. | records. | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields | 9.8. Intentionally Malformed DKIM-Signature Header Fields | |||
Verifiers MUST be prepared to receive messages with malformed DKIM- | Verifiers MUST be prepared to receive messages with malformed DKIM- | |||
Signature header fields, and thoroughly verify the header field | Signature header fields, and thoroughly verify the header field | |||
before depending on any of its contents. | before depending on any of its contents. | |||
8.9. Information Leakage | 9.9. Information Leakage | |||
An attacker could determine when a particular signature was verified | An attacker could determine when a particular signature was verified | |||
by using a per-message selector and then monitoring their DNS traffic | 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 the key lookup. This would act as the equivalent of a "web bug" | |||
for verification time rather than when the message was read. | for verification time rather than when the message was read. | |||
8.10. Remote Timing Attacks | 9.10. Remote Timing Attacks | |||
In some cases it may be possible to extract private keys using a | In some cases it may be possible to extract private keys using a | |||
remote timing attack [BONEH03]. Implementations should consider | remote timing attack [BONEH03]. Implementations should consider | |||
obfuscating the timing to prevent such attacks. | obfuscating the timing to prevent such attacks. | |||
8.11. Reordered Header Fields | 9.11. Reordered Header Fields | |||
Existing standards allow intermediate MTAs to reorder header fields. | Existing standards allow intermediate MTAs to reorder header fields. | |||
If a signer signs two or more header fields of the same name, this | If a signer signs two or more header fields of the same name, this | |||
can cause spurious verification errors on otherwise legitimate | can cause spurious verification errors on otherwise legitimate | |||
messages. In particular, signers that sign any existing DKIM- | messages. In particular, signers that sign any existing DKIM- | |||
Signature fields run the risk of having messages incorrectly fail to | Signature fields run the risk of having messages incorrectly fail to | |||
verify. | verify. | |||
8.12. RSA Attacks | 9.12. RSA Attacks | |||
An attacker could create a large RSA signing key with a small | An attacker could create a large RSA signing key with a small | |||
exponent, thus requiring that the verification key have a large | exponent, thus requiring that the verification key have a large | |||
exponent. This will force verifiers to use considerable computing | exponent. This will force verifiers to use considerable computing | |||
resources to verify the signature. Verifiers might avoid this attack | resources to verify the signature. Verifiers might avoid this attack | |||
by refusing to verify signatures that reference selectors with public | by refusing to verify signatures that reference selectors with public | |||
keys having unreasonable exponents. | keys having unreasonable exponents. | |||
In general, an attacker might try to overwhelm a verifier by flooding | In general, an attacker might try to overwhelm a verifier by flooding | |||
it with messages requiring verification. This is similar to other | it with messages requiring verification. This is similar to other | |||
MTA denial-of-service attacks and should be dealt with in a similar | MTA denial-of-service attacks and should be dealt with in a similar | |||
fashion. | fashion. | |||
8.13. Inappropriate Signing by Parent Domains | 9.13. Inappropriate Signing by Parent Domains | |||
The trust relationship described in Section 3.9 could conceivably be | The trust relationship described in Section 4.9 could conceivably be | |||
used by a parent domain to sign messages with identities in a | used by a parent domain to sign messages with identities in a | |||
subdomain not administratively related to the parent. For example, | subdomain not administratively related to the parent. For example, | |||
the ".com" registry could create messages with signatures using an | the ".com" registry could create messages with signatures using an | |||
"i=" value in the example.com domain. There is no general solution | "i=" value in the example.com domain. There is no general solution | |||
to this problem, since the administrative cut could occur anywhere in | to this problem, since the administrative cut could occur anywhere in | |||
the domain name. For example, in the domain "example.podunk.ca.us" | the domain name. For example, in the domain "example.podunk.ca.us" | |||
there are three administrative cuts (podunk.ca.us, ca.us, and 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 | any of which could create messages with an identity in the full | |||
domain. | domain. | |||
INFORMATIVE NOTE: This is considered an acceptable risk for the | INFORMATIVE NOTE: This is considered an acceptable risk for the | |||
same reason that it is acceptable for domain delegation. For | same reason that it is acceptable for domain delegation. For | |||
example, in the example above any of the domains could potentially | example, in the example above any of the domains could potentially | |||
simply delegate "example.podunk.ca.us" to a server of their choice | simply delegate "example.podunk.ca.us" to a server of their choice | |||
and completely replace all DNS-served information. Note that a | and completely replace all DNS-served information. Note that a | |||
verifier MAY ignore signatures that come from an unlikely domain | verifier MAY ignore signatures that come from an unlikely domain | |||
such as ".com", as discussed in Section 6.1.1. | such as ".com", as discussed in Section 7.1.1. | |||
8.14. Attacks Involving Addition of Header Fields | 9.14. Attacks Involving Addition of Header Fields | |||
Many email implementations do not enforce [RFC5322] with strictness. | Many email implementations do not enforce [RFC5322] with strictness. | |||
As discussed in Section 5.3 DKIM processing is predicated on a valid | As discussed in Section 6.3 DKIM processing is predicated on a valid | |||
mail message as its input. However, DKIM implementers should be | mail message as its input. However, DKIM implementers should be | |||
aware of the potential effect of having loose enforcement by email | aware of the potential effect of having loose enforcement by email | |||
components interacting with DKIM modules. | components interacting with DKIM modules. | |||
For example, a message with multiple From: header fields violates | For example, a message with multiple From: header fields violates | |||
Section 3.6 of [RFC5322]. With the intent of providing a better user | Section 3.6 of [RFC5322]. With the intent of providing a better user | |||
experience, many agents tolerate these violations and deliver the | experience, many agents tolerate these violations and deliver the | |||
message anyway. An MUA then might elect to render to the user the | message anyway. An MUA then might elect to render to the user the | |||
value of the last, or "top", From: field. This may also be done | value of the last, or "top", From: field. This may also be done | |||
simply out of the expectation that there is only one, where a "find | simply out of the expectation that there is only one, where a "find | |||
skipping to change at page 63, line 34 | skipping to change at page 63, line 34 | |||
canonicalized for input to the hash function, the extra field | canonicalized for input to the hash function, the extra field | |||
references will prevent instances of the cited fields from being | references will prevent instances of the cited fields from being | |||
added after signing, as doing so would render the signature invalid. | added after signing, as doing so would render the signature invalid. | |||
The From: field is used above to illustrate this issue, but it is | The From: field is used above to illustrate this issue, but it is | |||
only one of several fields that Section 3.6 of [RFC5322] constrains | only one of several fields that Section 3.6 of [RFC5322] constrains | |||
in this way. In reality any agent that forgives malformations, or is | in this way. In reality any agent that forgives malformations, or is | |||
careless about identifying which parts of a message were | careless about identifying which parts of a message were | |||
authenticated, is open to exploitation. | authenticated, is open to exploitation. | |||
8.15. Malformed Inputs | 9.15. Malformed Inputs | |||
DKIM allows additional header fields to be added to a signed message | DKIM allows additional header fields to be added to a signed message | |||
without breaking the signature. This tolerance can be abused, for | without breaking the signature. This tolerance can be abused, for | |||
example in a replay attack. The attack is accomplished by creating | example in a replay attack. The attack is accomplished by creating | |||
additional instances of header fields to an already signed message, | additional instances of header fields to an already signed message, | |||
without breaking the signature. These then might be displayed to the | without breaking the signature. These then might be displayed to the | |||
end user or are used as filtering input. Salient fields could | end user or are used as filtering input. Salient fields could | |||
include From: and Subject:, | include From: and Subject:, | |||
The resulting message violates section 3.6 of [RFC5322]. The way | The resulting message violates section 3.6 of [RFC5322]. The way | |||
skipping to change at page 64, line 32 | skipping to change at page 64, line 32 | |||
receiver filtering of invalid messages can ensure that adding | receiver filtering of invalid messages can ensure that adding | |||
additional header fields will break the DKIM signature by including | additional header fields will break the DKIM signature by including | |||
two copies of the header fields about which they are concerned in the | two copies of the header fields about which they are concerned in the | |||
signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | |||
Sections 3.5 and 5.4 for further discussion of this mechanism. | Sections 3.5 and 5.4 for further discussion of this mechanism. | |||
Specific validity rules for all known header fields can be gleaned | Specific validity rules for all known header fields can be gleaned | |||
from the IANA "Permanent Header Field Registry" and the reference | from the IANA "Permanent Header Field Registry" and the reference | |||
documents it identifies. | documents it identifies. | |||
9. References | 10. References | |||
9.1. Normative References | 10.1. Normative References | |||
[FIPS-180-2-2002] | [FIPS-180-2-2002] | |||
U.S. Department of Commerce, "Secure Hash Standard", FIPS | U.S. Department of Commerce, "Secure Hash Standard", FIPS | |||
PUB 180-2, August 2002. | PUB 180-2, August 2002. | |||
[ITU-X660-1997] | [ITU-X660-1997] | |||
"Information Technology - ASN.1 encoding rules: | "Information Technology - ASN.1 encoding rules: | |||
Specification of Basic Encoding Rules (BER), Canonical | Specification of Basic Encoding Rules (BER), Canonical | |||
Encoding Rules (CER) and Distinguished Encoding Rules | Encoding Rules (CER) and Distinguished Encoding Rules | |||
(DER)", 1997. | (DER)", 1997. | |||
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", | [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", | |||
RFC 1034, November 1987. | RFC 1034, November 1987. | |||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, November 1996. | Bodies", RFC 2045, November 1996. | |||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | ||||
Part Three: Message Header Extensions for Non-ASCII Text", | ||||
RFC 2047, November 1996. | ||||
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Five: Conformance Criteria and | Extensions (MIME) Part Five: Conformance Criteria and | |||
Examples", RFC 2049, November 1996. | Examples", RFC 2049, November 1996. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |||
Standards (PKCS) #1: RSA Cryptography Specifications | Standards (PKCS) #1: RSA Cryptography Specifications | |||
Version 2.1", RFC 3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | ||||
"Internationalizing Domain Names in Applications (IDNA)", | ||||
RFC 3490, March 2003. | ||||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", RFC 4234, January 2008. | Specifications: ABNF", RFC 5234, January 2008. | |||
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | |||
October 2008. | October 2008. | |||
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, | |||
October 2008. | October 2008. | |||
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, | [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, | |||
July 2009. | July 2009. | |||
9.2. Informative References | [RFC5890] Klensin, J., "Internationalizing Domain Names in | |||
Applications (IDNA): Definitions and Document Framework", | ||||
RFC 5890, August 2010. | ||||
10.2. Informative References | ||||
[BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th | [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th | |||
USENIX Security Symposium, 2003. | USENIX Security Symposium, 2003. | |||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | |||
"Security Multiparts for MIME: Multipart/Signed and | "Security Multiparts for MIME: Multipart/Signed and | |||
Multipart/Encrypted", RFC 1847, October 1995. | Multipart/Encrypted", RFC 1847, October 1995. | |||
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | |||
Public Keys Used For Exchanging Symmetric Keys", BCP 86, | Public Keys Used For Exchanging Symmetric Keys", BCP 86, | |||
End of changes. 163 change blocks. | ||||
283 lines changed or deleted | 256 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |