draft-ietf-dkim-rfc4871bis-02.txt | draft-ietf-dkim-rfc4871bis-03.txt | |||
---|---|---|---|---|
DKIM 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: April 14, 2011 M. Kucherawy, Ed. | Expires: August 20, 2011 M. Kucherawy, Ed. | |||
Cloudmark | Cloudmark | |||
October 11, 2010 | February 16, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-02 | draft-ietf-dkim-rfc4871bis-03 | |||
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 April 14, 2011. | This Internet-Draft will expire on August 20, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 | 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 | |||
1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | |||
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 | 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 6 | |||
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 | 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 | |||
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 | 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7 | |||
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8 | 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8 | |||
2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | |||
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 | 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 | 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 | 3.3. Signing and Verification Algorithms . . . . . . . . . . . 12 | |||
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | |||
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18 | |||
3.6. Key Management and Representation . . . . . . . . . . . . 28 | 3.6. Key Management and Representation . . . . . . . . . . . . 27 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32 | |||
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 | 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 34 | |||
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35 | 3.9. Relationship between SDID and AUID . . . . . . . . . . . . 34 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 | 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 35 | |||
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 36 | 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 35 | |||
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 | 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 | 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.1. Determine Whether the Email Should Be Signed and by | 5.1. Determine Whether the Email Should Be Signed and by | |||
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.2. Select a Private Key and Corresponding Selector | 5.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 39 | Information . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.3. Normalize the Message to Prevent Transport Conversions . . 40 | ||||
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 40 | 5.3. Normalize the Message to Prevent Transport Conversions . . 39 | |||
5.5. Recommended Signature Content . . . . . . . . . . . . . . 42 | 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 39 | |||
5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 | 5.5. Recommended Signature Content . . . . . . . . . . . . . . 41 | |||
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 44 | 5.6. Compute the Message Hash and Signature . . . . . . . . . . 43 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 | 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 43 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
6.1. Extract Signatures from the Message . . . . . . . . . . . 45 | 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 . . . . . . . . . . . 53 | 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 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 62 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 64 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 63 | |||
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64 | |||
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65 | A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 | |||
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65 | A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64 | |||
A.3. The Email Signature is Verified . . . . . . . . . . . . . 66 | A.3. The Email Signature is Verified . . . . . . . . . . . . . 65 | |||
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66 | |||
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67 | |||
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69 | |||
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72 | Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71 | |||
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 73 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 72 | |||
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72 | |||
Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 74 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 | |||
F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 74 | ||||
F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 | ||||
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 that owns the signing domain to claim some | organization to claim some responsibility for a message by | |||
responsibility for a message by associating the domain with the | associating a domain name [RFC1034] with the message [RFC5322]. This | |||
message. This can be an author's organization, an operational relay | can be an author's organization, an operational relay or one of their | |||
or one of their agents. Assertion of responsibility is validated | agents. Assertion of responsibility is validated through a | |||
through a cryptographic signature and querying the signer's domain | cryptographic signature and querying the signer's domain directly to | |||
directly to retrieve the appropriate public key. Message transit | retrieve the appropriate public key. Message transit from author to | |||
from author to recipient is through relays that typically make no | recipient is through relays that typically make no substantive change | |||
substantive change to the message content and thus preserve the DKIM | to the message content and thus preserve the DKIM signature. A | |||
signature. A message can contain multiple signatures, from the same | message can contain multiple signatures, from the same or different | |||
or different organizations involved with the message. | 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 41 | skipping to change at page 5, line 41 | |||
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 | ||||
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 | ||||
re-use of the signature with different messages. Verifying the | ||||
signature asserts that the hashed content has not changed since it | ||||
was signed, and asserts nothing else about "protecting" the end-to- | ||||
end integrity of the message. | ||||
2. Terminology and Definitions | 2. 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) [RFC4234]. | 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 | 2.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 | |||
skipping to change at page 8, line 24 | skipping to change at page 7, line 34 | |||
(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 | 2.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 [RFC4234]). | (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 [RFC4234]). | 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 | |||
CRLF followed by at least one whitespace, to be joined. | CRLF followed by at least one whitespace, to be joined. | |||
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. 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 | ||||
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 9, line 29 | skipping to change at page 8, line 39 | |||
o "dot-atom-text" (in the Local-part of an email address) | o "dot-atom-text" (in the Local-part of an email address) | |||
The following tokens are imported from [RFC2045]: | The following tokens are imported from [RFC2045]: | |||
o "qp-section" (a single line of quoted-printable-encoded text) | o "qp-section" (a single line of quoted-printable-encoded text) | |||
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 [RFC4234] 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 [RFC4234]. 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.11. DKIM-Quoted-Printable | 2.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 | |||
skipping to change at page 13, line 37 | skipping to change at page 12, line 39 | |||
Whitespace within a value MUST be retained unless explicitly excluded | Whitespace within a value MUST be retained unless explicitly excluded | |||
by the specific tag description. | by the specific tag description. | |||
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. For | empty value explicitly designates the empty string as the value. | |||
example, "g=" does not mean "g=*", even though "g=*" is the default | ||||
for that tag. | ||||
3.3. Signing and Verification Algorithms | 3.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. | ||||
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some | INFORMATIVE NOTE: Although 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 sha1 because of reduced CPU requirements to compute | |||
a sha1 hash. In general, sha256 should always be used whenever | a sha1 hash. In general, sha256 should always be used whenever | |||
possible. | possible. | |||
3.3.1. The rsa-sha1 Signing Algorithm | 3.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 | |||
skipping to change at page 20, line 42 | skipping to change at page 19, line 42 | |||
ABNF: | ABNF: | |||
sig-v-tag = %x76 [FWS] "=" [FWS] "1" | sig-v-tag = %x76 [FWS] "=" [FWS] "1" | |||
INFORMATIVE NOTE: DKIM-Signature version numbers are expected | INFORMATIVE NOTE: DKIM-Signature version numbers are expected | |||
to increase arithmetically as new versions of this | to increase arithmetically as new versions of this | |||
specification are released. | specification are released. | |||
a= The algorithm used to generate the signature (plain-text; | a= The algorithm used to generate the signature (plain-text; | |||
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; | |||
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a | signers SHOULD sign using "rsa-sha256". | |||
description of algorithms. | ||||
ABNF: | ABNF: | |||
a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | ||||
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg | ||||
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h | |||
sig-a-tag-k = "rsa" / x-sig-a-tag-k | sig-a-tag-k = "rsa" / x-sig-a-tag-k | |||
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) ; for later extension | x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) | |||
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension | ; for later extension | |||
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) | ||||
; 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 5) 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 | |||
skipping to change at page 22, line 14 | skipping to change at page 21, line 15 | |||
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 | |||
d= Specifies the SDID claiming responsibility for an introduction of | d= The SDID claiming responsibility for an introduction of a message | |||
a message into the mail stream (plain-text; REQUIRED). Hence, the | into the mail stream (plain-text; REQUIRED). Hence, the SDID | |||
SDID value is used to form the query for the public key. The SDID | value is used to form the query for the public key. The SDID MUST | |||
MUST correspond to a valid DNS name under which the DKIM key | correspond to a valid DNS name under which the DKIM key record is | |||
record is published. The conventions and semantics used by a | published. The conventions and semantics used by a signer to | |||
signer to create and use a specific SDID are outside the scope of | create and use a specific SDID are outside the scope of the DKIM | |||
the DKIM Signing specification, as is any use of those conventions | Signing specification, as is any use of those conventions and | |||
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]. | [RFC3490]. | |||
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-literall | ; from RFC 5321 Domain, but 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 | |||
skipping to change at page 23, line 35 | skipping to change at page 22, line 35 | |||
header fields prevents an attacker from inserting an actual | header fields prevents an attacker from inserting an actual | |||
header field with a null value. | header field with a null value. | |||
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 using the steps | |||
listed in Section 4 of [RFC3490] using the "ToASCII" function. | listed in Section 4 of [RFC3490] using the "ToASCII" function. | |||
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 | |||
skipping to change at page 24, line 22 | skipping to change at page 23, line 22 | |||
assessors is outside the scope of the DKIM Signing specification. | assessors is outside the scope of the DKIM Signing specification. | |||
The Signer MAY choose to use the same namespace for its AUIDs as | The Signer MAY choose to use the same namespace for its AUIDs as | |||
its users' email addresses or MAY choose other means of | its users' email addresses or MAY choose other means of | |||
representing its users. However, the signer SHOULD use the same | representing its users. However, the signer SHOULD use the same | |||
AUID for each message intended to be evaluated as being within the | AUID for each message intended to be evaluated as being within the | |||
same sphere of responsibility, if it wishes to offer receivers the | same sphere of responsibility, if it wishes to offer receivers the | |||
option of using the AUID as a stable identifier that is finer | option of using the AUID as a stable identifier that is finer | |||
grained than the SDID. | grained than the SDID. | |||
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional | INFORMATIVE NOTE: The Local-part of the "i=" tag is optional | |||
because, in some cases, a signer may not be able to establish a | because in some cases a signer may not be able to establish a | |||
verified individual identity. In such cases, the signer might | verified individual identity. In such cases, the signer might | |||
wish to assert that although it is willing to go as far as | wish to assert that although it is willing to go as far as | |||
signing for the domain, it is unable or unwilling to commit to | signing for the domain, it is unable or unwilling to commit to | |||
an individual user name within their domain. It can do so by | an individual user name within their domain. It can do so by | |||
including the domain part but not the Local-part of the | including the domain part but not the Local-part of the | |||
identity. | identity. | |||
INFORMATIVE DISCUSSION: This specification does not require the | INFORMATIVE DISCUSSION: This specification does not require the | |||
value of the "i=" tag to match the identity in any message | value of the "i=" tag to match the identity in any message | |||
header fields. This is considered to be a verifier policy | header fields. This is considered to be a verifier policy | |||
skipping to change at page 29, line 34 | skipping to change at page 28, line 34 | |||
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 | |||
g= Granularity of the key (plain-text; OPTIONAL, default is "*"). | ||||
This value MUST match the Local-part of the "i=" tag of the DKIM- | ||||
Signature header field (or its default value of the empty string | ||||
if "i=" is not specified), with a single, optional "*" character | ||||
matching a sequence of zero or more arbitrary characters | ||||
("wildcarding"). An email with a signing address that does not | ||||
match the value of this tag constitutes a failed verification. | ||||
The intent of this tag is to constrain which signing address can | ||||
legitimately use this selector, for example, when delegating a key | ||||
to a third party that should only be used for special purposes. | ||||
Wildcarding allows matching for addresses such as "user+*", | ||||
"*-offer" or "foo*bar". An empty "g=" value never matches any | ||||
addresses. | ||||
ABNF: | ||||
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | ||||
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] | ||||
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. Signers and Verifiers MUST support | algorithms that might be used. Signers and Verifiers MUST support | |||
the "sha256" hash algorithm. Verifiers MUST also support the | the "sha256" hash algorithm. Verifiers MUST also support the | |||
"sha1" hash algorithm. Unrecognized hash algorithms MUST be | "sha1" hash algorithm. Unrecognized hash algorithms MUST be | |||
ignored. | ignored. | |||
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 ) | |||
skipping to change at page 32, line 34 | skipping to change at page 31, line 14 | |||
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.1.1. Compatibility Note for DomainKeys | ||||
If a v= value is not found at the beginning of the DKIM key record, | ||||
the key record MAY be interpreted as for DomainKeys [RFC4870]. The | ||||
definition given here is upwardly compatible with what is used for | ||||
DomainKeys, with the exception of the "g=" value. In a DomainKeys | ||||
key record, an empty "g=" value would be interpreted as being | ||||
equivalent to DKIM's "g=*". | ||||
3.6.2. DNS Binding | 3.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 | 3.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 | |||
skipping to change at page 35, line 9 | skipping to change at page 33, 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 algorithm for the signature is as follows: | More formally, the ABNF of the algorithm for the signature is as | |||
body-hash = hash-alg(canon_body) | follows: | |||
header-hash = hash-alg(canon_header || DKIM-SIG) | body-hash = bh-hash-alg (canon-body, l-param) | |||
signature = sig-alg(header-hash, key) | data-hash = a-hash-alg (h-headers, D-SIG, content-hash) | |||
signature = sig-alg (d-domain, selector, data-hash) | ||||
where "sig-alg" is the signature algorithm specified by the "a=" tag, | where: | |||
"hash-alg" is the hash algorithm specified by the "a=" tag, | ||||
"canon_header" and "canon_body" are the canonicalized message header | ||||
and body (respectively) as defined in Section 3.4 (excluding the | ||||
DKIM-Signature header field), and "DKIM-SIG" is the canonicalized | ||||
DKIM-Signature header field sans the signature value itself, but with | ||||
"body-hash" included as the "bh=" tag. | ||||
INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs | body-hash: is the output of a function to hash the Body. | |||
provide both hashing and application of the RSA private key using | ||||
a single "sign()" primitive. When using such an API, the last two | bh-hash-alg: is the hashing algorithm specified in the "bh" | |||
steps in the algorithm would probably be combined into a single | parameter. | |||
call that would perform both the "hash-alg" and the "sig-alg". | ||||
canon-body: is a canonicalized representation of the body. | ||||
l-param: is the value of the l= length parameter. | ||||
data-hash: is the output from hashing the header, the | ||||
DOSETA-Signature header, and the Content 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 | ||||
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 | ||||
(excluding the DKIM-Signature field). | ||||
signature: is the signature value produced by the signing | ||||
algorithm. | ||||
sig-alg: is the signature algorithm specified by the "a=" tag, | ||||
d-domain: is the domain name specified in the d= parameter. | ||||
selector: is the value of the s= selector parameter | ||||
NOTE: Many digital signature APIs provide both hashing and | ||||
application of the RSA private key using a single "sign()" | ||||
primitive. When using such an API, the last two steps in the | ||||
algorithm would probably be combined into a single call that would | ||||
perform both the "a-hash-alg" and the "sig-alg". | ||||
3.8. Signing by Parent Domains | 3.8. 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 | |||
skipping to change at page 36, line 7 | skipping to change at page 35, line 7 | |||
3.9. Relationship between SDID and AUID | 3.9. 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 hnamas 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 | |||
its role as a DKIM identifier, additional semantics cannot be assumed | its role as a DKIM identifier, additional semantics cannot be assumed | |||
by an Identity Assessor. | by an Identity Assessor. | |||
A receive-side DKIM verifier MUST communicate the Signing Domain | Upon successfully verifying the signature, a receive-side DKIM | |||
Identifier (d=) to a consuming Identity Assessor module and MAY | verifier MUST communicate the Signing Domain Identifier (d=) to a | |||
communicate the Agent or User Identifier (i=) if present. | consuming Identity Assessor module and MAY communicate the Agent or | |||
User Identifier (i=) if present. | ||||
To the extent that a receiver attempts to intuit any structured | To the extent that a receiver attempts to intuit any structured | |||
semantics for either of the identifiers, this is a heuristic function | semantics for either of the identifiers, this is a heuristic function | |||
that is outside the scope of DKIM's specification and semantics. | that is outside the scope of DKIM's specification and semantics. | |||
Hence, it is relegated to a higher-level service, such as a delivery | Hence, it is relegated to a higher-level service, such as a delivery | |||
handling filter that integrates a variety of inputs and performs | handling filter that integrates a variety of inputs and performs | |||
heuristic analysis of them. | heuristic analysis of them. | |||
INFORMATIVE DISCUSSION: This document does not require the value | INFORMATIVE DISCUSSION: This document does not require the value | |||
of the SDID or AUID to match an identifier in any other message | of the SDID or AUID to match an identifier in any other message | |||
skipping to change at page 40, line 28 | skipping to change at page 39, line 28 | |||
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. | |||
Similarly, a message that is not compliant with RFC5322, RFC2045 | Similarly, a message that is not compliant with RFC5322, RFC2045 and | |||
correct or interpret such content. See Section 8 of [RFC4409] for | RFC2047, can be subject to attempts by intermediaries to correct or | |||
examples of changes that are commonly made. Such "corrections" may | interpret such content. See Section 8 of [RFC4409] for examples of | |||
break DKIM signatures or have other undesirable effects. Therefore, | changes that are commonly made. Such "corrections" may break DKIM | |||
a verifier SHOULD NOT validate a message that is not conformant. | signatures or have other undesirable effects. Therefore, a verifier | |||
SHOULD NOT validate a message that is not compliant with those | ||||
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 | |||
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. | |||
skipping to change at page 48, line 44 | skipping to change at page 48, line 5 | |||
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 | ||||
response to a DKIM query that is unlikely to be valid DKIM key | ||||
record. This problem applies to many other types of queries, and | ||||
client software that processes DNS responses needs to take this | ||||
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 | |||
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 | |||
skipping to change at page 49, line 35 | skipping to change at page 48, line 50 | |||
remainder of this section means "try the next key record, if any; | remainder of this section means "try the next key record, if any; | |||
if none, return to try another signature in the usual way". | if none, return to try another signature in the usual way". | |||
5. If the result returned from the query does not adhere to the | 5. If the result returned from the query does not adhere to the | |||
format defined in this specification, the verifier MUST ignore | format defined in this specification, the verifier MUST ignore | |||
the key record and return PERMFAIL (key syntax error). Verifiers | the key record and return PERMFAIL (key syntax error). Verifiers | |||
are urged to validate the syntax of key records carefully to | are urged to validate the syntax of key records carefully to | |||
avoid attempted attacks. In particular, the verifier MUST ignore | avoid attempted attacks. In particular, the verifier MUST ignore | |||
keys with a version code ("v=" tag) that they do not implement. | keys with a version code ("v=" tag) that they do not implement. | |||
6. If the "g=" tag in the public key does not match the Local-part | 6. If the "h=" tag exists in the public key record and the hash | |||
of the "i=" tag in the message signature header field, the | ||||
verifier MUST ignore the key record and return PERMFAIL | ||||
(inapplicable key). If the Local-part of the "i=" tag on the | ||||
message signature is not present, the "g=" tag must be "*" (valid | ||||
for all addresses in the domain) or the entire g= tag must be | ||||
omitted (which defaults to "g=*"), otherwise the verifier MUST | ||||
ignore the key record and return PERMFAIL (inapplicable key). | ||||
Other than this test, verifiers SHOULD NOT treat a message signed | ||||
with a key record having a "g=" tag any differently than one | ||||
without; in particular, verifiers SHOULD NOT prefer messages that | ||||
seem to have an individual signature by virtue of a "g=" tag | ||||
versus a domain signature. | ||||
7. If the "h=" tag exists in the public key record and the hash | ||||
algorithm implied by the a= tag in the DKIM-Signature header | algorithm implied by the a= tag in the DKIM-Signature header | |||
field is not included in the contents of the "h=" tag, the | field is not included in the contents of the "h=" tag, the | |||
verifier MUST ignore the key record and return PERMFAIL | verifier MUST ignore the key record and return PERMFAIL | |||
(inappropriate hash algorithm). | (inappropriate hash algorithm). | |||
8. If the public key data (the "p=" tag) is empty, then this key has | 7. If the public key data (the "p=" tag) is empty, then this key has | |||
been revoked and the verifier MUST treat this as a failed | 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. | |||
9. 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 | 6.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 | |||
skipping to change at page 61, line 24 | skipping to change at page 60, line 24 | |||
8.9. Information Leakage | 8.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 | 8.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 | 8.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 | |||
skipping to change at page 62, line 51 | skipping to change at page 61, line 51 | |||
be exploited to fool the user if it is also known that the other | be exploited to fool the user if it is also known that the other | |||
From: field is the one checked by arriving message filters. Such is | From: field is the one checked by arriving message filters. Such is | |||
the case with DKIM; although the From: field must be signed, a | the case with DKIM; although the From: field must be signed, a | |||
malformed message bearing more than one From: field might only have | malformed message bearing more than one From: field might only have | |||
the first ("bottom") one signed, in an attempt to show the message | the first ("bottom") one signed, in an attempt to show the message | |||
with some "DKIM passed" annotation while also rendering the From: | with some "DKIM passed" annotation while also rendering the From: | |||
field that was not authenticated. (This can also be taken as a | field that was not authenticated. (This can also be taken as a | |||
demonstration that DKIM is not designed to support author | demonstration that DKIM is not designed to support author | |||
validation.) | validation.) | |||
A signer wishing to be resistant to this specific attack can include | To resist this specific attack the signed header field list can | |||
in the signed header field list an additional instance of each field | include an additional reference for each field that was present at | |||
that was present at signing. For example, a proper message with one | signing. For example, a proper message with one From: field could be | |||
From: field could be signed using "h=From:From:..." Because of the | signed using "h=From:From:..." Due to the way header fields are | |||
way header fields are canonicalized for input to the hash function, | canonicalized for input to the hash function, the extra field | |||
this would prevent additional fields from being added, after signing, | references will prevent instances of the cited fields from being | |||
as this 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 | ||||
only one of > several fields that Section 3.6 of [RFC5322] constrains | ||||
in this way. In reality any agent that forgives malformations, or is | ||||
careless about identifying which parts of a message were | ||||
authenticated, is open to exploitation. | ||||
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: | |||
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", | ||||
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) | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | |||
Part Three: Message Header Extensions for Non-ASCII Text", | Part Three: Message Header Extensions for Non-ASCII Text", | |||
RFC 2047, November 1996. | 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 | |||
skipping to change at page 63, line 47 | skipping to change at page 63, line 9 | |||
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, | [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, | |||
"Internationalizing Domain Names in Applications (IDNA)", | "Internationalizing Domain Names in Applications (IDNA)", | |||
RFC 3490, March 2003. | RFC 3490, March 2003. | |||
[RFC4234] 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, October 2005. | Specifications: ABNF", RFC 4234, 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. | |||
skipping to change at page 68, line 22 | skipping to change at page 67, line 22 | |||
administrative control. This creates challenges for choosing and | administrative control. This creates challenges for choosing and | |||
administering the domain name to use for signing, and for its | administering the domain name to use for signing, and for its | |||
relationship to common email identity header fields. | relationship to common email identity header fields. | |||
B.1.1. Delegated Business Functions | B.1.1. Delegated Business Functions | |||
Some organizations assign specific business functions to discrete | Some organizations assign specific business functions to discrete | |||
groups, inside or outside the organization. The goal, then, is to | groups, inside or outside the organization. The goal, then, is to | |||
authorize that group to sign some mail, but to constrain what | authorize that group to sign some mail, but to constrain what | |||
signatures they can generate. DKIM selectors (the "s=" signature | signatures they can generate. DKIM selectors (the "s=" signature | |||
tag) and granularity (the "g=" key tag) facilitate this kind of | tag) facilitate this kind of restricted authorization. Examples of | |||
restricted authorization. Examples of these outsourced business | these outsourced business functions are legitimate email marketing | |||
functions are legitimate email marketing providers and corporate | providers and corporate benefits providers. | |||
benefits providers. | ||||
Here, the delegated group needs to be able to send messages that are | Here, the delegated group needs to be able to send messages that are | |||
signed, using the email domain of the client company. At the same | signed, using the email domain of the client company. At the same | |||
time, the client often is reluctant to register a key for the | time, the client often is reluctant to register a key for the | |||
provider that grants the ability to send messages for arbitrary | provider that grants the ability to send messages for arbitrary | |||
addresses in the domain. | addresses in the domain. | |||
There are multiple ways to administer these usage scenarios. In one | There are multiple ways to administer these usage scenarios. In one | |||
case, the client organization provides all of the public query | case, the client organization provides all of the public query | |||
service (for example, DNS) administration, and in another it uses DNS | service (for example, DNS) administration, and in another it uses DNS | |||
delegation to enable all ongoing administration of the DKIM key | delegation to enable all ongoing administration of the DKIM key | |||
record by the delegated group. | record by the delegated group. | |||
If the client organization retains responsibility for all of the DNS | If the client organization retains responsibility for all of the DNS | |||
administration, the outsourcing company can generate a key pair, | administration, the outsourcing company can generate a key pair, | |||
supplying the public key to the client company, which then registers | supplying the public key to the client company, which then registers | |||
it in the query service, using a unique selector that authorizes a | it in the query service, using a unique selector. The client company | |||
specific From header field Local-part. For example, a client with | retains control over the use of the delegated key because it retains | |||
the domain "example.com" could have the selector record specify | the ability to revoke the key at any time. | |||
"g=winter-promotions" so that this signature is only valid for mail | ||||
with a From address of "winter-promotions@example.com". This would | ||||
enable the provider to send messages using that specific address and | ||||
have them verify properly. The client company retains control over | ||||
the email address because it retains the ability to revoke the key at | ||||
any time. | ||||
If the client wants the delegated group to do the DNS administration, | If the client wants the delegated group to do the DNS administration, | |||
it can have the domain name that is specified with the selector point | it can have the domain name that is specified with the selector point | |||
to the provider's DNS server. The provider then creates and | to the provider's DNS server. The provider then creates and | |||
maintains all of the DKIM signature information for that selector. | maintains all of the DKIM signature information for that selector. | |||
Hence, the client cannot provide constraints on the Local-part of | Hence, the client cannot provide constraints on the Local-part of | |||
addresses that get signed, but it can revoke the provider's signing | addresses that get signed, but it can revoke the provider's signing | |||
rights by removing the DNS delegation record. | rights by removing the DNS delegation record. | |||
B.1.2. PDAs and Similar Devices | B.1.2. PDAs and Similar Devices | |||
skipping to change at page 71, line 15 | skipping to change at page 70, line 8 | |||
This is another application that takes advantage of user-level | This is another application that takes advantage of user-level | |||
keying, and domains used for affinity addresses would typically have | keying, and domains used for affinity addresses would typically have | |||
a very large number of user-level keys. Alternatively, the affinity | a very large number of user-level keys. Alternatively, the affinity | |||
domain could handle outgoing mail, operating a mail submission agent | domain could handle outgoing mail, operating a mail submission agent | |||
that authenticates users before accepting and signing messages for | that authenticates users before accepting and signing messages for | |||
them. This is of course dependent on the user's service provider not | them. This is of course dependent on the user's service provider not | |||
blocking the relevant TCP ports used for mail submission. | blocking the relevant TCP ports used for mail submission. | |||
B.2.2. Simple Address Aliasing (.forward) | B.2.2. Simple Address Aliasing (.forward) | |||
In some cases, a recipient is allowed to configure an email address | In some cases a recipient is allowed to configure an email address to | |||
to cause automatic redirection of email messages from the original | cause automatic redirection of email messages from the original | |||
address to another, such as through the use of a Unix .forward file. | address to another, such as through the use of a Unix .forward file. | |||
In this case, messages are typically redirected by the mail handling | In this case, messages are typically redirected by the mail handling | |||
service of the recipient's domain, without modification, except for | service of the recipient's domain, without modification, except for | |||
the addition of a Received header field to the message and a change | the addition of a Received header field to the message and a change | |||
in the envelope recipient address. In this case, the recipient at | in the envelope recipient address. In this case, the recipient at | |||
the final address' mailbox is likely to be able to verify the | the final address' mailbox is likely to be able to verify the | |||
original signature since the signed content has not changed, and DKIM | original signature since the signed content has not changed, and DKIM | |||
is able to validate the message signature. | is able to validate the message signature. | |||
B.2.3. Mailing Lists and Re-Posters | B.2.3. Mailing Lists and Re-Posters | |||
skipping to change at page 73, line 4 | skipping to change at page 71, line 39 | |||
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj | eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj | |||
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA | 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA | |||
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf | qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf | |||
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX | eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX | |||
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= | GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= | |||
-----END RSA PRIVATE KEY----- | -----END RSA PRIVATE KEY----- | |||
To extract the public-key component from the private key, use openssl | To extract the public-key component from the private key, use openssl | |||
like this: | like this: | |||
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM | $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM | |||
This results in the file rsa.public containing the key information | This results in the file rsa.public containing the key information | |||
similar to this: | similar to this: | |||
[-----BEGIN PUBLIC KEY----- | -----BEGIN PUBLIC KEY----- | |||
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM | MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM | |||
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R | oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R | |||
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI | tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI | |||
MmPSPDdQPNUYckcQ2QIDAQAB | MmPSPDdQPNUYckcQ2QIDAQAB | |||
-----END PUBLIC KEY----- | -----END PUBLIC KEY----- | |||
This public-key data (without the BEGIN and END tags) is placed in | This public-key data (without the BEGIN and END tags) is placed in | |||
the DNS: | the DNS: | |||
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | |||
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | |||
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | |||
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | |||
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | |||
Appendix D. MUA Considerations | Appendix D. MUA Considerations | |||
When a DKIM signature is verified, the processing system sometimes | When a DKIM signature is verified, the processing system sometimes | |||
makes the result available to the recipient user's MUA. How to | makes the result available to the recipient user's MUA. How to | |||
skipping to change at page 74, line 31 | skipping to change at page 73, line 19 | |||
Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, | Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, | |||
Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, | Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, | |||
Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, | Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, | |||
Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector | Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector | |||
Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert | Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert | |||
Sanders, Rand Wacker, Sam Weiler, and Dan Wing. | Sanders, Rand Wacker, Sam Weiler, and Dan Wing. | |||
The earlier DomainKeys was a primary source from which DKIM was | The earlier DomainKeys was a primary source from which DKIM was | |||
derived. Further information about DomainKeys is at [RFC4870]. | derived. Further information about DomainKeys is at [RFC4870]. | |||
Appendix F. RFC4871bis Changes | ||||
F.1. TO DO | ||||
o Revise summary Introduction to reflect "authentic labeling" rather | ||||
than "message authentication". | ||||
o Review interoperability items to consider dropping unused | ||||
features. | ||||
o Review retention of other parameters, such as l= | ||||
o "signatures inside parts shouldn't be processed"? | ||||
F.2. DONE | ||||
o Incorporate Updates RFC | ||||
o Added RFC 5598 reference | ||||
o Errata ID: 1376 - Verified - sha value for empty bodies | ||||
o Errata ID: 1377 - Verified - no trailing CR-LF | ||||
o Errata ID: 1378 - Verified - no default algorithm | ||||
o Errata ID: 1379 - Verified - z= ABNF | ||||
o Errata ID: 1384 - Verified - clarify relaxed step order | ||||
o Errata ID: 1461 - Verified - h= ABNF | ||||
o Errata ID: 1487 - Verified - v= ABNF | ||||
o Errata ID: 1380 - Held for Document Update - x= fudge factor | ||||
o Errata ID: 1381 - Held for Document Update - unknown q= value, | ||||
h=/k=/s=/t= value | ||||
o Errata ID: 1382 - Held for Document Update - unknown s= values | ||||
(dup of 1381) | ||||
o Errata ID: 1383 - Held for Document Update - add g= example | ||||
o Errata ID: 1386 - Held for Document Update - fix DKIM-Signature | ||||
example | ||||
o Errata ID: 1532 - Held for Document Update - "v=DKIM1" | ||||
o Errata ID: 1596 - Held for Document Update - *value* of the b= tag | ||||
o Add Authentication Results RFC 5451 to 6.2 | ||||
Authors' Addresses | Authors' Addresses | |||
D. Crocker (editor) | D. Crocker (editor) | |||
Brandenburg InternetWorking | Brandenburg InternetWorking | |||
675 Spruce Dr. | 675 Spruce Dr. | |||
Sunnyvale | Sunnyvale | |||
USA | USA | |||
Phone: +1.408.246.8253 | Phone: +1.408.246.8253 | |||
Email: dcrocker@bbiw.net | Email: dcrocker@bbiw.net | |||
skipping to change at page 76, line 14 | skipping to change at page 73, line 41 | |||
Tony Hansen (editor) | Tony Hansen (editor) | |||
AT&T Laboratories | AT&T Laboratories | |||
200 Laurel Ave. South | 200 Laurel Ave. South | |||
Middletown, NJ 07748 | Middletown, NJ 07748 | |||
USA | USA | |||
Email: tony+dkimov@maillennium.att.com | Email: tony+dkimov@maillennium.att.com | |||
M. Kucherawy (editor) | M. Kucherawy (editor) | |||
Cloudmark | Cloudmark | |||
128 King St., 2nd Floor | ||||
San Francisco, CA 94107 | ||||
USA | ||||
Email: msk@cloudmark.com | Email: msk@cloudmark.com | |||
End of changes. 60 change blocks. | ||||
272 lines changed or deleted | 229 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |