draft-ietf-dkim-rfc4871bis-03.txt | draft-ietf-dkim-rfc4871bis-04.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 (if approved) T. Hansen, Ed. | |||
Intended status: Standards Track AT&T Laboratories | Intended status: Standards Track AT&T Laboratories | |||
Expires: August 20, 2011 M. Kucherawy, Ed. | Expires: September 29, 2011 M. Kucherawy, Ed. | |||
Cloudmark | Cloudmark | |||
February 16, 2011 | March 28, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-03 | draft-ietf-dkim-rfc4871bis-04 | |||
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 | |||
skipping to change at page 1, line 43 | skipping to change at page 1, line 43 | |||
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 August 20, 2011. | This Internet-Draft will expire on September 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 | 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 5 | 1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 | |||
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 6 | 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 | |||
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 | 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 | |||
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7 | 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 | |||
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8 | 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | |||
2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | |||
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.3. Signing and Verification Algorithms . . . . . . . . . . . 12 | 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 | |||
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | |||
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18 | 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | |||
3.6. Key Management and Representation . . . . . . . . . . . . 27 | 3.6. Key Management and Representation . . . . . . . . . . . . 28 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | |||
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 34 | 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | |||
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 34 | 3.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 35 | 3.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 | |||
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 35 | 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 | |||
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37 | 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38 | 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | ||||
5.1. Determine Whether the Email Should Be Signed and by | 5.1. Determine Whether the Email Should Be Signed and by | |||
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.2. Select a Private Key and Corresponding Selector | 5.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 38 | Information . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
5.3. Normalize the Message to Prevent Transport Conversions . . 40 | ||||
5.3. Normalize the Message to Prevent Transport Conversions . . 39 | 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 | |||
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 39 | 5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 | |||
5.5. Recommended Signature Content . . . . . . . . . . . . . . 41 | 5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 43 | 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 43 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44 | 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 | |||
6.1. Extract Signatures from the Message . . . . . . . . . . . 45 | 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 | |||
6.2. Communicate Verification Results . . . . . . . . . . . . . 50 | 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 | |||
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 | 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 | |||
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52 | 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 | |||
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 52 | 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 | |||
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53 | 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 | |||
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 53 | 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 | |||
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 54 | 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 | |||
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55 | 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 | |||
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55 | 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 | |||
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55 | 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 | |||
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 | 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 | |||
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56 | 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 | |||
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57 | 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 | |||
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 | 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 | |||
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58 | 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 | |||
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 | 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 | |||
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 59 | 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 | |||
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 59 | 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 | |||
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 | 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 | |||
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60 | 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 | |||
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60 | 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 | |||
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60 | 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 60 | 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 | |||
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 | 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 | |||
8.14. Attacks Involving Addition of Header Fields . . . . . . . 61 | 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 62 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 63 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 | |||
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 | |||
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 | |||
A.3. The Email Signature is Verified . . . . . . . . . . . . . 65 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 72 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | |||
1. Introduction | 1. 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]. This | associating a domain name [RFC1034] with the message [RFC5322], which | |||
can be an author's organization, an operational relay or one of their | they are authorized to use. This can be an author's organization, an | |||
agents. Assertion of responsibility is validated through a | operational relay or one of their agents. Assertion of | |||
cryptographic signature and querying the signer's domain directly to | responsibility is validated through a cryptographic signature and | |||
retrieve the appropriate public key. Message transit from author to | querying the signer's domain directly to retrieve the appropriate | |||
recipient is through relays that typically make no substantive change | public key. Message transit from author to recipient is through | |||
to the message content and thus preserve the DKIM signature. A | relays that typically make no substantive change to the message | |||
message can contain multiple signatures, from the same or different | content and thus preserve the DKIM signature. A message can contain | |||
organizations involved with the message. | multiple signatures, from the same or different organizations | |||
involved with the message. | ||||
The approach taken by DKIM differs from previous approaches to | The approach taken by DKIM differs from previous approaches to | |||
message signing (e.g., Secure/Multipurpose Internet Mail Extensions | message signing (e.g., Secure/Multipurpose Internet Mail Extensions | |||
(S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: | (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: | |||
o the message signature is written as a message header field so that | o the message signature is written as a message header field so that | |||
neither human recipients nor existing MUA (Mail User Agent) | neither human recipients nor existing MUA (Mail User Agent) | |||
software is confused by signature-related content appearing in the | software is confused by signature-related content appearing in the | |||
message body; | message body; | |||
skipping to change at page 6, line 40 | skipping to change at page 7, line 40 | |||
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 | 2.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 author, author's organization, an ISP along the handling | include the author, the author's organization, an ISP along the | |||
path, an independent trust assessment service, and a mailing list | handling path, an independent trust assessment service, and a mailing | |||
operator. | list operator. | |||
2.4. Identifier | 2.4. Identifier | |||
A label that refers to an identity. | A label that refers to an identity. | |||
2.5. Signing Domain Identifier (SDID) | 2.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 | |||
skipping to change at page 8, line 13 | skipping to change at page 9, line 13 | |||
the exclusion of obs-FWS. | the exclusion of obs-FWS. | |||
2.9. Common ABNF Tokens | 2.9. 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.10. Imported ABNF Tokens | 2.10. 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) | |||
skipping to change at page 33, line 26 | skipping to change at page 34, line 26 | |||
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 3.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, the ABNF of the algorithm for the signature is as | More formally, pseudo-code for the signature algorithm is: | |||
follows: | body-hash = hash-alg (canon-body, l-param) | |||
body-hash = bh-hash-alg (canon-body, l-param) | data-hash = hash-alg (h-headers, D-SIG, content-hash) | |||
data-hash = a-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 of a function to hash the Body. | body-hash: is the output from hashing the body, using hash-alg. | |||
bh-hash-alg: is the hashing algorithm specified in the "bh" | 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" | ||||
parameter, as defined in Section 3.4 and excluding the | ||||
DKIM-Signature field. | ||||
l-param: is the value of the l= length parameter. | l-param: is the length-of-body value of the "l" parameter. | |||
data-hash: is the output from hashing the header, the | data-hash: is the output from using the hash-alg algorithm, to | |||
DOSETA-Signature header, and the Content hash. | hash the header including the DKIM-Signature header, and the | |||
body hash. | ||||
a-hash-alg: is the hash algorithm specified by the "a=" tag, | ||||
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. | |||
D-SIG: is the canonicalized DOSETA-Signature field sans the | ||||
signature value itself. | ||||
canon-body: is the canonicalized Body as defined in Section 3.4 | D-SIG: is the canonicalized DKIM-Signature field without the | |||
(excluding the DKIM-Signature field). | signature value portion of the parameter, itself; that is, an | |||
empty parameter value. | ||||
signature: is the signature value produced by the signing | signature: is the signature value produced by the signing | |||
algorithm. | algorithm. | |||
sig-alg: is the signature algorithm specified by the "a=" tag, | sig-alg: is the signature algorithm specified by the "a" | |||
parameter. | ||||
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 value of the s= selector 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. Signing by Parent Domains | 3.8. Input Requirements | |||
DKIM's design is predicated on valid input. Therefore, signers and | ||||
verifiers SHOULD take reasonable steps to ensure that the messages | ||||
they are processing are valid according to [RFC5322], [RFC2045], and | ||||
any other relevant message format standards. See Section 8.15 for | ||||
additional discussion and references. | ||||
3.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.9. Relationship between SDID and AUID | 3.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 39, line 29 | skipping to change at page 40, line 38 | |||
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. | |||
Similarly, a message that is not compliant with RFC5322, RFC2045 and | Similarly, a message that is not compliant with RFC5322, RFC2045 and | |||
RFC2047, can be subject to attempts by intermediaries to correct or | RFC2047 can be subject to attempts by intermediaries to correct or | |||
interpret such content. See Section 8 of [RFC4409] for examples of | interpret such content. See Section 8 of [RFC4409] for examples of | |||
changes that are commonly made. Such "corrections" may break DKIM | changes that are commonly made. Such "corrections" may break DKIM | |||
signatures or have other undesirable effects. Therefore, a verifier | signatures or have other undesirable effects. Therefore, a verifier | |||
SHOULD NOT validate a message that is not compliant with those | SHOULD NOT validate a message that is not compliant with those | |||
specifications. | specifications. | |||
If the message is submitted to the signer with any local encoding | If the message is submitted to the signer with any local encoding | |||
that will be modified before transmission, that modification to | that will be modified before transmission, that modification to | |||
canonical [RFC5322] form MUST be done before signing. In particular, | canonical [RFC5322] form MUST be done before signing. In particular, | |||
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 | |||
skipping to change at page 48, line 5 | skipping to change at page 49, line 6 | |||
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 3.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 wildcard TXT records in the DNS will produce a | NOTE: The use of a wildcard TXT record that covers a queried DKIM | |||
response to a DKIM query that is unlikely to be valid DKIM key | domain name will produce a response to a DKIM query that is | |||
record. This problem applies to many other types of queries, and | unlikely to be valid DKIM key record. This problem is not | |||
client software that processes DNS responses needs to take this | specific to DKIM and applies to many other types of queries. | |||
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 3.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 | |||
skipping to change at page 61, line 7 | skipping to change at page 62, line 7 | |||
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 | 8.13. Inappropriate Signing by Parent Domains | |||
The trust relationship described in Section 3.8 could conceivably be | The trust relationship described in Section 3.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. | |||
skipping to change at page 62, line 11 | skipping to change at page 63, line 11 | |||
To resist this specific attack the signed header field list can | To resist this specific attack the signed header field list can | |||
include an additional reference for each field that was present at | include an additional reference for each field that was present at | |||
signing. For example, a proper message with one From: field could be | signing. For example, a proper message with one From: field could be | |||
signed using "h=From:From:..." Due to the way header fields are | signed using "h=From:From:..." Due to the way header fields are | |||
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 | ||||
DKIM allows additional header fields to be added to a signed message | ||||
without breaking the signature. This tolerance can be abused, for | ||||
example in a replay attack. The attack is accomplished by creating | ||||
additional instances of header fields to an already signed message, | ||||
without breaking the signature. These then might be displayed to the | ||||
end user or are used as filtering input. Salient fields could | ||||
include From: and Subject:, | ||||
The resulting message violates section 3.6 of [RFC5322]. The way | ||||
such input will be handled and displayed by an MUA is unpredictable, | ||||
but in some cases it might display the newly added header fields | ||||
rather than those that are part of the originally signed message | ||||
alongside some "valid DKIM signature" annotation. This might allow | ||||
an attacker to replay a previously sent, signed message with a | ||||
different Subject:, From: or To: field. | ||||
Because of this, DKIM implementers are strongly advised to reject or | ||||
treat as suspicious any message that has multiple copies of header | ||||
fields that are disallowed by section 3.6 of [MAIL], particularly | ||||
those that are typically displayed to end users (From:, To:, Cc:, | ||||
Subject:). A signing module could return an error rather than | ||||
generate a signature; a verifying module might return a syntax error | ||||
code or arrange not to return a positive result even if the signature | ||||
technically validates. | ||||
Senders concerned that their messages might be particularly | ||||
vulnerable to this sort of attack and who do not wish to rely on | ||||
receiver filtering of invalid messages can ensure that adding | ||||
additional header fields will break the DKIM signature by including | ||||
two copies of the header fields about which they are concerned in the | ||||
signature (e.g. "h= ... from:from:to:to:subject:subject ...). See | ||||
Sections 3.5 and 5.4 for further discussion of this mechanism. | ||||
Specific validity rules for all known header fields can be gleaned | ||||
from the IANA "Permanent Header Field Registry" and the reference | ||||
documents it identifies. | ||||
9. References | 9. References | |||
9.1. Normative References | 9.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: | |||
End of changes. 29 change blocks. | ||||
128 lines changed or deleted | 179 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/ |