draft-ietf-dkim-base-08.txt | draft-ietf-dkim-base-09.txt | |||
---|---|---|---|---|
DKIM E. Allman | DKIM E. Allman | |||
Internet-Draft Sendmail, Inc. | Internet-Draft Sendmail, Inc. | |||
Expires: July 22, 2007 J. Callas | Intended status: Standards Track J. Callas | |||
PGP Corporation | Expires: August 15, 2007 PGP Corporation | |||
M. Delany | M. Delany | |||
M. Libbey | M. Libbey | |||
Yahoo! Inc | Yahoo! Inc | |||
J. Fenton | J. Fenton | |||
M. Thomas | M. Thomas | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
January 18, 2007 | February 11, 2007 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-base-08 | draft-ietf-dkim-base-09 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 41 | skipping to change at page 1, line 41 | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on July 22, 2007. | This Internet-Draft will expire on August 15, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2007). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) defines a domain-level | DomainKeys Identified Mail (DKIM) defines a domain-level | |||
authentication framework for email using public-key cryptography and | authentication framework for email using public-key cryptography and | |||
key server technology to permit verification of the source and | key server technology to permit verification of the source and | |||
contents of messages by either Mail Transfer Agents (MTAs) or Mail | contents of messages by either Mail Transfer Agents (MTAs) or Mail | |||
User Agents (MUAs). The ultimate goal of this framework is to permit | User Agents (MUAs). The ultimate goal of this framework is to permit | |||
a signing domain to assert responsibility for a message, thus | a signing domain to assert responsibility for a message, thus | |||
protecting message signer identity and the integrity of the messages | protecting message signer identity and the integrity of the messages | |||
skipping to change at page 3, line 7 | skipping to change at page 2, line 22 | |||
global control of "spam" and "phishing". | global control of "spam" and "phishing". | |||
Requirements Language | Requirements Language | |||
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]. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6 | 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 | |||
2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3. White Space . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | 2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | 2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 | |||
2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | 2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 | 3.3. Signing and Verification Algorithms . . . . . . . . . . . 12 | |||
3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 | |||
3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 | 3.5. The DKIM-Signature header field . . . . . . . . . . . . . 18 | |||
3.6 Key Management and Representation . . . . . . . . . . . . 26 | 3.6. Key Management and Representation . . . . . . . . . . . . 26 | |||
3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 30 | |||
3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 32 | 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 32 | |||
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 33 | 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 33 | |||
4.1 Example Scenarios . . . . . . . . . . . . . . . . . . . . 33 | 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 33 | |||
4.2 Interpretation . . . . . . . . . . . . . . . . . . . . . . 34 | 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 34 | |||
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 35 | 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
5.1 Determine if the Email Should be Signed and by Whom . . . 35 | 5.1. Determine if the Email Should be Signed and by Whom . . . 35 | |||
5.2 Select a Private Key and Corresponding Selector | 5.2. Select a Private Key and Corresponding Selector | |||
Information . . . . . . . . . . . . . . . . . . . . . . . 36 | Information . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
5.3 Normalize the Message to Prevent Transport Conversions . . 36 | 5.3. Normalize the Message to Prevent Transport Conversions . . 36 | |||
5.4 Determine the Header Fields to Sign . . . . . . . . . . . 37 | 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36 | |||
5.5 Compute the Message Hash and Signature . . . . . . . . . . 40 | 5.5. Recommended Signature Content . . . . . . . . . . . . . . 39 | |||
5.6 Insert the DKIM-Signature Header Field . . . . . . . . . . 40 | 5.6. Compute the Message Hash and Signature . . . . . . . . . . 40 | |||
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 41 | 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 41 | |||
6.1 Extract Signatures from the Message . . . . . . . . . . . 41 | 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
6.2 Communicate Verification Results . . . . . . . . . . . . . 47 | 6.1. Extract Signatures from the Message . . . . . . . . . . . 42 | |||
6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 47 | 6.2. Communicate Verification Results . . . . . . . . . . . . . 47 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 | 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 48 | |||
7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 49 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 | |||
7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 49 | 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 49 | |||
7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 50 | 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 50 | |||
7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 50 | 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 50 | |||
7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 51 | 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 51 | |||
7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51 | 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 51 | |||
7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 52 | 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 52 | |||
7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52 | 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 52 | |||
7.9 DKIM-Signature Header Field . . . . . . . . . . . . . . . 53 | 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 53 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . 53 | 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 53 | |||
8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 53 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 53 | |||
8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 54 | 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 53 | |||
8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 54 | 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 54 | |||
8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 55 | 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 55 | |||
8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55 | 8.4. Attacks Against DNS . . . . . . . . . . . . . . . . . . . 55 | |||
8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 56 | 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 56 | |||
8.7 Intentionally malformed Key Records . . . . . . . . . . . 56 | 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 56 | |||
8.8 Intentionally Malformed DKIM-Signature header fields . . . 56 | 8.7. Intentionally malformed Key Records . . . . . . . . . . . 57 | |||
8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 57 | 8.8. Intentionally Malformed DKIM-Signature header fields . . . 57 | |||
8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 57 | 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 57 | |||
8.11 Reordered Header Fields . . . . . . . . . . . . . . . . 57 | 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 57 | |||
8.12 RSA Attacks . . . . . . . . . . . . . . . . . . . . . . 57 | 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 57 | |||
8.13 Inappropriate Signing by Parent Domains . . . . . . . . 57 | 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 57 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 | 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 58 | |||
9.1 Normative References . . . . . . . . . . . . . . . . . . . 58 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | |||
9.2 Informative References . . . . . . . . . . . . . . . . . . 59 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 58 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 59 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 59 | |||
A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 61 | Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 | |||
A.1 The user composes an email . . . . . . . . . . . . . . . . 61 | A.1. The user composes an email . . . . . . . . . . . . . . . . 60 | |||
A.2 The email is signed . . . . . . . . . . . . . . . . . . . 61 | A.2. The email is signed . . . . . . . . . . . . . . . . . . . 60 | |||
A.3 The email signature is verified . . . . . . . . . . . . . 62 | A.3. The email signature is verified . . . . . . . . . . . . . 61 | |||
B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 63 | Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 | |||
B.1 Alternate Submission Scenarios . . . . . . . . . . . . . . 64 | B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 | |||
B.2 Alternate Delivery Scenarios . . . . . . . . . . . . . . . 66 | B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 | |||
C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 68 | Appendix C. Creating a public key (INFORMATIVE) . . . . . . . . . 67 | |||
D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 70 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 69 | |||
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 | |||
F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 71 | Appendix F. Edit History . . . . . . . . . . . . . . . . . . . . 70 | |||
F.1 Changes since -ietf-07 version . . . . . . . . . . . . . . 71 | F.1. Changes since -ietf-08 version . . . . . . . . . . . . . . 70 | |||
F.2 Changes since -ietf-06 version . . . . . . . . . . . . . . 72 | F.2. Changes since -ietf-07 version . . . . . . . . . . . . . . 70 | |||
F.3 Changes since -ietf-05 version . . . . . . . . . . . . . . 73 | F.3. Changes since -ietf-06 version . . . . . . . . . . . . . . 72 | |||
F.4 Changes since -ietf-04 version . . . . . . . . . . . . . . 73 | F.4. Changes since -ietf-05 version . . . . . . . . . . . . . . 72 | |||
F.5 Changes since -ietf-03 version . . . . . . . . . . . . . . 74 | F.5. Changes since -ietf-04 version . . . . . . . . . . . . . . 73 | |||
F.6 Changes since -ietf-02 version . . . . . . . . . . . . . . 75 | F.6. Changes since -ietf-03 version . . . . . . . . . . . . . . 73 | |||
F.7 Changes since -ietf-01 version . . . . . . . . . . . . . . 76 | F.7. Changes since -ietf-02 version . . . . . . . . . . . . . . 74 | |||
F.8 Changes since -ietf-00 version . . . . . . . . . . . . . . 76 | F.8. Changes since -ietf-01 version . . . . . . . . . . . . . . 75 | |||
F.9 Changes since -allman-01 version . . . . . . . . . . . . . 77 | F.9. Changes since -ietf-00 version . . . . . . . . . . . . . . 76 | |||
F.10 Changes since -allman-00 version . . . . . . . . . . . . 77 | F.10. Changes since -allman-01 version . . . . . . . . . . . . . 77 | |||
Intellectual Property and Copyright Statements . . . . . . . 79 | F.11. Changes since -allman-00 version . . . . . . . . . . . . . 77 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 80 | ||||
1. Introduction | 1. Introduction | |||
[[Note: text in double square brackets (such as this text) will be | [[Note: text in double square brackets (such as this text) will be | |||
deleted before publication.]] | deleted before publication.]] | |||
DomainKeys Identified Mail (DKIM) defines a mechanism by which email | DomainKeys Identified Mail (DKIM) defines a mechanism by which email | |||
messages can be cryptographically signed, permitting a signing domain | messages can be cryptographically signed, permitting a signing domain | |||
to claim responsibility for the introduction of a message into the | to claim responsibility for the introduction of a message into the | |||
mail stream. Message recipients can verify the signature by querying | mail stream. Message recipients can verify the signature by querying | |||
skipping to change at page 6, line 5 | skipping to change at page 6, line 5 | |||
o requires minimal new infrastructure; | o requires minimal new infrastructure; | |||
o can be implemented independently of clients in order to reduce | o can be implemented independently of clients in order to reduce | |||
deployment time; | deployment time; | |||
o can be deployed incrementally; | o can be deployed incrementally; | |||
o allows delegation of signing to third parties. | o allows delegation of signing to third parties. | |||
1.1 Signing Identity | 1.1. Signing Identity | |||
DKIM separates the question of the identity of the signer of the | DKIM separates the question of the identity of the signer of the | |||
message from the purported author of the message. In particular, a | message from the purported author of the message. In particular, a | |||
signature includes the identity of the signer. Verifiers can use the | signature includes the identity of the signer. Verifiers can use the | |||
signing information to decide how they want to process the message. | signing information to decide how they want to process the message. | |||
The signing identity is included as part of the signature header | The signing identity is included as part of the signature header | |||
field. | field. | |||
INFORMATIVE RATIONALE: The signing identity specified by a DKIM | INFORMATIVE RATIONALE: The signing identity specified by a DKIM | |||
signature is not required to match an address in any particular | signature is not required to match an address in any particular | |||
header field because of the broad methods of interpretation by | header field because of the broad methods of interpretation by | |||
recipient mail systems, including MUAs. | recipient mail systems, including MUAs. | |||
1.2 Scalability | 1.2. Scalability | |||
DKIM is designed to support the extreme scalability requirements | DKIM is designed to support the extreme scalability requirements | |||
which characterize the email identification problem. There are | which characterize the email identification problem. There are | |||
currently over 70 million domains and a much larger number of | currently over 70 million domains and a much larger number of | |||
individual addresses. DKIM seeks to preserve the positive aspects of | individual addresses. DKIM seeks to preserve the positive aspects of | |||
the current email infrastructure, such as the ability for anyone to | the current email infrastructure, such as the ability for anyone to | |||
communicate with anyone else without introduction. | communicate with anyone else without introduction. | |||
1.3 Simple Key Management | 1.3. Simple Key Management | |||
DKIM differs from traditional hierarchical public-key systems in that | DKIM differs from traditional hierarchical public-key systems in that | |||
no Certificate Authority infrastructure is required; the verifier | no Certificate Authority infrastructure is required; the verifier | |||
requests the public key from a repository in the domain of the | requests the public key from a repository in the domain of the | |||
claimed signer directly rather than from a third party. | claimed signer directly rather than from a third party. | |||
The DNS is proposed as the initial mechanism for the public keys. | The DNS is proposed as the initial mechanism for the public keys. | |||
Thus, DKIM currently depends on DNS administration and the security | Thus, DKIM currently depends on DNS administration and the security | |||
of the DNS system. DKIM is designed to be extensible to other key | of the DNS system. DKIM is designed to be extensible to other key | |||
fetching services as they become available. | fetching services as they become available. | |||
2. Terminology and Definitions | 2. Terminology and Definitions | |||
This section defines terms used in the rest of the document. Syntax | This section defines terms used in the rest of the document. Syntax | |||
descriptions use the form described in Augmented BNF for Syntax | descriptions use the form described in Augmented BNF for Syntax | |||
Specifications [RFC4234]. | Specifications [RFC4234]. | |||
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 | |||
agents such as mailing list exploders. In general any signer will be | agents such as mailing list exploders. In general any signer will be | |||
involved in the injection of a message into the message system in | involved in the injection of a message into the message system in | |||
some way. The key issue is that a message must be signed before it | some way. The key issue is that a message must be signed before it | |||
leaves the administrative domain of the signer. | leaves the administrative domain of the signer. | |||
2.2 Verifiers | 2.2. Verifiers | |||
Elements in the mail system that verify signatures are referred to as | Elements in the mail system that verify signatures are referred to as | |||
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. | verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. | |||
In most cases it is expected that verifiers will be close to an end | In most cases it is expected that verifiers will be close to an end | |||
user (reader) of the message or some consuming agent such as a | user (reader) of the message or some consuming agent such as a | |||
mailing list exploder. | mailing list exploder. | |||
2.3 White Space | 2.3. White Space | |||
There are three forms of white space: | There are three forms of white space: | |||
o WSP represents simple white space, i.e., a space or a tab | o WSP represents simple white space, i.e., a space or a tab | |||
character (formal definition in [RFC4234]). | character (formal definition in [RFC4234]). | |||
o LWSP is linear white space, defined as WSP plus CRLF (formal | o LWSP is linear white space, defined as WSP plus CRLF (formal | |||
definition in [RFC4234]). | definition in [RFC4234]). | |||
o FWS is folding white space. It allows multiple lines separated by | o FWS is folding white space. It allows multiple lines separated by | |||
skipping to change at page 7, line 39 | skipping to change at page 7, line 39 | |||
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 [RFC2822] except for | The definition of FWS is identical to that in [RFC2822] except for | |||
the exclusion of obs-FWS. | the exclusion of obs-FWS. | |||
2.4 Common ABNF Tokens | 2.4. 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) ] | |||
base64string = 1*(ALPHA / DIGIT / "+" / "/" / LWSP) | base64string = 1*(ALPHA / DIGIT / "+" / "/" / LWSP) | |||
[ "=" LWSP [ "=" LWSP ] ] | [ "=" LWSP [ "=" LWSP ] ] | |||
2.5 Imported ABNF Tokens | 2.5. 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 [RFC2821]: | The following tokens are imported from [RFC2821]: | |||
o "Local-part" (implementation warning: this permits quoted | o "Local-part" (implementation warning: this permits quoted | |||
strings) | strings) | |||
o "sub-domain" | o "sub-domain" | |||
skipping to change at page 8, line 37 | skipping to change at page 8, line 37 | |||
o "hex-octet" (a quoted-printable encoded octet) | o "hex-octet" (a quoted-printable encoded octet) | |||
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not | INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not | |||
obey the rules of RFC 4234 and must be interpreted accordingly, | obey the rules of RFC 4234 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 [RFC4234]. 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.6 DKIM-Quoted-Printable | 2.6. 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 lower case characters permitted) representing | "0123456789ABCDEF" (no lower case characters permitted) representing | |||
the hexadecimal-encoded integer value of that character. All control | the hexadecimal-encoded integer value of that character. All control | |||
characters (those with values < %x20), eight-bit characters (values > | characters (those with values < %x20), eight-bit characters (values > | |||
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon | %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon | |||
(";", %x3B) MUST be encoded. Note that all white space, including | (";", %x3B) MUST be encoded. Note that all white space, including | |||
SPACE, CR and LF characters, MUST be encoded. After encoding, FWS | SPACE, CR and LF characters, MUST be encoded. After encoding, FWS | |||
skipping to change at page 9, line 44 | skipping to change at page 9, line 44 | |||
text is being used). | text is being used). | |||
3. Protocol Elements | 3. Protocol Elements | |||
Protocol Elements are conceptual parts of the protocol that are not | Protocol Elements are conceptual parts of the protocol that are not | |||
specific to either signers or verifiers. The protocol descriptions | specific to either signers or verifiers. The protocol descriptions | |||
for signers and verifiers are described in later sections (Signer | for signers and verifiers are described in later sections (Signer | |||
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This | Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This | |||
section must be read in the context of those sections. | section must be read in the context of those sections. | |||
3.1 Selectors | 3.1. Selectors | |||
To support multiple concurrent public keys per signing domain, the | To support multiple concurrent public keys per signing domain, the | |||
key namespace is subdivided using "Selectors". For example, | key namespace is subdivided using "Selectors". For example, | |||
Selectors might indicate the names of office locations (e.g., | Selectors might indicate the names of office locations (e.g., | |||
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date | "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date | |||
(e.g., "january2005", "february2005", etc.), or even the individual | (e.g., "january2005", "february2005", etc.), or even the individual | |||
user. | user. | |||
Selectors are needed to support some important use cases. For | Selectors are needed to support some important use cases. For | |||
example: | example: | |||
skipping to change at page 11, line 24 | skipping to change at page 11, line 24 | |||
fingerprint of the public key. | fingerprint of the public key. | |||
INFORMATIVE OPERATIONS NOTE: Reusing a Selector with a new key | INFORMATIVE OPERATIONS NOTE: Reusing a Selector with a new key | |||
(for example, changing the key associated with a user's name) | (for example, changing the key associated with a user's name) | |||
makes it impossible to tell the difference between a message that | makes it impossible to tell the difference between a message that | |||
didn't verify because the key is no longer valid versus a message | didn't verify because the key is no longer valid versus a message | |||
that is actually forged. For this reason, signers are ill-advised | that is actually forged. For this reason, signers are ill-advised | |||
to reuse selectors for new keys. A better strategy is to assign | to reuse selectors for new keys. A better strategy is to assign | |||
new keys to new selectors. | new keys to new selectors. | |||
3.2 Tag=Value Lists | 3.2. Tag=Value Lists | |||
DKIM uses a simple "tag=value" syntax in several contexts, including | DKIM uses a simple "tag=value" syntax in several contexts, including | |||
in messages and domain signature records. | in messages and domain signature records. | |||
Values are a series of strings containing either plain text, "base64" | Values are a series of strings containing either plain text, "base64" | |||
text (as defined in [RFC2045], section 6.8), "qp-section" (ibid, | text (as defined in [RFC2045], section 6.8), "qp-section" (ibid, | |||
section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6). | section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6). | |||
The name of the tag will determine the encoding of each value. | The name of the tag will determine the encoding of each value. | |||
Unencoded semicolon (";") characters MUST NOT occur in the tag value, | Unencoded semicolon (";") characters MUST NOT occur in the tag value, | |||
since that separates tag-specs. | since that separates tag-specs. | |||
skipping to change at page 12, line 41 | skipping to change at page 12, line 41 | |||
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. For | |||
example, "g=" does not mean "g=*", even though "g=*" is the default | example, "g=" does not mean "g=*", even though "g=*" is the default | |||
for that tag. | 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. The rsa-sha256 algorithm is the default if no algorithm is | sha256. The rsa-sha256 algorithm is the default if no algorithm is | |||
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. | specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. | |||
Signers MUST implement and SHOULD sign using rsa-sha256. | Signers MUST implement and SHOULD sign using 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 | |||
in Section 3.7 below using SHA-1 [SHA] as the hash-alg. That hash is | in Section 3.7 below using SHA-1 [SHA] as the hash-alg. That hash is | |||
then signed by the signer using the RSA algorithm (defined in PKCS#1 | then signed by the signer using the RSA algorithm (defined in PKCS#1 | |||
version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. | |||
The hash MUST NOT be truncated or converted into any form other than | The hash MUST NOT be truncated or converted into any form other than | |||
the native binary form before being signed. | the native binary form before being signed. The signing algorithm | |||
SHOULD use an exponent of 65537. | ||||
INFORMATIVE IMPLEMENTATION WARNING: Low-valued exponents should | ||||
be avoided, as they are believed to be subject to attack. | ||||
3.3.2 The rsa-sha256 Signing Algorithm | 3.3.2. The rsa-sha256 Signing Algorithm | |||
The rsa-sha256 Signing Algorithm computes a message hash as described | The rsa-sha256 Signing Algorithm computes a message hash as described | |||
in Section 3.7 below using SHA-256 [SHA] as the hash-alg. That hash | in Section 3.7 below using SHA-256 [SHA] as the hash-alg. That hash | |||
is then signed by the signer using the RSA algorithm (defined in | is then signed by the signer using the RSA algorithm (defined in | |||
PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's | PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's | |||
private key. The hash MUST NOT be truncated or converted into any | private key. The hash MUST NOT be truncated or converted into any | |||
form other than the native binary form before being signed. | form other than the native binary form before being signed. | |||
3.3.3 Key sizes | 3.3.3. Key sizes | |||
Selecting appropriate key sizes is a trade-off between cost, | Selecting appropriate key sizes is a trade-off between cost, | |||
performance and risk. Since short RSA keys more easily succumb to | performance and risk. Since short RSA keys more easily succumb to | |||
off-line attacks, signers MUST use RSA keys of at least 1024 bits for | off-line attacks, signers MUST use RSA keys of at least 1024 bits for | |||
long-lived keys. Verifiers MUST be able to validate signatures with | long-lived keys. Verifiers MUST be able to validate signatures with | |||
keys ranging from 512 bits to 2048 bits, and they MAY be able to | keys ranging from 512 bits to 2048 bits, and they MAY be able to | |||
validate signatures with larger keys. Verifier policies may use the | validate signatures with larger keys. Verifier policies may use the | |||
length of the signing key as one metric for determining whether a | length of the signing key as one metric for determining whether a | |||
signature is acceptable. | signature is acceptable. | |||
skipping to change at page 14, line 4 | skipping to change at page 13, line 48 | |||
o The practical constraint that large (e.g., 4096 bit) keys may not | o The practical constraint that large (e.g., 4096 bit) keys may not | |||
fit within a 512 byte DNS UDP response packet | fit within a 512 byte DNS UDP response packet | |||
o The security constraint that keys smaller than 1024 bits are | o The security constraint that keys smaller than 1024 bits are | |||
subject to off-line attacks | subject to off-line attacks | |||
o Larger keys impose higher CPU costs to verify and sign email | o Larger keys impose higher CPU costs to verify and sign email | |||
o Keys can be replaced on a regular basis, thus their lifetime can | o Keys can be replaced on a regular basis, thus their lifetime can | |||
be relatively short | be relatively short | |||
o The security goals of this specification are modest compared to | o The security goals of this specification are modest compared to | |||
typical goals of other systems that employ digital signatures | typical goals of other systems that employ digital signatures | |||
See [RFC3766] for further discussion on selecting key sizes. | See [RFC3766] for further discussion on selecting key sizes. | |||
3.3.4 Other algorithms | 3.3.4. Other algorithms | |||
Other algorithms MAY be defined in the future. Verifiers MUST ignore | Other algorithms MAY be defined in the future. Verifiers MUST ignore | |||
any signatures using algorithms that they do not implement. | any signatures using algorithms that they do not implement. | |||
3.4 Canonicalization | 3.4. Canonicalization | |||
Empirical evidence demonstrates that some mail servers and relay | Empirical evidence demonstrates that some mail servers and relay | |||
systems modify email in transit, potentially invalidating a | systems modify email in transit, potentially invalidating a | |||
signature. There are two competing perspectives on such | signature. There are two competing perspectives on such | |||
modifications. For most signers, mild modification of email is | modifications. For most signers, mild modification of email is | |||
immaterial to the authentication status of the email. For such | immaterial to the authentication status of the email. For such | |||
signers a canonicalization algorithm that survives modest in-transit | signers a canonicalization algorithm that survives modest in-transit | |||
modification is preferred. | modification is preferred. | |||
Other signers demand that any modification of the email, however | Other signers demand that any modification of the email, however | |||
skipping to change at page 15, line 8 | skipping to change at page 15, line 5 | |||
Canonicalization simply prepares the email for presentation to the | Canonicalization simply prepares the email for presentation to the | |||
signing or verification algorithm. It MUST NOT change the | signing or verification algorithm. It MUST NOT change the | |||
transmitted data in any way. Canonicalization of header fields and | transmitted data in any way. Canonicalization of header fields and | |||
body are described below. | body are described below. | |||
NOTE: This section assumes that the message is already in "network | NOTE: This section assumes that the message is already in "network | |||
normal" format (e.g., text is ASCII encoded, lines are separated with | normal" format (e.g., text is ASCII encoded, lines are separated with | |||
CRLF characters, etc.). See also Section 5.3 for information about | CRLF characters, etc.). See also Section 5.3 for information about | |||
normalizing the message. | normalizing the message. | |||
3.4.1 The "simple" Header Canonicalization Algorithm | 3.4.1. The "simple" Header Canonicalization Algorithm | |||
The "simple" header canonicalization algorithm does not change header | The "simple" header canonicalization algorithm does not change header | |||
fields in any way. Header fields MUST be presented to the signing or | fields in any way. Header fields MUST be presented to the signing or | |||
verification algorithm exactly as they are in the message being | verification algorithm exactly as they are in the message being | |||
signed or verified. In particular, header field names MUST NOT be | signed or verified. In particular, header field names MUST NOT be | |||
case folded and white space MUST NOT be changed. | case folded and white space MUST NOT be changed. | |||
3.4.2 The "relaxed" Header Canonicalization Algorithm | 3.4.2. The "relaxed" Header Canonicalization Algorithm | |||
The "relaxed" header canonicalization algorithm MUST apply the | The "relaxed" header canonicalization algorithm MUST apply the | |||
following steps in order: | following steps in order: | |||
o Convert all header field names (not the header field values) to | o Convert all header field names (not the header field values) to | |||
lower case. For example, convert "SUBJect: AbC" to "subject: | lower case. For example, convert "SUBJect: AbC" to "subject: | |||
AbC". | AbC". | |||
o Unfold all header field continuation lines as described in | o Unfold all header field continuation lines as described in | |||
[RFC2822]; in particular, lines with terminators embedded in | [RFC2822]; in particular, lines with terminators embedded in | |||
skipping to change at page 15, line 42 | skipping to change at page 15, line 39 | |||
character. WSP characters here include those before and after a | character. WSP characters here include those before and after a | |||
line folding boundary. | line folding boundary. | |||
o Delete all WSP characters at the end of each unfolded header field | o Delete all WSP characters at the end of each unfolded header field | |||
value. | value. | |||
o Delete any WSP characters remaining before and after the colon | o Delete any WSP characters remaining before and after the colon | |||
separating the header field name from the header field value. The | separating the header field name from the header field value. The | |||
colon separator MUST be retained. | colon separator MUST be retained. | |||
3.4.3 The "simple" Body Canonicalization Algorithm | 3.4.3. The "simple" Body Canonicalization Algorithm | |||
The "simple" body canonicalization algorithm ignores all empty lines | The "simple" body canonicalization algorithm ignores all empty lines | |||
at the end of the message body. An empty line is a line of zero | at the end of the message body. An empty line is a line of zero | |||
length after removal of the line terminator. If there is no body or | length after removal of the line terminator. If there is no body or | |||
no trailing CRLF on the message body, a CRLF is added. It makes no | no trailing CRLF on the message body, a CRLF is added. It makes no | |||
other changes to the message body. In more formal terms, the | other changes to the message body. In more formal terms, the | |||
"simple" body canonicalization algorithm converts "0*CRLF" at the end | "simple" body canonicalization algorithm converts "0*CRLF" at the end | |||
of the body to a single "CRLF". | of the body to a single "CRLF". | |||
Note that a completely empty or missing body is canonicalized as a | Note that a completely empty or missing body is canonicalized as a | |||
single "CRLF"; that is, the canonicalized length will be 2 octets. | single "CRLF"; that is, the canonicalized length will be 2 octets. | |||
3.4.4 The "relaxed" Body Canonicalization Algorithm | 3.4.4. The "relaxed" Body Canonicalization Algorithm | |||
The "relaxed" body canonicalization algorithm: | The "relaxed" body canonicalization algorithm: | |||
o Ignores all white space at the end of lines. Implementations MUST | o Ignores all white space at the end of lines. Implementations MUST | |||
NOT remove the CRLF at the end of the line. | NOT remove the CRLF at the end of the line. | |||
o Reduces all sequences of WSP within a line to a single SP | o Reduces all sequences of WSP within a line to a single SP | |||
character. | character. | |||
o Ignores all empty lines at the end of the message body. "Empty | o Ignores all empty lines at the end of the message body. "Empty | |||
line" is defined in Section 3.4.3. | line" is defined in Section 3.4.3. | |||
3.4.5 Body Length Limits | INFORMATIVE NOTE: It should be noted that the relaxed body | |||
canonicalization algorithm may enable certain types of extremely | ||||
crude "ASCII Art" attacks where a message may be conveyed by | ||||
adjusting the spacing between words. If this is a concern, the | ||||
"simple" body canonicalization algorithm should be used instead. | ||||
3.4.5. Body Length Limits | ||||
A body length count MAY be specified to limit the signature | A body length count MAY be specified to limit the signature | |||
calculation to an initial prefix of the body text, measured in | calculation to an initial prefix of the body text, measured in | |||
octets. If the body length count is not specified then the entire | octets. If the body length count is not specified then the entire | |||
message body is signed. | message body is signed. | |||
INFORMATIVE RATIONALE: This capability is provided because it is | INFORMATIVE RATIONALE: This capability is provided because it is | |||
very common for mailing lists to add trailers to messages (e.g., | very common for mailing lists to add trailers to messages (e.g., | |||
instructions how to get off the list). Until those messages are | instructions how to get off the list). Until those messages are | |||
also signed, the body length count is a useful tool for the | also signed, the body length count is a useful tool for the | |||
skipping to change at page 17, line 22 | skipping to change at page 17, line 24 | |||
only works for some MIME types, e.g., multipart/mixed but not | only works for some MIME types, e.g., multipart/mixed but not | |||
multipart/signed. | multipart/signed. | |||
A body length count of zero means that the body is completely | A body length count of zero means that the body is completely | |||
unsigned. | unsigned. | |||
Signers wishing to ensure that no modification of any sort can occur | Signers wishing to ensure that no modification of any sort can occur | |||
should specify the "simple" canonicalization algorithm for both | should specify the "simple" canonicalization algorithm for both | |||
header and body and omit the body length count. | header and body and omit the body length count. | |||
3.4.6 Canonicalization Examples (INFORMATIVE) | 3.4.6. Canonicalization Examples (INFORMATIVE) | |||
In the following examples, actual white space is used only for | In the following examples, actual white space is used only for | |||
clarity. The actual input and output text is designated using | clarity. The actual input and output text is designated using | |||
bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a | |||
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | tab character, and "<CRLF>" for a carriage-return/line-feed sequence. | |||
For example, "X <SP> Y" and "X<SP>Y" represent the same three | For example, "X <SP> Y" and "X<SP>Y" represent the same three | |||
characters. | characters. | |||
Example 1: A message reading: | Example 1: A message reading: | |||
A: <SP> X <CRLF> | A: <SP> X <CRLF> | |||
skipping to change at page 18, line 25 | skipping to change at page 18, line 25 | |||
Example 3: When processed using relaxed header canonicalization and | Example 3: When processed using relaxed header canonicalization and | |||
simple body canonicalization, the canonicalized version has a header | simple body canonicalization, the canonicalized version has a header | |||
of: | of: | |||
a:X <CRLF> | a:X <CRLF> | |||
b:Y <SP> Z <CRLF> | b:Y <SP> Z <CRLF> | |||
and a body reading: | and a body reading: | |||
<SP> C <SP><CRLF> | <SP> C <SP><CRLF> | |||
D <SP><HTAB><SP> E <CRLF> | D <SP><HTAB><SP> E <CRLF> | |||
3.5 The DKIM-Signature header field | 3.5. The DKIM-Signature header field | |||
The signature of the email is stored in the "DKIM-Signature:" header | The signature of the email is stored in the "DKIM-Signature:" header | |||
field. This header field contains all of the signature and key- | field. This header field contains all of the signature and key- | |||
fetching data. The DKIM-Signature value is a tag-list as described | fetching data. The DKIM-Signature value is a tag-list as described | |||
in Section 3.2. | in Section 3.2. | |||
The "DKIM-Signature:" header field SHOULD be treated as though it | The "DKIM-Signature:" header field SHOULD be treated as though it | |||
were a trace header field as defined in section 3.6 of [RFC2822], and | were a trace header field as defined in section 3.6 of [RFC2822], and | |||
hence SHOULD NOT be reordered and SHOULD be prepended to the message. | hence SHOULD NOT be reordered and SHOULD be prepended to the message. | |||
skipping to change at page 26, line 15 | skipping to change at page 26, line 15 | |||
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; | DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; | |||
c=simple; q=dns/txt; i=@eng.example.net; | c=simple; q=dns/txt; i=@eng.example.net; | |||
t=1117574938; x=1118006938; | t=1117574938; x=1118006938; | |||
h=from:to:subject:date; | h=from:to:subject:date; | |||
z=From:foo@eng.example.net|To:joe@example.com| | z=From:foo@eng.example.net|To:joe@example.com| | |||
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; | |||
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | |||
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ | |||
VoG4ZHRNiYzR | VoG4ZHRNiYzR | |||
3.6 Key Management and Representation | 3.6. Key Management and Representation | |||
Signature applications require some level of assurance that the | Signature applications require some level of assurance that the | |||
verification public key is associated with the claimed signer. Many | verification public key is associated with the claimed signer. Many | |||
applications achieve this by using public key certificates issued by | applications achieve this by using public key certificates issued by | |||
a trusted third party. However, DKIM can achieve a sufficient level | a trusted third party. However, DKIM can achieve a sufficient level | |||
of security, with significantly enhanced scalability, by simply | of security, with significantly enhanced scalability, by simply | |||
having the verifier query the purported signer's DNS entry (or some | having the verifier query the purported signer's DNS entry (or some | |||
security-equivalent) in order to retrieve the public key. | security-equivalent) in order to retrieve the public key. | |||
DKIM keys can potentially be stored in multiple types of key servers | DKIM keys can potentially be stored in multiple types of key servers | |||
skipping to change at page 26, line 38 | skipping to change at page 26, line 38 | |||
Parameters to the key lookup algorithm are the type of the lookup | Parameters to the key lookup algorithm are the type of the lookup | |||
(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- | (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- | |||
Signature header field), and the Selector (the "s=" tag). | Signature header field), and the Selector (the "s=" tag). | |||
public_key = dkim_find_key(q_val, d_val, s_val) | public_key = dkim_find_key(q_val, d_val, s_val) | |||
This document defines a single binding, using DNS TXT records to | This document defines a single binding, using DNS TXT records to | |||
distribute the keys. Other bindings may be defined in the future. | distribute the keys. Other bindings may be defined in the future. | |||
3.6.1 Textual Representation | 3.6.1. Textual Representation | |||
It is expected that many key servers will choose to present the keys | It is expected that many key servers will choose to present the keys | |||
in an otherwise unstructured text format (for example, an XML form | in an otherwise unstructured text format (for example, an XML form | |||
would not be considered to be unstructured text for this purpose). | would not be considered to be unstructured text for this purpose). | |||
The following definition MUST be used for any DKIM key represented in | The following definition MUST be used for any DKIM key represented in | |||
an otherwise unstructured textual form. | an otherwise unstructured textual form. | |||
The overall syntax is a tag-list as described in Section 3.2. The | The overall syntax is a tag-list as described in Section 3.2. The | |||
current valid tags are described below. Other tags MAY be present | current valid tags are described below. Other tags MAY be present | |||
and MUST be ignored by any implementation that does not understand | and MUST be ignored by any implementation that does not understand | |||
skipping to change at page 27, line 36 | skipping to change at page 27, line 36 | |||
key to a third party that should only be used for special | key to a third party that should only be used for special | |||
purposes. Wildcarding allows matching for addresses such as | purposes. Wildcarding allows matching for addresses such as | |||
"user+*" or "*-offer". An empty "g=" value never matches any | "user+*" or "*-offer". An empty "g=" value never matches any | |||
addresses. | addresses. | |||
ABNF: | ABNF: | |||
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart | |||
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] | key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] | |||
[[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a "dot- | [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a | |||
atom-text". This should probably use a different character | "dot-atom-text". This should probably use a different | |||
for wildcarding. Unfortunately, the options are non-mnemonic | character for wildcarding. Unfortunately, the options are | |||
(e.g., "@", "(", ":"). Alternatively we could insist on | non-mnemonic (e.g., "@", "(", ":"). Alternatively we could | |||
escaping a "*" intended as a literal "*" in the address.]] | insist on escaping a "*" intended as a literal "*" in the | |||
address.]] | ||||
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 | algorithms that might be used. Signers and Verifiers MUST | |||
support the "sha256" hash algorithm. Verifiers MUST also support | support the "sha256" hash algorithm. Verifiers MUST also support | |||
the "sha1" hash algorithm. | the "sha1" hash algorithm. | |||
ABNF: | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | |||
skipping to change at page 30, line 12 | skipping to change at page 30, line 12 | |||
ABNF: | ABNF: | |||
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag | |||
0*( [FWS] ":" [FWS] key-t-tag-flag ) | 0*( [FWS] ":" [FWS] key-t-tag-flag ) | |||
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | key-t-tag-flag = "y" / "s" / x-key-t-tag-flag | |||
x-key-t-tag-flag = hyphenated-word ; for future extension | x-key-t-tag-flag = hyphenated-word ; for future extension | |||
Unrecognized flags MUST be ignored. | Unrecognized flags MUST be ignored. | |||
3.6.2 DNS binding | 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 Name Space | 3.6.2.1. Name Space | |||
All DKIM keys are stored in a subdomain named "_domainkey". Given a | All DKIM keys are stored in a subdomain named "_domainkey". Given a | |||
DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag | DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag | |||
of "foo.bar", the DNS query will be for | of "foo.bar", the DNS query will be for | |||
"foo.bar._domainkey.example.com". | "foo.bar._domainkey.example.com". | |||
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., | INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., | |||
*.bar._domainkey.example.com) do not make sense in this context | *.bar._domainkey.example.com) do not make sense in this context | |||
and should not be used. Note also that wildcards within domains | and should not be used. Note also that wildcards within domains | |||
(e.g., s._domainkey.*.example.com) are not supported by the DNS. | (e.g., s._domainkey.*.example.com) are not supported by the DNS. | |||
3.6.2.2 Resource Record Types for Key Storage | 3.6.2.2. Resource Record Types for Key Storage | |||
The DNS Resource Record type used is specified by an option to the | The DNS Resource Record type used is specified by an option to the | |||
query-type ("q=") tag. The only option defined in this base | query-type ("q=") tag. The only option defined in this base | |||
specification is "txt", indicating the use of a TXT Resource Record | specification is "txt", indicating the use of a TXT Resource Record | |||
(RR). A later extension of this standard may define another RR type. | (RR). A later extension of this standard may define another RR type. | |||
Strings in a TXT RR MUST be concatenated together before use with no | Strings in a TXT RR MUST be concatenated together before use with no | |||
intervening white space. TXT RRs MUST be unique for a particular | intervening white space. TXT RRs MUST be unique for a particular | |||
selector name; that is, if there are multiple records in an RRset, | selector name; that is, if there are multiple records in an RRset, | |||
the results are undefined. | the results are undefined. | |||
TXT RRs are encoded as described in Section 3.6.1. | TXT RRs are encoded as described in Section 3.6.1. | |||
3.7 Computing the Message Hashes | 3.7. Computing the Message Hashes | |||
Both signing and verifying message signatures starts with a step of | Both signing and verifying message signatures starts with a step of | |||
computing two cryptographic hashes over the message. Signers will | computing two cryptographic hashes over the message. Signers will | |||
choose the parameters of the signature as described in Signer Actions | choose the parameters of the signature as described in Signer Actions | |||
(Section 5); verifiers will use the parameters specified in the | (Section 5); verifiers will use the parameters specified in the | |||
"DKIM-Signature" header field being verified. In the following | "DKIM-Signature" header field being verified. In the following | |||
discussion, the names of the tags in the "DKIM-Signature" header | discussion, the names of the tags in the "DKIM-Signature" header | |||
field which either exists (when verifying) or will be created (when | field which either exists (when verifying) or will be created (when | |||
signing) are used. Note that canonicalization (Section 3.4) is only | signing) are used. Note that canonicalization (Section 3.4) is only | |||
used to prepare the email for signing or verifying; it does not | used to prepare the email for signing or verifying; it does not | |||
skipping to change at page 32, line 35 | skipping to change at page 32, line 33 | |||
DKIM-Signature header field), and "DKIM-SIG" is the canonicalized | DKIM-Signature header field), and "DKIM-SIG" is the canonicalized | |||
DKIM-Signature header field sans the signature value itself, but with | DKIM-Signature header field sans the signature value itself, but with | |||
"body-hash" included as the "bh=" tag. | "body-hash" included as the "bh=" tag. | |||
INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs | INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs | |||
provide both hashing and application of the RSA private key using | provide both hashing and application of the RSA private key using | |||
a single "sign()" primitive. When using such an API the last two | a single "sign()" primitive. When using such an API the last two | |||
steps in the algorithm would probably be combined into a single | steps in the algorithm would probably be combined into a single | |||
call that would perform both the "hash-alg" and the "sig-alg". | call that would perform both the "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, | |||
e.g., a key record for the domain example.com can be used to verify | e.g., a key record for the domain example.com can be used to verify | |||
messages where the signing identity (i= tag of the signature) is | messages where the signing identity (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 | |||
skipping to change at page 33, line 10 | skipping to change at page 33, line 7 | |||
of the record to exactly the domain of the signing identity. If the | of the record to exactly the domain of the signing identity. If the | |||
referenced key record contains the "s" flag as part of the t= tag, | referenced key record contains the "s" flag as part of the t= tag, | |||
the domain of the signing identity (i= flag) MUST be the same as that | the domain of the signing identity (i= flag) MUST be the same as that | |||
of the d= domain. If this flag is absent, the domain of the signing | of the d= domain. If this flag is absent, the domain of the signing | |||
identity MUST be the same as, or a subdomain of, the d= domain. Key | identity MUST be the same as, or a subdomain of, the d= domain. Key | |||
records which are not intended for use with subdomains SHOULD specify | records which are not intended for use with subdomains SHOULD specify | |||
the "s" flag in the t= tag. | the "s" flag in the t= tag. | |||
4. Semantics of Multiple Signatures | 4. Semantics of Multiple Signatures | |||
4.1 Example Scenarios | 4.1. Example Scenarios | |||
There are many reasons that a message might have multiple signatures. | There are many reasons that a message might have multiple signatures. | |||
For example, a given signer might sign multiple times, perhaps with | For example, a given signer might sign multiple times, perhaps with | |||
different hashing or signing algorithms during a transition phase. | different hashing or signing algorithms during a transition phase. | |||
INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be | |||
insufficiently strong, and DKIM usage transitions to SHA-1024. A | insufficiently strong, and DKIM usage transitions to SHA-1024. A | |||
signer might immediately sign using the newer algorithm, but | signer might immediately sign using the newer algorithm, but | |||
continue to sign using the older algorithm for interoperability | continue to sign using the older algorithm for interoperability | |||
with verifiers that had not yet upgraded. The signer would do | with verifiers that had not yet upgraded. The signer would do | |||
skipping to change at page 34, line 13 | skipping to change at page 34, line 10 | |||
even from unknown authors. They might also subscribe to less | even from unknown authors. They might also subscribe to less | |||
trusted mailing lists (e.g., those without anti-abuse protection) | trusted mailing lists (e.g., those without anti-abuse protection) | |||
and be willing to accept all messages from specific authors, but | and be willing to accept all messages from specific authors, but | |||
insist on doing additional abuse scanning for other messages. | insist on doing additional abuse scanning for other messages. | |||
Another related example of multiple signers might be forwarding | Another related example of multiple signers might be forwarding | |||
services, such as those commonly associated with academic alumni | services, such as those commonly associated with academic alumni | |||
sites. | sites. | |||
INFORMATIVE EXAMPLE: A recipient might have an address at | INFORMATIVE EXAMPLE: A recipient might have an address at | |||
alumni.example.edu, a site that has anti-abuse protection that is | members.example.org, a site that has anti-abuse protection that is | |||
somewhat less effective than the recipient would prefer. Such a | somewhat less effective than the recipient would prefer. Such a | |||
recipient might have specific authors whose messages would be | recipient might have specific authors whose messages would be | |||
trusted absolutely, but messages from unknown authors which had | trusted absolutely, but messages from unknown authors which had | |||
passed the forwarder's scrutiny would have only medium trust. | passed the forwarder's scrutiny would have only medium trust. | |||
4.2 Interpretation | 4.2. Interpretation | |||
A signer that is adding a signature to a message merely creates a new | A signer that is adding a signature to a message merely creates a new | |||
DKIM-Signature header, using the usual semantics of the h= option. A | DKIM-Signature header, using the usual semantics of the h= option. A | |||
signer MAY sign previously existing DKIM-Signature header fields | signer MAY sign previously existing DKIM-Signature header fields | |||
using the method described in section Section 5.4 to sign trace | using the method described in section Section 5.4 to sign trace | |||
header fields. | header fields. | |||
INFORMATIVE NOTE: Signers should be cognizant that signing DKIM- | INFORMATIVE NOTE: Signers should be cognizant that signing DKIM- | |||
Signature header fields may result in signature failures with | Signature header fields may result in signature failures with | |||
intermediaries that do not recognize that DKIM-Signature header | intermediaries that do not recognize that DKIM-Signature header | |||
skipping to change at page 35, line 26 | skipping to change at page 35, line 20 | |||
present in the message. Verifiers SHOULD continue to check | present in the message. Verifiers SHOULD continue to check | |||
signatures until a signature successfully verifies to the | signatures until a signature successfully verifies to the | |||
satisfaction of the verifier. To limit potential denial-of-service | satisfaction of the verifier. To limit potential denial-of-service | |||
attacks, verifiers MAY limit the total number of signatures they will | attacks, verifiers MAY limit the total number of signatures they will | |||
attempt to verify. | attempt to verify. | |||
5. Signer Actions | 5. Signer Actions | |||
The following steps are performed in order by signers. | The following steps are performed in order by signers. | |||
5.1 Determine if the Email Should be Signed and by Whom | 5.1. Determine if the Email Should be Signed and by Whom | |||
A signer can obviously only sign email for domains for which it has a | A signer can obviously only sign email for domains for which it has a | |||
private key and the necessary knowledge of the corresponding public | private key and the necessary knowledge of the corresponding public | |||
key and Selector information. However there are a number of other | key and Selector information. However there are a number of other | |||
reasons beyond the lack of a private key why a signer could choose | reasons beyond the lack of a private key why a signer could choose | |||
not to sign an email. | not to sign an email. | |||
INFORMATIVE NOTE: Signing modules may be incorporated into any | INFORMATIVE NOTE: Signing modules may be incorporated into any | |||
portion of the mail system as deemed appropriate, including an | portion of the mail system as deemed appropriate, including an | |||
MUA, a SUBMISSION server, or an MTA. Wherever implemented, | MUA, a SUBMISSION server, or an MTA. Wherever implemented, | |||
skipping to change at page 36, line 5 | skipping to change at page 35, line 46 | |||
authenticated and authorized. | authenticated and authorized. | |||
INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not | INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not | |||
sign Received header fields if the outgoing gateway MTA obfuscates | sign Received header fields if the outgoing gateway MTA obfuscates | |||
Received header fields, for example to hide the details of | Received header fields, for example to hide the details of | |||
internal topology. | internal topology. | |||
If an email cannot be signed for some reason, it is a local policy | If an email cannot be signed for some reason, it is a local policy | |||
decision as to what to do with that email. | decision as to what to do with that email. | |||
5.2 Select a Private Key and Corresponding Selector Information | 5.2. Select a Private Key and Corresponding Selector Information | |||
This specification does not define the basis by which a signer should | This specification does not define the basis by which a signer should | |||
choose which private key and Selector information to use. Currently, | choose which private key and Selector information to use. Currently, | |||
all Selectors are equal as far as this specification is concerned, so | all Selectors are equal as far as this specification is concerned, so | |||
the decision should largely be a matter of administrative | the decision should largely be a matter of administrative | |||
convenience. Distribution and management of private keys is also | convenience. Distribution and management of private keys is also | |||
outside the scope of this document. | outside the scope of this document. | |||
INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a | |||
private key when the Selector containing the corresponding public | private key when the Selector containing the corresponding public | |||
key is expected to be revoked or removed before the verifier has | key is expected to be revoked or removed before the verifier has | |||
an opportunity to validate the signature. The signer should | an opportunity to validate the signature. The signer should | |||
anticipate that verifiers may choose to defer validation, perhaps | anticipate that verifiers may choose to defer validation, perhaps | |||
until the message is actually read by the final recipient. In | until the message is actually read by the final recipient. In | |||
particular, when rotating to a new key pair, signing should | particular, when rotating to a new key pair, signing should | |||
immediately commence with the new private key and the old public | immediately commence with the new private key and the old public | |||
key should be retained for a reasonable validation interval before | key should be retained for a reasonable validation interval before | |||
being removed from the key server. | being removed from the key server. | |||
5.3 Normalize the Message to Prevent Transport Conversions | 5.3. Normalize the Message to Prevent Transport Conversions | |||
Some messages, particularly those using 8-bit characters, are subject | Some messages, particularly those using 8-bit characters, are subject | |||
to modification during transit, notably conversion to 7-bit form. | to modification during transit, notably conversion to 7-bit form. | |||
Such conversions will break DKIM signatures. In order to minimize | Such conversions will break DKIM signatures. In order to minimize | |||
the chances of such breakage, signers SHOULD convert the message to a | the chances of such breakage, signers SHOULD convert the message to a | |||
suitable MIME content transfer encoding such as quoted-printable or | suitable MIME content transfer encoding such as quoted-printable or | |||
base64 as described in MIME Part One [RFC2045] before signing. Such | base64 as described in MIME Part One [RFC2045] before signing. Such | |||
conversion is outside the scope of DKIM; the actual message SHOULD be | conversion is outside the scope of DKIM; the actual message SHOULD be | |||
converted to 7-bit MIME by an MUA or MSA prior to presentation to the | converted to 7-bit MIME by an MUA or MSA prior to presentation to the | |||
DKIM algorithm. | DKIM algorithm. | |||
skipping to change at page 37, line 5 | skipping to change at page 36, line 44 | |||
bare CR or LF characters (used by some systems as a local line | bare CR or LF characters (used by some systems as a local line | |||
separator convention) MUST be converted to the SMTP-standard CRLF | separator convention) MUST be converted to the SMTP-standard CRLF | |||
sequence before the message is signed. Any conversion of this sort | sequence before the message is signed. Any conversion of this sort | |||
SHOULD be applied to the message actually sent to the recipient(s), | SHOULD be applied to the message actually sent to the recipient(s), | |||
not just to the version presented to the signing algorithm. | not just to the version presented to the signing algorithm. | |||
More generally, the signer MUST sign the message as it is expected to | More generally, the signer MUST sign the message as it is expected to | |||
be received by the verifier rather than in some local or internal | be received by the verifier rather than in some local or internal | |||
form. | form. | |||
5.4 Determine the Header Fields to Sign | 5.4. Determine the Header Fields to Sign | |||
The From header field MUST be signed (that is, included in the h= tag | The From header field MUST be signed (that is, included in the h= tag | |||
of the resulting DKIM-Signature header field). Signers SHOULD NOT | of the resulting DKIM-Signature header field). Signers SHOULD NOT | |||
sign an existing header field likely to be legitimately modified or | sign an existing header field likely to be legitimately modified or | |||
removed in transit. In particular, [RFC2821] explicitly permits | removed in transit. In particular, [RFC2821] explicitly permits | |||
modification or removal of the "Return-Path" header field in transit. | modification or removal of the "Return-Path" header field in transit. | |||
Signers MAY include any other header fields present at the time of | Signers MAY include any other header fields present at the time of | |||
signing at the discretion of the signer. | signing at the discretion of the signer. | |||
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to | INFORMATIVE OPERATIONS NOTE: The choice of which header fields to | |||
skipping to change at page 39, line 8 | skipping to change at page 39, line 5 | |||
instances by intermediate MTAs will cause DKIM signatures to be | instances by intermediate MTAs will cause DKIM signatures to be | |||
broken; such anti-social behavior should be avoided. | broken; such anti-social behavior should be avoided. | |||
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this | |||
specification, all end-user visible header fields should be signed | specification, all end-user visible header fields should be signed | |||
to avoid possible "indirect spamming." For example, if the | to avoid possible "indirect spamming." For example, if the | |||
"Subject" header field is not signed, a spammer can resend a | "Subject" header field is not signed, a spammer can resend a | |||
previously signed mail, replacing the legitimate subject with a | previously signed mail, replacing the legitimate subject with a | |||
one-line spam. | one-line spam. | |||
5.4.1 Recommended Signature Content | 5.5. Recommended Signature Content | |||
In order to maximize compatibility with a variety of verifiers, it is | In order to maximize compatibility with a variety of verifiers, it is | |||
recommended that signers follow the practices outlined in this | recommended that signers follow the practices outlined in this | |||
section when signing a message. However, these are generic | section when signing a message. However, these are generic | |||
recommendations applying to the general case; specific senders may | recommendations applying to the general case; specific senders may | |||
wish to modify these guidelines as required by their unique | wish to modify these guidelines as required by their unique | |||
situations. Verifiers MUST be capable of verifying signatures even | situations. Verifiers MUST be capable of verifying signatures even | |||
if one or more of the recommended header fields is not signed (with | if one or more of the recommended header fields is not signed (with | |||
the exception of From, which must always be signed) or if one or more | the exception of From, which must always be signed) or if one or more | |||
of the disrecommended header fields is signed. Note that verifiers | of the disrecommended header fields is signed. Note that verifiers | |||
skipping to change at page 40, line 23 | skipping to change at page 40, line 18 | |||
o DKIM-Signature | o DKIM-Signature | |||
Optional header fields (those not mentioned above) normally SHOULD | Optional header fields (those not mentioned above) normally SHOULD | |||
NOT be included in the signature, because of the potential for | NOT be included in the signature, because of the potential for | |||
additional header fields of the same name to be legitimately added or | additional header fields of the same name to be legitimately added or | |||
reordered prior to verification. There are likely to be legitimate | reordered prior to verification. There are likely to be legitimate | |||
exceptions to this rule, because of the wide variety of application- | exceptions to this rule, because of the wide variety of application- | |||
specific header fields which may be applied to a message, some of | specific header fields which may be applied to a message, some of | |||
which are unlikely to be duplicated, modified, or reordered. | which are unlikely to be duplicated, modified, or reordered. | |||
Signers SHOULD include all or nearly all of the body content when | Signers SHOULD choose canonicalization algorithms based on the types | |||
specifying the body length count (l= tag) in the signature. In | of messages they process and their aversion to risk. For example, | |||
particular, signers SHOULD NOT specify a body length of 0 since this | e-commerce sites sending primarily purchase receipts, which are not | |||
may be interpreted as a meaningless signature by some verifiers. | expected to be processed by mailing lists or other software likely to | |||
modify messages, will generally prefer "simple" canonicalization. | ||||
Sites sending primarily person-to-person email will likely prefer to | ||||
be more more resilient to modification during transport by using | ||||
"relaxed" canonicalization. | ||||
5.5 Compute the Message Hash and Signature | Signers SHOULD NOT use l= unless they intend to accomodate | |||
intermediate mail processors that append text to a message. For | ||||
example, many mailing list processors append "unsubscribe" | ||||
information to message bodies. If signers use l=, they SHOULD | ||||
include the entire message body existing at the time of signing in | ||||
computing the count. In particular, signers SHOULD NOT specify a | ||||
body length of 0 since this may be interpreted as a meaningless | ||||
signature by some verifiers. | ||||
5.6. Compute the Message Hash and Signature | ||||
The signer MUST compute the message hash as described in Section 3.7 | The signer MUST compute the message hash as described in Section 3.7 | |||
and then sign it using the selected public-key algorithm. This will | and then sign it using the selected public-key algorithm. This will | |||
result in a DKIM-Signature header field which will include the body | result in a DKIM-Signature header field which will include the body | |||
hash and a signature of the header hash, where that header includes | hash and a signature of the header hash, where that header includes | |||
the DKIM-Signature header field itself. | the DKIM-Signature header field itself. | |||
Entities such as mailing list managers that implement DKIM and which | Entities such as mailing list managers that implement DKIM and which | |||
modify the message or a header field (for example, inserting | modify the message or a header field (for example, inserting | |||
unsubscribe information) before retransmitting the message SHOULD | unsubscribe information) before retransmitting the message SHOULD | |||
check any existing signature on input and MUST make such | check any existing signature on input and MUST make such | |||
modifications before re-signing the message. | modifications before re-signing the message. | |||
The signer MAY elect to limit the number of bytes of the body that | The signer MAY elect to limit the number of bytes of the body that | |||
will be included in the hash and hence signed. The length actually | will be included in the hash and hence signed. The length actually | |||
hashed should be inserted in the "l=" tag of the "DKIM-Signature" | hashed should be inserted in the "l=" tag of the "DKIM-Signature" | |||
header field. | header field. | |||
5.6 Insert the DKIM-Signature Header Field | 5.7. Insert the DKIM-Signature Header Field | |||
Finally, the signer MUST insert the "DKIM-Signature:" header field | Finally, the signer MUST insert the "DKIM-Signature:" header field | |||
created in the previous step prior to transmitting the email. The | created in the previous step prior to transmitting the email. The | |||
"DKIM-Signature" header field MUST be the same as used to compute the | "DKIM-Signature" header field MUST be the same as used to compute the | |||
hash as described above, except that the value of the "b=" tag MUST | hash as described above, except that the value of the "b=" tag MUST | |||
be the appropriately signed hash computed in the previous step, | be the appropriately signed hash computed in the previous step, | |||
signed using the algorithm specified in the "a=" tag of the "DKIM- | signed using the algorithm specified in the "a=" tag of the "DKIM- | |||
Signature" header field and using the private key corresponding to | Signature" header field and using the private key corresponding to | |||
the Selector given in the "s=" tag of the "DKIM-Signature" header | the Selector given in the "s=" tag of the "DKIM-Signature" header | |||
field, as chosen above in Section 5.2 | field, as chosen above in Section 5.2 | |||
skipping to change at page 41, line 46 | skipping to change at page 42, line 8 | |||
A verifying MTA MAY implement a policy with respect to unverifiable | A verifying MTA MAY implement a policy with respect to unverifiable | |||
mail, regardless of whether or not it applies the verification header | mail, regardless of whether or not it applies the verification header | |||
field to signed messages. | field to signed messages. | |||
Verifiers MUST produce a result that is semantically equivalent to | Verifiers MUST produce a result that is semantically equivalent to | |||
applying the following steps in the order listed. In practice, | applying the following steps in the order listed. In practice, | |||
several of these steps can be performed in parallel in order to | several of these steps can be performed in parallel in order to | |||
improve performance. | improve performance. | |||
6.1 Extract Signatures from the Message | 6.1. Extract Signatures from the Message | |||
The order in which verifiers try DKIM-Signature header fields is not | The order in which verifiers try DKIM-Signature header fields is not | |||
defined; verifiers MAY try signatures in any order they would like. | defined; verifiers MAY try signatures in any order they would like. | |||
For example, one implementation might prefer to try the signatures in | For example, one implementation might prefer to try the signatures in | |||
textual order, whereas another might want to prefer signatures by | textual order, whereas another might want to prefer signatures by | |||
identities that match the contents of the "From" header field over | identities that match the contents of the "From" header field over | |||
other identities. Verifiers MUST NOT attribute ultimate meaning to | other identities. Verifiers MUST NOT attribute ultimate meaning to | |||
the order of multiple DKIM-Signature header fields. In particular, | the order of multiple DKIM-Signature header fields. In particular, | |||
there is reason to believe that some relays will reorder the header | there is reason to believe that some relays will reorder the header | |||
fields in potentially arbitrary ways. | fields in potentially arbitrary ways. | |||
skipping to change at page 43, line 25 | skipping to change at page 43, line 34 | |||
the original submitter signature in place even though the exploder | the original submitter signature in place even though the exploder | |||
knows that it is modifying the message in some way that will break | knows that it is modifying the message in some way that will break | |||
that signature, and the exploder inserts its own signature. In | that signature, and the exploder inserts its own signature. In | |||
this case the message should succeed even in the presence of the | this case the message should succeed even in the presence of the | |||
known-broken signature. | known-broken signature. | |||
For each signature to be validated, the following steps should be | For each signature to be validated, the following steps should be | |||
performed in such a manner as to produce a result that is | performed in such a manner as to produce a result that is | |||
semantically equivalent to performing them in the indicated order. | semantically equivalent to performing them in the indicated order. | |||
6.1.1 Validate the Signature Header Field | 6.1.1. Validate the Signature Header Field | |||
Implementers MUST meticulously validate the format and values in the | Implementers MUST meticulously validate the format and values in the | |||
DKIM-Signature header field; any inconsistency or unexpected values | DKIM-Signature header field; any inconsistency or unexpected values | |||
MUST cause the header field to be completely ignored and the verifier | MUST cause the header field to be completely ignored and the verifier | |||
to return PERMFAIL (signature syntax error). Being "liberal in what | to return PERMFAIL (signature syntax error). Being "liberal in what | |||
you accept" is definitely a bad strategy in this security context. | you accept" is definitely a bad strategy in this security context. | |||
Note however that this does not include the existence of unknown tags | Note however that this does not include the existence of unknown tags | |||
in a DKIM-Signature header field, which are explicitly permitted. | in a DKIM-Signature header field, which are explicitly permitted. | |||
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag | Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag | |||
skipping to change at page 44, line 22 | skipping to change at page 44, line 30 | |||
verifier should return PERMFAIL (domain mismatch). | verifier should return PERMFAIL (domain mismatch). | |||
If the "h=" tag does not include the "From" header field the verifier | If the "h=" tag does not include the "From" header field the verifier | |||
MUST ignore the DKIM-Signature header field and return PERMFAIL (From | MUST ignore the DKIM-Signature header field and return PERMFAIL (From | |||
field not signed). | field not signed). | |||
Verifiers MAY ignore the DKIM-Signature header field and return | Verifiers MAY ignore the DKIM-Signature header field and return | |||
PERMFAIL (signature expired) if it contains an "x=" tag and the | PERMFAIL (signature expired) if it contains an "x=" tag and the | |||
signature has expired. | signature has expired. | |||
Verifiers MAY ignore the DKIM-Signature header field if the domain | ||||
used by the signer in the d= tag is not associated with a valid | ||||
signing entity. For example, signatures with d= values such as "com" | ||||
and "co.uk" may be ignored. | ||||
Verifiers MAY ignore the DKIM-Signature header field and return | Verifiers MAY ignore the DKIM-Signature header field and return | |||
PERMFAIL (unacceptable signature header) for any other reason, for | PERMFAIL (unacceptable signature header) for any other reason, for | |||
example, if the signature does not sign header fields that the | example, if the signature does not sign header fields that the | |||
verifier views to be essential. As a case in point, if MIME header | verifier views to be essential. As a case in point, if MIME header | |||
fields are not signed, certain attacks may be possible that the | fields are not signed, certain attacks may be possible that the | |||
verifier would prefer to avoid. | verifier would prefer to avoid. | |||
6.1.2 Get the Public Key | 6.1.2. Get the Public Key | |||
The public key for a signature is needed to complete the verification | The public key for a signature is needed to complete the verification | |||
process. The process of retrieving the public key depends on the | process. The process of retrieving the public key depends on the | |||
query type as defined by the "q=" tag in the "DKIM-Signature:" header | query type as defined by the "q=" tag in the "DKIM-Signature:" header | |||
field. Obviously, a public key need only be retrieved if the process | field. Obviously, a public key need only be retrieved if the process | |||
of extracting the signature information is completely successful. | of extracting the signature information is completely successful. | |||
Details of key management and representation are described in | Details of key management and representation are described in | |||
Section 3.6. The verifier MUST validate the key record and MUST | Section 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. | |||
skipping to change at page 46, line 12 | skipping to change at page 46, line 25 | |||
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 | 9. If the public key data is not suitable for use with the algorithm | |||
and key types defined by the "a=" and "k=" tags in the "DKIM- | 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 | |||
specified in the "l=" tag, and the header field names in the "h=" | specified in the "l=" tag, and the header field names in the "h=" | |||
tag, prepare a canonicalized version of the message as is | tag, prepare a canonicalized version of the message as is | |||
described in Section 3.7 (note that this version does not | described in Section 3.7 (note that this version does not | |||
actually need to be instantiated). When matching header field | actually need to be instantiated). When matching header field | |||
names in the "h=" tag against the actual message header field, | names in the "h=" tag against the actual message header field, | |||
skipping to change at page 47, line 25 | skipping to change at page 47, line 36 | |||
at the indicated body length might pass on a malformed MIME | at the indicated body length might pass on a malformed MIME | |||
message if the signer used the "N-4" trick (omitting the final | message if the signer used the "N-4" trick (omitting the final | |||
"--CRLF") described in the informative note in Section 3.4.5. | "--CRLF") described in the informative note in Section 3.4.5. | |||
Such verifiers may wish to check for this case and include a | Such verifiers may wish to check for this case and include a | |||
trailing "--CRLF" to avoid breaking the MIME structure. A simple | trailing "--CRLF" to avoid breaking the MIME structure. A simple | |||
way to achieve this might be to append "--CRLF" to any "multipart" | way to achieve this might be to append "--CRLF" to any "multipart" | |||
message with a body length; if the MIME structure is already | message with a body length; if the MIME structure is already | |||
correctly formed, this will appear in the postlude and will not be | correctly formed, this will appear in the postlude and will not be | |||
displayed to the end user. | displayed to the end user. | |||
6.2 Communicate Verification Results | 6.2. Communicate Verification Results | |||
Verifiers wishing to communicate the results of verification to other | Verifiers wishing to communicate the results of verification to other | |||
parts of the mail system may do so in whatever manner they see fit. | parts of the mail system may do so in whatever manner they see fit. | |||
For example, implementations might choose to add an email header | For example, implementations might choose to add an email header | |||
field to the message before passing it on. Any such header field | field to the message before passing it on. Any such header field | |||
SHOULD be inserted before any existing DKIM-Signature or preexisting | SHOULD be inserted before any existing DKIM-Signature or preexisting | |||
authentication status header fields in the header field block. | authentication status header fields in the header field block. | |||
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | INFORMATIVE ADVICE to MUA filter writers: Patterns intended to | |||
search for results header fields to visibly mark authenticated | search for results header fields to visibly mark authenticated | |||
mail for end users should verify that such header field was added | mail for end users should verify that such header field was added | |||
by the appropriate verifying domain and that the verified identity | by the appropriate verifying domain and that the verified identity | |||
matches the author identity that will be displayed by the MUA. In | matches the author identity that will be displayed by the MUA. In | |||
particular, MUA filters should not be influenced by bogus results | particular, MUA filters should not be influenced by bogus results | |||
header fields added by attackers. To circumvent this attack, | header fields added by attackers. To circumvent this attack, | |||
verifiers may wish to delete existing results header fields after | verifiers may wish to delete existing results header fields after | |||
verification and before adding a new header field. | verification and before adding a new header field. | |||
6.3 Interpret Results/Apply Local Policy | 6.3. Interpret Results/Apply Local Policy | |||
It is beyond the scope of this specification to describe what actions | It is beyond the scope of this specification to describe what actions | |||
a verifier system should make, but an authenticated email presents an | a verifier system should make, but an authenticated email presents an | |||
opportunity to a receiving system that unauthenticated email cannot. | opportunity to a receiving system that unauthenticated email cannot. | |||
Specifically, an authenticated email creates a predictable identifier | Specifically, an authenticated email creates a predictable identifier | |||
by which other decisions can reliably be managed, such as trust and | by which other decisions can reliably be managed, such as trust and | |||
reputation. Conversely, unauthenticated email lacks a reliable | reputation. Conversely, unauthenticated email lacks a reliable | |||
identifier that can be used to assign trust and reputation. It is | identifier that can be used to assign trust and reputation. It is | |||
reasonable to treat unauthenticated email as lacking any trust and | reasonable to treat unauthenticated email as lacking any trust and | |||
having no positive reputation. | having no positive reputation. | |||
In general verifiers SHOULD NOT reject messages solely on the basis | In general verifiers SHOULD NOT reject messages solely on the basis | |||
of a lack of signature or an unverifiable signature; such rejection | of a lack of signature or an unverifiable signature; such rejection | |||
would cause severe interoperability problems. However, if the | would cause severe interoperability problems. However, if the | |||
verifier does opt to reject such messages (for example, when | verifier does opt to reject such messages (for example, when | |||
communicating with a peer who, by prior agreement, agrees to only | communicating with a peer who, by prior agreement, agrees to only | |||
send signed messages), and the verifier runs synchronously with the | send signed messages), and the verifier runs synchronously with the | |||
SMTP session and a signature is missing or does not verify, the MTA | SMTP session and a signature is missing or does not verify, the MTA | |||
SHOULD use a 550/5.7.x reply code, for example: | SHOULD use a 550/5.7.x reply code. | |||
550 5.7.1 Unsigned messages not accepted | ||||
550 5.7.5 Message signature incorrect | ||||
If it is not possible to fetch the public key, perhaps because the | If it is not possible to fetch the public key, perhaps because the | |||
key server is not available, a temporary failure message MAY be | key server is not available, a temporary failure message MAY be | |||
generated using a 451/4.7.5 reply code, such as: | generated using a 451/4.7.5 reply code, such as: | |||
451 4.7.5 Unable to verify signature - key server unavailable | 451 4.7.5 Unable to verify signature - key server unavailable | |||
Temporary failures such as inability to access the key server or | Temporary failures such as inability to access the key server or | |||
other external service are the only conditions that SHOULD use a 4xx | other external service are the only conditions that SHOULD use a 4xx | |||
SMTP reply code. In particular, cryptographic signature verification | SMTP reply code. In particular, cryptographic signature verification | |||
skipping to change at page 49, line 11 | skipping to change at page 49, line 16 | |||
never there, or was it removed by an over-zealous filter? For | never there, or was it removed by an over-zealous filter? For | |||
diagnostic purposes, the exact reason why the verification fails | diagnostic purposes, the exact reason why the verification fails | |||
SHOULD be made available to the policy module and possibly recorded | SHOULD be made available to the policy module and possibly recorded | |||
in the system logs. If the email cannot be verified, then it SHOULD | in the system logs. If the email cannot be verified, then it SHOULD | |||
be rendered the same as all unverified email regardless of whether it | be rendered the same as all unverified email regardless of whether it | |||
looks like it was signed or not. | looks like it was signed or not. | |||
7. IANA Considerations | 7. IANA Considerations | |||
DKIM introduces some new namespaces that require IANA registry. In | DKIM introduces some new namespaces that require IANA registry. In | |||
all cases, new values are assigned only for Standards Track RFCs | all cases, new values are assigned only for values that have | |||
approved by the IESG. | documented in a published RFC having IETF Consensus [RFC2434]. | |||
7.1 DKIM-Signature Tag Specifications | 7.1. DKIM-Signature Tag Specifications | |||
A DKIM-Signature provides for a list of tag specifications. IANA is | A DKIM-Signature provides for a list of tag specifications. IANA is | |||
requested to establish the DKIM Signature Tag Specification Registry, | requested to establish the DKIM Signature Tag Specification Registry, | |||
for tag specifications that can be used in DKIM-Signature fields and | for tag specifications that can be used in DKIM-Signature fields and | |||
that have been specified in any published RFC. | that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
skipping to change at page 49, line 42 | skipping to change at page 49, line 47 | |||
| h | (this document) | | | h | (this document) | | |||
| i | (this document) | | | i | (this document) | | |||
| l | (this document) | | | l | (this document) | | |||
| q | (this document) | | | q | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
| t | (this document) | | | t | (this document) | | |||
| x | (this document) | | | x | (this document) | | |||
| z | (this document) | | | z | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
7.2 DKIM-Signature Query Method Registry | DKIM Signature Tag Specification Registry Initial Values | |||
7.2. DKIM-Signature Query Method Registry | ||||
The "q=" tag-spec, as specified in Section 3.5 provides for a list of | The "q=" tag-spec, as specified in Section 3.5 provides for a list of | |||
query methods. | query methods. | |||
IANA is requested to establish the DKIM Query Method Registry, for | IANA is requested to establish the DKIM Query Method Registry, for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM and have been | validation processing of a message signed using DKIM and have been | |||
specified in any published RFC. | specified in any published RFC. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
| TYPE | OPTION | REFERENCE | | | TYPE | OPTION | REFERENCE | | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
| dns | txt | (this document) | | | dns | txt | (this document) | | |||
+------+--------+-----------------+ | +------+--------+-----------------+ | |||
7.3 DKIM-Signature Canonicalization Registry | DKIM-Signature Query Method Registry Initial Values | |||
7.3. DKIM-Signature Canonicalization Registry | ||||
The "c=" tag-spec, as specified in Section 3.5 provides for a | The "c=" tag-spec, as specified in Section 3.5 provides for a | |||
specifier for canonicalization algorithms for the header and body of | specifier for canonicalization algorithms for the header and body of | |||
the message. | the message. | |||
IANA is requested to establish the DKIM Canonicalization Algorithm | IANA is requested to establish the DKIM Canonicalization Algorithm | |||
Registry, for algorithms for converting a message into a canonical | Registry, for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM and have been specified | form before signing or verifying using DKIM and have been specified | |||
in any published RFC. | in any published RFC. | |||
The initial entries in the header registry comprise: | The initial entries in the header registry comprise: | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| simple | (this document) | | | simple | (this document) | | |||
| relaxed | (this document) | | | relaxed | (this document) | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
DKIM-Signature Header Canonicalization Algorithm Registry Initial | ||||
Values | ||||
The initial entries in the body registry comprise: | The initial entries in the body registry comprise: | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
| simple | (this document) | | | simple | (this document) | | |||
| relaxed | (this document) | | | relaxed | (this document) | | |||
+---------+-----------------+ | +---------+-----------------+ | |||
7.4 _domainkey DNS TXT Record Tag Specifications | DKIM-Signature Body Canonicalization Algorithm Registry Initial | |||
Values | ||||
7.4. _domainkey DNS TXT Record Tag Specifications | ||||
A _domainkey DNS TXT record provides for a list of tag | A _domainkey DNS TXT record provides for a list of tag | |||
specifications. IANA is requested to establish the DKIM _domainkey | specifications. IANA is requested to establish the DKIM _domainkey | |||
DNS TXT Tag Specification Registry, for tag specifications that can | DNS TXT Tag Specification Registry, for tag specifications that can | |||
be used in DNS TXT Records and that have been specified in any | be used in DNS TXT Records and that have been specified in any | |||
published RFC. | published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
skipping to change at page 51, line 20 | skipping to change at page 51, line 39 | |||
| v | (this document) | | | v | (this document) | | |||
| g | (this document) | | | g | (this document) | | |||
| h | (this document) | | | h | (this document) | | |||
| k | (this document) | | | k | (this document) | | |||
| n | (this document) | | | n | (this document) | | |||
| p | (this document) | | | p | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
| t | (this document) | | | t | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
7.5 DKIM Key Type Registry | DKIM _domainkey DNS TXT Record Tag Specification Registry Initial | |||
Values | ||||
7.5. DKIM Key Type Registry | ||||
The "k=" <key-k-tag> (as specified in Section 3.6.1) and the "a=" | The "k=" <key-k-tag> (as specified in Section 3.6.1) and the "a=" | |||
<sig-a-tag-k> (Section 3.5) tags provide for a list of mechanisms | <sig-a-tag-k> (Section 3.5) tags provide for a list of mechanisms | |||
that can be used to decode a DKIM signature. | that can be used to decode a DKIM signature. | |||
IANA is requested to establish the DKIM Key Type Registry, for such | IANA is requested to establish the DKIM Key Type Registry, for such | |||
mechanisms that have been specified in any published RFC. | mechanisms that have been specified in any published RFC. | |||
The initial entry in the registry comprises: | The initial entry in the registry comprises: | |||
+------+-----------+ | +------+-----------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------+ | +------+-----------+ | |||
| rsa | [RFC3447] | | | rsa | [RFC3447] | | |||
+------+-----------+ | +------+-----------+ | |||
7.6 DKIM Hash Algorithms Registry | DKIM Key Type Initial Values | |||
7.6. DKIM Hash Algorithms Registry | ||||
The "h=" <key-h-tag> list (specified in Section 3.6.1) and the "a=" | The "h=" <key-h-tag> list (specified in Section 3.6.1) and the "a=" | |||
<sig-a-tag-h> (Section 3.5) provide for a list of mechanisms that can | <sig-a-tag-h> (Section 3.5) provide for a list of mechanisms that can | |||
be used to produce a digest of message data. | be used to produce a digest of message data. | |||
IANA is requested to establish the DKIM Hash Algorithms Registry, for | IANA is requested to establish the DKIM Hash Algorithms Registry, for | |||
such mechanisms that have been specified in any published RFC. | such mechanisms that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+--------+-----------+ | +--------+-----------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+--------+-----------+ | +--------+-----------+ | |||
| sha1 | [SHA] | | | sha1 | [SHA] | | |||
| sha256 | [SHA] | | | sha256 | [SHA] | | |||
+--------+-----------+ | +--------+-----------+ | |||
7.7 DKIM Service Types Registry | DKIM Hash Algorithms Initial Values | |||
7.7. DKIM Service Types Registry | ||||
The "s=" <key-s-tag> list (specified in Section 3.6.1) provides for a | The "s=" <key-s-tag> list (specified in Section 3.6.1) provides for a | |||
list of service types to which this selector may apply. | list of service types to which this selector may apply. | |||
IANA is requested to establish the DKIM Service Types Registry, for | IANA is requested to establish the DKIM Service Types Registry, for | |||
service types that have been specified in any published RFC. | service types that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+-------+-----------------+ | +-------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+-------+-----------------+ | +-------+-----------------+ | |||
| email | (this document) | | | email | (this document) | | |||
| * | (this document) | | | * | (this document) | | |||
+-------+-----------------+ | +-------+-----------------+ | |||
7.8 DKIM Selector Flags Registry | DKIM Hash Algorithms Initial Values | |||
7.8. DKIM Selector Flags Registry | ||||
The "t=" <key-t-tag> list (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> list (specified in Section 3.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA is requested to establish the DKIM Selector Flags Registry, for | IANA is requested to establish the DKIM Selector Flags Registry, for | |||
additional flags that have been specified in any published RFC. | additional flags that have been specified in any published RFC. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| y | (this document) | | | y | (this document) | | |||
| s | (this document) | | | s | (this document) | | |||
+------+-----------------+ | +------+-----------------+ | |||
7.9 DKIM-Signature Header Field | DKIM Hash Algorithms Initial Values | |||
IANA is requested to add DKIM-Signature to the "Permanent Header | 7.9. DKIM-Signature Header Field | |||
Messages" registry for the "mail" protocol, using this document as | ||||
the Reference. | IANA is requested to add DKIM-Signature to the "Permanent Message | |||
Header Fields" registry (see [RFC3864]) for the "mail" protocol, | ||||
using this document as the Reference. | ||||
8. Security Considerations | 8. Security Considerations | |||
It has been observed that any mechanism that is introduced which | It has been observed that any mechanism that is introduced which | |||
attempts to stem the flow of spam is subject to intensive attack. | attempts to stem the flow of spam is subject to intensive attack. | |||
DKIM needs to be carefully scrutinized to identify potential attack | DKIM needs to be carefully scrutinized to identify potential attack | |||
vectors and the vulnerability to each. See also [RFC4686]. | vectors and the vulnerability to each. See also [RFC4686]. | |||
8.1 Misuse of Body Length Limits ("l=" Tag) | 8.1. Misuse of Body Length Limits ("l=" Tag) | |||
Body length limits (in the form of the "l=" tag) are subject to | Body length limits (in the form of the "l=" tag) are subject to | |||
several potential attacks. | several potential attacks. | |||
8.1.1 Addition of new MIME parts to multipart/* | 8.1.1. Addition of new MIME parts to multipart/* | |||
If the body length limit does not cover a closing MIME multipart | If the body length limit does not cover a closing MIME multipart | |||
section (including the trailing ""--CRLF"" portion), then it is | section (including the trailing ""--CRLF"" portion), then it is | |||
possible for an attacker to intercept a properly signed multipart | possible for an attacker to intercept a properly signed multipart | |||
message and add a new body part. Depending on the details of the | message and add a new body part. Depending on the details of the | |||
MIME type and the implementation of the verifying MTA and the | MIME type and the implementation of the verifying MTA and the | |||
receiving MUA, this could allow an attacker to change the information | receiving MUA, this could allow an attacker to change the information | |||
displayed to an end user from an apparently trusted source. | displayed to an end user from an apparently trusted source. | |||
For example, if an attacker can append information to a "text/html" | For example, if an attacker can append information to a "text/html" | |||
body part, they may be able to exploit a bug in some MUAs that | body part, they may be able to exploit a bug in some MUAs that | |||
continue to read after a "</html>" marker, and thus display HTML text | continue to read after a "</html>" marker, and thus display HTML text | |||
on top of already displayed text. If a message has a "multipart/ | on top of already displayed text. If a message has a | |||
alternative" body part, they might be able to add a new body part | "multipart/alternative" body part, they might be able to add a new | |||
that is preferred by the displaying MTA. | body part that is preferred by the displaying MUA. | |||
8.1.2 Addition of new HTML content to existing content | 8.1.2. Addition of new HTML content to existing content | |||
Several receiving MUA implementations do not cease display after a | Several receiving MUA implementations do not cease display after a | |||
""</html>"" tag. In particular, this allows attacks involving | ""</html>"" tag. In particular, this allows attacks involving | |||
overlaying images on top of existing text. | overlaying images on top of existing text. | |||
INFORMATIVE EXAMPLE: Appending the following text to an existing, | INFORMATIVE EXAMPLE: Appending the following text to an existing, | |||
properly closed message will in many MUAs result in inappropriate | properly closed message will in many MUAs result in inappropriate | |||
data being rendered on top of existing, correct data: | data being rendered on top of existing, correct data: | |||
<div style="position: relative; bottom: 350px; z-index: 2;"> | <div style="position: relative; bottom: 350px; z-index: 2;"> | |||
<img src="http://www.ietf.org/images/ietflogo2e.gif" | <img src="http://www.ietf.org/images/ietflogo2e.gif" | |||
width=578 height=370> | width=578 height=370> | |||
</div> | </div> | |||
8.2 Misappropriated Private Key | 8.2. Misappropriated Private Key | |||
If the private key for a user is resident on their computer and is | If the private key for a user is resident on their computer and is | |||
not protected by an appropriately secure mechanism, it is possible | not protected by an appropriately secure mechanism, it is possible | |||
for malware to send mail as that user and any other user sharing the | for malware to send mail as that user and any other user sharing the | |||
same private key. The malware would, however, not be able to | same private key. The malware would, however, not be able to | |||
generate signed spoofs of other signers' addresses, which would aid | generate signed spoofs of other signers' addresses, which would aid | |||
in identification of the infected user and would limit the | in identification of the infected user and would limit the | |||
possibilities for certain types of attacks involving socially- | possibilities for certain types of attacks involving socially- | |||
engineered messages. This threat applies mainly to MUA-based | engineered messages. This threat applies mainly to MUA-based | |||
implementations; protection of private keys on servers can be easily | implementations; protection of private keys on servers can be easily | |||
skipping to change at page 54, line 46 | skipping to change at page 55, line 18 | |||
A somewhat more effective countermeasure is to send messages through | A somewhat more effective countermeasure is to send messages through | |||
an outgoing MTA that can authenticate the submitter using existing | an outgoing MTA that can authenticate the submitter using existing | |||
techniques (e.g., SMTP Authentication), possibly validate the message | techniques (e.g., SMTP Authentication), possibly validate the message | |||
itself (e.g., verify that the header is legitimate and that the | itself (e.g., verify that the header is legitimate and that the | |||
content passes a spam content check), and sign the message using a | content passes a spam content check), and sign the message using a | |||
key appropriate for the submitter address. Such an MTA can also | key appropriate for the submitter address. Such an MTA can also | |||
apply controls on the volume of outgoing mail each user is permitted | apply controls on the volume of outgoing mail each user is permitted | |||
to originate in order to further limit the ability of malware to | to originate in order to further limit the ability of malware to | |||
generate bulk email. | generate bulk email. | |||
8.3 Key Server Denial-of-Service Attacks | 8.3. Key Server Denial-of-Service Attacks | |||
Since the key servers are distributed (potentially separate for each | Since the key servers are distributed (potentially separate for each | |||
domain), the number of servers that would need to be attacked to | domain), the number of servers that would need to be attacked to | |||
defeat this mechanism on an Internet-wide basis is very large. | defeat this mechanism on an Internet-wide basis is very large. | |||
Nevertheless, key servers for individual domains could be attacked, | Nevertheless, key servers for individual domains could be attacked, | |||
impeding the verification of messages from that domain. This is not | impeding the verification of messages from that domain. This is not | |||
significantly different from the ability of an attacker to deny | significantly different from the ability of an attacker to deny | |||
service to the mail exchangers for a given domain, although it | service to the mail exchangers for a given domain, although it | |||
affects outgoing, not incoming, mail. | affects outgoing, not incoming, mail. | |||
A variation on this attack is that if a very large amount of mail | A variation on this attack is that if a very large amount of mail | |||
were to be sent using spoofed addresses from a given domain, the key | were to be sent using spoofed addresses from a given domain, the key | |||
servers for that domain could be overwhelmed with requests. However, | servers for that domain could be overwhelmed with requests. However, | |||
given the low overhead of verification compared with handling of the | given the low overhead of verification compared with handling of the | |||
email message itself, such an attack would be difficult to mount. | email message itself, such an attack would be difficult to mount. | |||
8.4 Attacks Against DNS | 8.4. Attacks Against DNS | |||
Since DNS is a required binding for key services, specific attacks | Since DNS is a required binding for key services, specific attacks | |||
against DNS must be considered. | against DNS must be considered. | |||
While the DNS is currently insecure [RFC3833], these security | While the DNS is currently insecure [RFC3833], these security | |||
problems are the motivation behind DNSSEC [RFC4033], and all users of | problems are the motivation behind DNSSEC [RFC4033], and all users of | |||
the DNS will reap the benefit of that work. | the DNS will reap the benefit of that work. | |||
DKIM is only intended as a "sufficient" method of proving | DKIM is only intended as a "sufficient" method of proving | |||
authenticity. It is not intended to provide strong cryptographic | authenticity. It is not intended to provide strong cryptographic | |||
skipping to change at page 55, line 45 | skipping to change at page 56, line 18 | |||
A specific DNS security issue which should be considered by DKIM | A specific DNS security issue which should be considered by DKIM | |||
verifiers is the name chaining attack described in section 2.3 of the | verifiers is the name chaining attack described in section 2.3 of the | |||
DNS Threat Analysis [RFC3833]. A DKIM verifier, while verifying a | DNS Threat Analysis [RFC3833]. A DKIM verifier, while verifying a | |||
DKIM-Signature header field, could be prompted to retrieve a key | DKIM-Signature header field, could be prompted to retrieve a key | |||
record of an attacker's choosing. This threat can be minimized by | record of an attacker's choosing. This threat can be minimized by | |||
ensuring that name servers, including recursive name servers, used by | ensuring that name servers, including recursive name servers, used by | |||
the verifier enforce strict checking of "glue" and other additional | the verifier enforce strict checking of "glue" and other additional | |||
information in DNS responses and are therefore not vulnerable to this | information in DNS responses and are therefore not vulnerable to this | |||
attack. | attack. | |||
8.5 Replay Attacks | 8.5. Replay Attacks | |||
In this attack, a spammer sends a message to be spammed to an | In this attack, a spammer sends a message to be spammed to an | |||
accomplice, which results in the message being signed by the | accomplice, which results in the message being signed by the | |||
originating MTA. The accomplice resends the message, including the | originating MTA. The accomplice resends the message, including the | |||
original signature, to a large number of recipients, possibly by | original signature, to a large number of recipients, possibly by | |||
sending the message to many compromised machines that act as MTAs. | sending the message to many compromised machines that act as MTAs. | |||
The messages, not having been modified by the accomplice, have valid | The messages, not having been modified by the accomplice, have valid | |||
signatures. | signatures. | |||
Partial solutions to this problem involve the use of reputation | Partial solutions to this problem involve the use of reputation | |||
services to convey the fact that the specific email address is being | services to convey the fact that the specific email address is being | |||
used for spam, and that messages from that signer are likely to be | used for spam, and that messages from that signer are likely to be | |||
spam. This requires a real-time detection mechanism in order to | spam. This requires a real-time detection mechanism in order to | |||
react quickly enough. However, such measures might be prone to | react quickly enough. However, such measures might be prone to | |||
abuse, if for example an attacker resent a large number of messages | abuse, if for example an attacker resent a large number of messages | |||
received from a victim in order to make them appear to be a spammer. | received from a victim in order to make them appear to be a spammer. | |||
skipping to change at page 56, line 21 | skipping to change at page 56, line 41 | |||
spam. This requires a real-time detection mechanism in order to | spam. This requires a real-time detection mechanism in order to | |||
react quickly enough. However, such measures might be prone to | react quickly enough. However, such measures might be prone to | |||
abuse, if for example an attacker resent a large number of messages | abuse, if for example an attacker resent a large number of messages | |||
received from a victim in order to make them appear to be a spammer. | received from a victim in order to make them appear to be a spammer. | |||
Large verifiers might be able to detect unusually large volumes of | Large verifiers might be able to detect unusually large volumes of | |||
mails with the same signature in a short time period. Smaller | mails with the same signature in a short time period. Smaller | |||
verifiers can get substantially the same volume information via | verifiers can get substantially the same volume information via | |||
existing collaborative systems. | existing collaborative systems. | |||
8.6 Limits on Revoking Keys | 8.6. Limits on Revoking Keys | |||
When a large domain detects undesirable behavior on the part of one | When a large domain detects undesirable behavior on the part of one | |||
of its users, it might wish to revoke the key used to sign that | of its users, it might wish to revoke the key used to sign that | |||
user's messages in order to disavow responsibility for messages which | user's messages in order to disavow responsibility for messages which | |||
have not yet been verified or which are the subject of a replay | have not yet been verified or which are the subject of a replay | |||
attack. However, the ability of the domain to do so can be limited | attack. However, the ability of the domain to do so can be limited | |||
if the same key, for scalability reasons, is used to sign messages | if the same key, for scalability reasons, is used to sign messages | |||
for many other users. Mechanisms for explicitly revoking keys on a | for many other users. Mechanisms for explicitly revoking keys on a | |||
per-address basis have been proposed but require further study as to | per-address basis have been proposed but require further study as to | |||
their utility and the DNS load they represent. | their utility and the DNS load they represent. | |||
8.7 Intentionally malformed Key Records | 8.7. Intentionally malformed Key Records | |||
It is possible for an attacker to publish key records in DNS which | It is possible for an attacker to publish key records in DNS which | |||
are intentionally malformed, with the intent of causing a denial-of- | are intentionally malformed, with the intent of causing a denial-of- | |||
service attack on a non-robust verifier implementation. The attacker | service attack on a non-robust verifier implementation. The attacker | |||
could then cause a verifier to read the malformed key record by | could then cause a verifier to read the malformed key record by | |||
sending a message to one of its users referencing the malformed | sending a message to one of its users referencing the malformed | |||
record in a (not necessarily valid) signature. Verifiers MUST | record in a (not necessarily valid) signature. Verifiers MUST | |||
thoroughly verify all key records retrieved from DNS and be robust | thoroughly verify all key records retrieved from DNS and be robust | |||
against intentionally as well as unintentionally malformed key | against intentionally as well as unintentionally malformed key | |||
records. | records. | |||
8.8 Intentionally Malformed DKIM-Signature header fields | 8.8. Intentionally Malformed DKIM-Signature header fields | |||
Verifiers MUST be prepared to receive messages with malformed DKIM- | Verifiers MUST be prepared to receive messages with malformed DKIM- | |||
Signature header fields, and thoroughly verify the header field | Signature header fields, and thoroughly verify the header field | |||
before depending on any of its contents. | before depending on any of its contents. | |||
8.9 Information Leakage | 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 | |||
verify. | verify. | |||
8.12 RSA Attacks | 8.12. RSA Attacks | |||
An attacker could create a large RSA signing key with a small | An attacker could create a large RSA signing key with a small | |||
exponent, thus requiring that the verification key have a large | exponent, thus requiring that the verification key have a large | |||
exponent. This will force verifiers to use considerable computing | exponent. This will force verifiers to use considerable computing | |||
resources to verify the signature. Verifiers might avoid this attack | resources to verify the signature. Verifiers might avoid this attack | |||
by refusing to verify signatures that reference selectors with public | by refusing to verify signatures that reference selectors with public | |||
keys having unreasonable exponents. | keys having unreasonable exponents. | |||
In general, an attacker might try to overwhelm a verifier by flooding | In general, an attacker might try to overwhelm a verifier by flooding | |||
it with messages requiring verification. This is similar to other | it with messages requiring verification. This is similar to other | |||
MTA denial-of-service attacks and should be dealt with in a similar | MTA denial-of-service attacks and should be dealt with in a similar | |||
fashion. | fashion. | |||
8.13 Inappropriate Signing by Parent Domains | 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.8 could conceivably be | |||
used by a parent domain to sign messages with identities in a | used by a parent domain to sign messages with identities in a | |||
subdomain not administratively related to the parent. For example, | subdomain not administratively related to the parent. For example, | |||
the ".com" registry could create messages with signatures using an | the ".com" registry could create messages with signatures using an | |||
"i=" value in the example.com domain. There is no general solution | "i=" value in the example.com domain. There is no general solution | |||
to this problem, since the administrative cut could occur anywhere in | to this problem, since the administrative cut could occur anywhere in | |||
the domain name. For example, in the domain "example.podunk.ca.us" | the domain name. For example, in the domain "example.podunk.ca.us" | |||
there are three administrative cuts (podunk.ca.us, ca.us, and us), | there are three administrative cuts (podunk.ca.us, ca.us, and us), | |||
any of which could create messages with an identity in the full | any of which could create messages with an identity in the full | |||
domain. | domain. | |||
INFORMATIVE NOTE: This is considered an acceptable risk for the | INFORMATIVE NOTE: This is considered an acceptable risk for the | |||
same reason that it is acceptable for domain delegation. For | same reason that it is acceptable for domain delegation. For | |||
example, in the example above any of the domains could potentially | example, in the example above any of the domains could potentially | |||
simply delegate "example.podunk.ca.us" to a server of their choice | simply delegate "example.podunk.ca.us" to a server of their choice | |||
and completely replace all DNS-served information. | and completely replace all DNS-served information. Note that a | |||
verifier MAY ignore signatures that come from an unlikely domain | ||||
such as ".com", as discussed in Section 6.1.1. | ||||
9. References | 9. References | |||
9.1 Normative References | 9.1. Normative References | |||
[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 field Extensions for Non-ASCII | Part Three: Message header field Extensions for Non-ASCII | |||
Text", RFC 2047, November 1996. | Text", RFC 2047, November 1996. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
skipping to change at page 59, line 5 | skipping to change at page 59, line 24 | |||
Specifications: ABNF", RFC 4234, October 2005. | Specifications: ABNF", RFC 4234, October 2005. | |||
[SHA] U.S. Department of Commerce, "Secure Hash Standard", FIPS | [SHA] U.S. Department of Commerce, "Secure Hash Standard", FIPS | |||
PUB 180-2, August 2002. | PUB 180-2, August 2002. | |||
[X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 | [X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 | |||
encoding rules: Specification of Basic Encoding Rules | encoding rules: Specification of Basic Encoding Rules | |||
(BER), Canonical Encoding Rules (CER) and Distinguished | (BER), Canonical Encoding Rules (CER) and Distinguished | |||
Encoding Rules (DER)", 1997. | Encoding Rules (DER)", 1997. | |||
9.2 Informative References | 9.2. Informative References | |||
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing | [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing | |||
Attacks are Practical", 2003, <http://www.usenix.org/ | Attacks are Practical", 2003, <http://www.usenix.org/ | |||
publications/library/proceedings/sec03/tech/brumley.html>. | publications/library/proceedings/sec03/tech/brumley.html>. | |||
[RFC-DK] "DomainKeys specification (to be published with this | [RFC-DK] "DomainKeys specification (to be published with this | |||
RFC)", 2005. | RFC)", 2005. | |||
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, | |||
"Security Multiparts for MIME: Multipart/Signed and | "Security Multiparts for MIME: Multipart/Signed and | |||
Multipart/Encrypted", RFC 1847, October 1995. | Multipart/Encrypted", RFC 1847, October 1995. | |||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considers Section in RFCs", BCP 26, October 1998. | ||||
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, | |||
"OpenPGP Message Format", RFC 2440, November 1998. | "OpenPGP Message Format", RFC 2440, November 1998. | |||
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for | |||
Public Keys Used For Exchanging Symmetric Keys", RFC 3766, | Public Keys Used For Exchanging Symmetric Keys", RFC 3766, | |||
April 2004. | April 2004. | |||
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain | |||
Name System (DNS)", RFC 3833, August 2004. | Name System (DNS)", RFC 3833, August 2004. | |||
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", | [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", | |||
RFC 3851, June 1999. | RFC 3851, June 1999. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | ||||
Procedures for Message Header Fields", BCP 90, | ||||
September 2004. | ||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, March 2005. | RFC 4033, March 2005. | |||
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys | [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys | |||
Identified Mail (DKIM)", RFC 4686, September 2006. | Identified Mail (DKIM)", RFC 4686, September 2006. | |||
Authors' Addresses | ||||
Eric Allman | ||||
Sendmail, Inc. | ||||
6425 Christie Ave, Suite 400 | ||||
Emeryville, CA 94608 | ||||
USA | ||||
Phone: +1 510 594 5501 | ||||
Email: eric+dkim@sendmail.org | ||||
URI: | ||||
Jon Callas | ||||
PGP Corporation | ||||
3460 West Bayshore | ||||
Palo Alto, CA 94303 | ||||
USA | ||||
Phone: +1 650 319 9016 | ||||
Email: jon@pgp.com | ||||
Mark Delany | ||||
Yahoo! Inc | ||||
701 First Avenue | ||||
Sunnyvale, CA 95087 | ||||
USA | ||||
Phone: +1 408 349 6831 | ||||
Email: markd+dkim@yahoo-inc.com | ||||
URI: | ||||
Miles Libbey | ||||
Yahoo! Inc | ||||
701 First Avenue | ||||
Sunnyvale, CA 95087 | ||||
USA | ||||
Email: mlibbeymail-mailsig@yahoo.com | ||||
URI: | ||||
Jim Fenton | ||||
Cisco Systems, Inc. | ||||
MS SJ-24/2 | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134-1706 | ||||
USA | ||||
Phone: +1 408 526 5914 | ||||
Email: fenton@cisco.com | ||||
URI: | ||||
Michael Thomas | ||||
Cisco Systems, Inc. | ||||
MS SJ-9/2 | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134-1706 | ||||
Phone: +1 408 525 5386 | ||||
Email: mat@cisco.com | ||||
Appendix A. Example of Use (INFORMATIVE) | Appendix A. Example of Use (INFORMATIVE) | |||
This section shows the complete flow of an email from submission to | This section shows the complete flow of an email from submission to | |||
final delivery, demonstrating how the various components fit | final delivery, demonstrating how the various components fit | |||
together. | together. | |||
A.1 The user composes an email | A.1. The user composes an email | |||
From: Joe SixPack <joe@football.example.com> | From: Joe SixPack <joe@football.example.com> | |||
To: Suzie Q <suzie@shopping.example.net> | To: Suzie Q <suzie@shopping.example.net> | |||
Subject: Is dinner ready? | Subject: Is dinner ready? | |||
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) | |||
Message-ID: <20030712040037.46341.5F8J@football.example.com> | Message-ID: <20030712040037.46341.5F8J@football.example.com> | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
A.2 The email is signed | A.2. The email is signed | |||
This email is signed by the example.com outbound email server and now | This email is signed by the example.com outbound email server and now | |||
looks like this: | looks like this: | |||
DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; | DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; | |||
c=simple; q=dns/txt; i=joe@football.example.com; | c=simple; q=dns/txt; i=joe@football.example.com; | |||
h=Received : From : To : Subject : Date : Message-ID; | h=Received : From : To : Subject : Date : Message-ID; | |||
bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=; | bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=; | |||
b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B | b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B | |||
7Tp1a1kEwZKdOtlTHlvF4JKg6RZUbN5urRJoaiD4RiSbf8D6fmMHt | 7Tp1a1kEwZKdOtlTHlvF4JKg6RZUbN5urRJoaiD4RiSbf8D6fmMHt | |||
skipping to change at page 62, line 31 | skipping to change at page 61, line 31 | |||
Hi. | Hi. | |||
We lost the game. Are you hungry yet? | We lost the game. Are you hungry yet? | |||
Joe. | Joe. | |||
The signing email server requires access to the private key | The signing email server requires access to the private key | |||
associated with the "brisbane" Selector to generate this signature. | associated with the "brisbane" Selector to generate this signature. | |||
A.3 The email signature is verified | A.3. The email signature is verified | |||
The signature is normally verified by an inbound SMTP server or | The signature is normally verified by an inbound SMTP server or | |||
possibly the final delivery agent. However, intervening MTAs can | possibly the final delivery agent. However, intervening MTAs can | |||
also perform this verification if they choose to do so. The | also perform this verification if they choose to do so. The | |||
verification process uses the domain "example.com" extracted from the | verification process uses the domain "example.com" extracted from the | |||
"d=" tag and the Selector "brisbane" from the "s=" tag in the "DKIM- | "d=" tag and the Selector "brisbane" from the "s=" tag in the "DKIM- | |||
Signature" header field to form the DNS DKIM query for: | Signature" header field to form the DNS DKIM query for: | |||
brisbane._domainkey.example.com | brisbane._domainkey.example.com | |||
skipping to change at page 64, line 5 | skipping to change at page 63, line 5 | |||
different operational scenarios. This Appendix discusses some common | different operational scenarios. This Appendix discusses some common | |||
examples. | examples. | |||
NOTE: Descriptions in this Appendix are for informational | NOTE: Descriptions in this Appendix are for informational | |||
purposes only. They describe various ways that DKIM can be used, | purposes only. They describe various ways that DKIM can be used, | |||
given particular constraints and needs. In no case are these | given particular constraints and needs. In no case are these | |||
examples intended to be taken as providing explanation or guidance | examples intended to be taken as providing explanation or guidance | |||
concerning DKIM specification details, when creating an | concerning DKIM specification details, when creating an | |||
implementation. | implementation. | |||
B.1 Alternate Submission Scenarios | B.1. Alternate Submission Scenarios | |||
In the most simple scenario, a user's MUA, MSA, and Internet | In the most simple scenario, a user's MUA, MSA, and Internet | |||
(boundary) MTA are all within the same administrative environment, | (boundary) MTA are all within the same administrative environment, | |||
using the same domain name. Therefore, all of the components | using the same domain name. Therefore, all of the components | |||
involved in submission and initial transfer are related. However it | involved in submission and initial transfer are related. However it | |||
is common for two or more of the components to be under independent | is common for two or more of the components to be under independent | |||
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) and granularity (the "g=" key tag) facilitate this kind of | |||
restricted authorization. Examples of these outsourced business | restricted authorization. Examples of these outsourced business | |||
functions are legitimate email marketing providers and corporate | functions are legitimate email marketing providers and corporate | |||
benefits providers. | benefits providers. | |||
skipping to change at page 65, line 11 | skipping to change at page 64, line 11 | |||
any time. | 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 | |||
PDAs demonstrate the need for using multiple keys per domain. | PDAs demonstrate the need for using multiple keys per domain. | |||
Suppose that John Doe wanted to be able to send messages using his | Suppose that John Doe wanted to be able to send messages using his | |||
corporate email address, jdoe@example.com, and his email device did | corporate email address, jdoe@example.com, and his email device did | |||
not have the ability to make a VPN connection to the corporate | not have the ability to make a VPN connection to the corporate | |||
network, either because the device is limited or because there are | network, either because the device is limited or because there are | |||
restrictions enforced by his Internet access provider. If the device | restrictions enforced by his Internet access provider. If the device | |||
was equipped with a private key registered for jdoe@example.com by | was equipped with a private key registered for jdoe@example.com by | |||
the administrator of the example.com domain, and appropriate software | the administrator of the example.com domain, and appropriate software | |||
to sign messages, John could sign the message on the device itself | to sign messages, John could sign the message on the device itself | |||
before transmission through the outgoing network of the access | before transmission through the outgoing network of the access | |||
service provider. | service provider. | |||
B.1.3 Roaming Users | B.1.3. Roaming Users | |||
Roaming users often find themselves in circumstances where it is | Roaming users often find themselves in circumstances where it is | |||
convenient or necessary to use an SMTP server other than their home | convenient or necessary to use an SMTP server other than their home | |||
server; examples are conferences and many hotels. In such | server; examples are conferences and many hotels. In such | |||
circumstances a signature that is added by the submission service | circumstances a signature that is added by the submission service | |||
will use an identity that is different from the user's home system. | will use an identity that is different from the user's home system. | |||
Ideally roaming users would connect back to their home server using | Ideally roaming users would connect back to their home server using | |||
either a VPN or a SUBMISSION server running with SMTP AUTHentication | either a VPN or a SUBMISSION server running with SMTP AUTHentication | |||
on port 587. If the signing can be performed on the roaming user's | on port 587. If the signing can be performed on the roaming user's | |||
laptop then they can sign before submission, although the risk of | laptop then they can sign before submission, although the risk of | |||
further modification is high. If neither of these are possible, | further modification is high. If neither of these are possible, | |||
these roaming users will not be able to send mail signed using their | these roaming users will not be able to send mail signed using their | |||
own domain key. | own domain key. | |||
B.1.4 Independent (Kiosk) Message Submission | B.1.4. Independent (Kiosk) Message Submission | |||
Stand-alone services, such as walk-up kiosks and web-based | Stand-alone services, such as walk-up kiosks and web-based | |||
information services, have no enduring email service relationship | information services, have no enduring email service relationship | |||
with the user, but the user occasionally requests that mail be sent | with the user, but the user occasionally requests that mail be sent | |||
on their behalf. For example, a website providing news often allows | on their behalf. For example, a website providing news often allows | |||
the reader to forward a copy of the article to a friend. This is | the reader to forward a copy of the article to a friend. This is | |||
typically done using the reader's own email address, to indicate who | typically done using the reader's own email address, to indicate who | |||
the author is. This is sometimes referred to as the "Evite problem", | the author is. This is sometimes referred to as the "Evite problem", | |||
named after the website of the same name that allows a user to send | named after the website of the same name that allows a user to send | |||
invitations to friends. | invitations to friends. | |||
skipping to change at page 66, line 23 | skipping to change at page 65, line 23 | |||
Receiving sites often wish to provide their end users with | Receiving sites often wish to provide their end users with | |||
information about mail that is mediated in this fashion. Although | information about mail that is mediated in this fashion. Although | |||
the real efficacy of different approaches is a subject for human | the real efficacy of different approaches is a subject for human | |||
factors usability research, one technique that is used is for the | factors usability research, one technique that is used is for the | |||
verifying system to rewrite the From header field, to indicate the | verifying system to rewrite the From header field, to indicate the | |||
address that was verified. For example: From: John Doe via | address that was verified. For example: From: John Doe via | |||
news@news-site.com <jdoe@example.com>. (Note that, such rewriting | news@news-site.com <jdoe@example.com>. (Note that, such rewriting | |||
will break a signature, unless it is done after the verification pass | will break a signature, unless it is done after the verification pass | |||
is complete.) | is complete.) | |||
B.2 Alternate Delivery Scenarios | B.2. Alternate Delivery Scenarios | |||
Email is often received at a mailbox that has an address different | Email is often received at a mailbox that has an address different | |||
from the one used during initial submission. In these cases, an | from the one used during initial submission. In these cases, an | |||
intermediary mechanism operates at the address originally used and it | intermediary mechanism operates at the address originally used and it | |||
then passes the message on to the final destination. This mediation | then passes the message on to the final destination. This mediation | |||
process presents some challenges for DKIM signatures. | process presents some challenges for DKIM signatures. | |||
B.2.1 Affinity Addresses | B.2.1. Affinity Addresses | |||
"Affinity addresses" allow a user to have an email address that | "Affinity addresses" allow a user to have an email address that | |||
remains stable, even as the user moves among different email | remains stable, even as the user moves among different email | |||
providers. They are typically associated with college alumni | providers. They are typically associated with college alumni | |||
associations, professional organizations, and recreational | associations, professional organizations, and recreational | |||
organizations with which they expect to have a long-term | organizations with which they expect to have a long-term | |||
relationship. These domains usually provide forwarding of incoming | relationship. These domains usually provide forwarding of incoming | |||
email, and they often have an associated Web application which | email, and they often have an associated Web application which | |||
authenticates the user and allows the forwarding address to be | authenticates the user and allows the forwarding address to be | |||
changed. However these services usually depend on the user's sending | changed. However these services usually depend on the user's sending | |||
skipping to change at page 67, line 13 | skipping to change at page 66, line 13 | |||
the public half in DNS for access by verifiers. | the public half in DNS for access by verifiers. | |||
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 to | In some cases a recipient is allowed to configure an email address 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 | |||
There is a wide range of behaviors in services that take delivery of | There is a wide range of behaviors in services that take delivery of | |||
a message and then resubmit it. A primary example is with mailing | a message and then resubmit it. A primary example is with mailing | |||
lists (collectively called "forwarders" below), ranging from those | lists (collectively called "forwarders" below), ranging from those | |||
which make no modification to the message itself, other than to add a | which make no modification to the message itself, other than to add a | |||
Received header field and change the envelope information, to those | Received header field and change the envelope information, to those | |||
which add header fields, change the Subject header field, add content | which add header fields, change the Subject header field, add content | |||
to the body (typically at the end), or reformat the body in some | to the body (typically at the end), or reformat the body in some | |||
manner. The simple ones produces messages that are quite similar to | manner. The simple ones produces messages that are quite similar to | |||
the automated alias services. More elaborate systems essentially | the automated alias services. More elaborate systems essentially | |||
skipping to change at page 70, line 38 | skipping to change at page 69, line 44 | |||
The aforementioned information is not intended to be exhaustive. The | The aforementioned information is not intended to be exhaustive. The | |||
MUA may choose to highlight, accentuate, hide, or otherwise display | MUA may choose to highlight, accentuate, hide, or otherwise display | |||
any other information that may, in the opinion of the MUA author, be | any other information that may, in the opinion of the MUA author, be | |||
deemed important to the end user. | deemed important to the end user. | |||
Appendix E. Acknowledgements | Appendix E. Acknowledgements | |||
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, | |||
Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, | Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, | |||
Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, | Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, | |||
Jutta Degener, Frank Ellermann, Patrik Faltstrom, Mark Fanto, Stephen | Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, | |||
Farrell, Duncan Findlay, Elliot Gillum, Olafur Gu[eth]mundsson, | Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur | |||
Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel Hathcock, Amir | Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, | |||
Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, Cullen Jennings, | Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig | |||
Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John | Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. | |||
Levine, Charles Lindsey, Simon Longsdale, David Margrave, Justin | Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon | |||
Mason, David Mayne, Steve Murphy, Russell Nelson, Dave Oran, Doug | Longsdale, David Margrave, Justin Mason, David Mayne, Steve Murphy, | |||
Otis, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake | Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer | |||
Ramsdell, Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, | Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, | |||
Dave Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, | Neil Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, | |||
Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan | the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, | |||
Wing for their valuable suggestions and constructive criticism. | Sam Weiler, and Dan Wing for their valuable suggestions and | |||
constructive criticism. | ||||
The DomainKeys specification was a primary source from which this | The DomainKeys specification was a primary source from which this | |||
specification has been derived. Further information about DomainKeys | specification has been derived. Further information about DomainKeys | |||
is at [RFC-DK]. | is at [RFC-DK]. | |||
Appendix F. Edit History | Appendix F. Edit History | |||
[[This section to be removed before publication.]] | [[This section to be removed before publication.]] | |||
F.1 Changes since -ietf-07 version | F.1. Changes since -ietf-08 version | |||
The following changes were made between draft-ietf-dkim-base-08 and | ||||
draft-ietf-dkim-base-09: | ||||
o Section 3.3.1, recommend use of an RSA exponent of 65537. | ||||
o Section 3.4.4, mention theoretical "ASCII Art" attack for relaxed | ||||
body canonicalization. | ||||
o Section 5.4.1 moved to 5.5 (with old 5.5 et seq. pushed down) to | ||||
talk more generally about use of l= and canonicalization | ||||
algorithms. | ||||
o Section 6.1.1, make an explicit mention that verifiers may reject | ||||
signatures from unlikely domains such as "com" and "co.uk". | ||||
o Section 6.3, try to clarify the wording about SMTP rejections. | ||||
o Section 7, change IANA registration requirement to be any RFC | ||||
having "IETF Consensus" (as defined in RFC2434), not necessarily | ||||
standards-track, as a result of overwhelming WG consensus. | ||||
o Informative References, add RFC 2434. | ||||
F.2. Changes since -ietf-07 version | ||||
The following changes were made between draft-ietf-dkim-base-07 and | The following changes were made between draft-ietf-dkim-base-07 and | |||
draft-ietf-dkim-base-08: | draft-ietf-dkim-base-08: | |||
o Drop reference to "trusted third party" in section 1; it was | o Drop reference to "trusted third party" in section 1; it was | |||
redundant with existing bullet points and created confusion. | redundant with existing bullet points and created confusion. | |||
o Drop the wording on re-using keys from normative to an operational | o Drop the wording on re-using keys from normative to an operational | |||
note. | note. | |||
skipping to change at page 72, line 25 | skipping to change at page 72, line 10 | |||
o Add sentence in section 8.11 to emphasize that signing existing | o Add sentence in section 8.11 to emphasize that signing existing | |||
DKIM-Signature header fields may result in incorrect validation | DKIM-Signature header fields may result in incorrect validation | |||
failures, as requested by Security Area review. | failures, as requested by Security Area review. | |||
o Added section 8.14 (RSA Attacks) based on DNS-dir review from | o Added section 8.14 (RSA Attacks) based on DNS-dir review from | |||
Olafur Gu[eth]mundsson. | Olafur Gu[eth]mundsson. | |||
o Added section 8.15 (Inappropriate Signing by Parent Domains). | o Added section 8.15 (Inappropriate Signing by Parent Domains). | |||
F.2 Changes since -ietf-06 version | F.3. Changes since -ietf-06 version | |||
The following changes were made between draft-ietf-dkim-base-06 and | The following changes were made between draft-ietf-dkim-base-06 and | |||
draft-ietf-dkim-base-07: | draft-ietf-dkim-base-07: | |||
o Added section 8.11 regarding header reordering. | o Added section 8.11 regarding header reordering. | |||
o Added informative note to section 3.3 regarding use of sha256. | o Added informative note to section 3.3 regarding use of sha256. | |||
o Added informative rationale to section 3.6.1, "p=", regarding key | o Added informative rationale to section 3.6.1, "p=", regarding key | |||
revocation. | revocation. | |||
skipping to change at page 73, line 5 | skipping to change at page 72, line 34 | |||
o Minor modification of the second informative note in section 6.1 | o Minor modification of the second informative note in section 6.1 | |||
regarding DoS attacks. | regarding DoS attacks. | |||
o Added explicit mention of v= to section 6.1.2, step 5. | o Added explicit mention of v= to section 6.1.2, step 5. | |||
o Updated paragraph 3 of section 8.4 regarding DNS attacks. | o Updated paragraph 3 of section 8.4 regarding DNS attacks. | |||
o Added section 7.9 (DKIM-Signature IANA Registry) per IANA request. | o Added section 7.9 (DKIM-Signature IANA Registry) per IANA request. | |||
F.3 Changes since -ietf-05 version | F.4. Changes since -ietf-05 version | |||
The following changes were made between draft-ietf-dkim-base-05 and | The following changes were made between draft-ietf-dkim-base-05 and | |||
draft-ietf-dkim-base-06: | draft-ietf-dkim-base-06: | |||
o Fix an error in an example in Appendix C. | o Fix an error in an example in Appendix C. | |||
o Substantial updates to Appendixes B and D. | o Substantial updates to Appendixes B and D. | |||
o Clarify ABNF for tag-value. | o Clarify ABNF for tag-value. | |||
skipping to change at page 73, line 29 | skipping to change at page 73, line 10 | |||
o Add normative reference to SHA1/SHA256 FIPS publication 180-2. | o Add normative reference to SHA1/SHA256 FIPS publication 180-2. | |||
o Several minor edits based on AD Review. | o Several minor edits based on AD Review. | |||
o Move discussion of not re-using a selector (i.e., changing the | o Move discussion of not re-using a selector (i.e., changing the | |||
public key for a single selector) from informational to normative. | public key for a single selector) from informational to normative. | |||
o Assorted wordsmithing based on external review. | o Assorted wordsmithing based on external review. | |||
F.4 Changes since -ietf-04 version | F.5. Changes since -ietf-04 version | |||
The following changes were made between draft-ietf-dkim-base-04 and | The following changes were made between draft-ietf-dkim-base-04 and | |||
draft-ietf-dkim-base-05: | draft-ietf-dkim-base-05: | |||
o Clarified definition of "plain text" in section 3.2 (issue 1316). | o Clarified definition of "plain text" in section 3.2 (issue 1316). | |||
o Added some clarification about multiple listings of non-existent | o Added some clarification about multiple listings of non-existent | |||
header field names in h= in section 5.4 (issue 1316). | header field names in h= in section 5.4 (issue 1316). | |||
o Finished filling out IANA registries in section 7 (issue 1320). | o Finished filling out IANA registries in section 7 (issue 1320). | |||
skipping to change at page 74, line 5 | skipping to change at page 73, line 32 | |||
o Clarified handling of bare CR and LF in section 5.3 (issue 1326). | o Clarified handling of bare CR and LF in section 5.3 (issue 1326). | |||
o Listed the required tags in section 6.1.1 as an informational note | o Listed the required tags in section 6.1.1 as an informational note | |||
(issue 1330). | (issue 1330). | |||
o Changed IDNA reference from 3492 to 3490 (issue 1331). | o Changed IDNA reference from 3492 to 3490 (issue 1331). | |||
o Changed the reference for WSP to 4234; changed the definition of | o Changed the reference for WSP to 4234; changed the definition of | |||
SWSP to exclude bare CR and LF (issue 1332). | SWSP to exclude bare CR and LF (issue 1332). | |||
F.5 Changes since -ietf-03 version | F.6. Changes since -ietf-03 version | |||
The following changes were made between draft-ietf-dkim-base-03 and | The following changes were made between draft-ietf-dkim-base-03 and | |||
draft-ietf-dkim-base-04: | draft-ietf-dkim-base-04: | |||
o Re-worded Abstract to avoid use of "prove" and "non-repudiation". | o Re-worded Abstract to avoid use of "prove" and "non-repudiation". | |||
o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. | o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. | |||
o Capitalize Selector throughout. | o Capitalize Selector throughout. | |||
skipping to change at page 75, line 4 | skipping to change at page 74, line 32 | |||
o Add several examples; update some others. | o Add several examples; update some others. | |||
o Considerable minor editorial updating to clarify language, delete | o Considerable minor editorial updating to clarify language, delete | |||
redundant text, fix spelling errors, etc. | redundant text, fix spelling errors, etc. | |||
Still to be resolved: | Still to be resolved: | |||
o How does "simple" body canonicalization interact with BINARYMIME | o How does "simple" body canonicalization interact with BINARYMIME | |||
data? | data? | |||
o Deal with "relaxed" body canonicalizations, especially in regard | o Deal with "relaxed" body canonicalizations, especially in regard | |||
to bare CRs and NLs. | to bare CRs and NLs. | |||
o How to handle "*" in g= dot-atom-text (which allows "*" as a | o How to handle "*" in g= dot-atom-text (which allows "*" as a | |||
literal character). | literal character). | |||
o The IANA Considerations need to be completed and cleaned up. | o The IANA Considerations need to be completed and cleaned up. | |||
F.6 Changes since -ietf-02 version | F.7. Changes since -ietf-02 version | |||
The following changes were made between draft-ietf-dkim-base-02 and | The following changes were made between draft-ietf-dkim-base-02 and | |||
draft-ietf-dkim-base-03: | draft-ietf-dkim-base-03: | |||
o Section 5.2: changed key expiration text to be informational; | o Section 5.2: changed key expiration text to be informational; | |||
drop "seven day" wording in favor of something vaguer. | drop "seven day" wording in favor of something vaguer. | |||
o Don't indicate that the "i=" tag value should be passed to the key | o Don't indicate that the "i=" tag value should be passed to the key | |||
lookup service; this can be added as an extension if required. | lookup service; this can be added as an extension if required. | |||
skipping to change at page 76, line 13 | skipping to change at page 75, line 42 | |||
may contain the content. | may contain the content. | |||
o Use dkim-quoted-printable as the encoding used in z= rather than | o Use dkim-quoted-printable as the encoding used in z= rather than | |||
referring to RFC2045, since they are different. | referring to RFC2045, since they are different. | |||
o Rewrite description of g= tag in the key record. | o Rewrite description of g= tag in the key record. | |||
o Deleted use of Domain in ABNF, which permits address-literals; | o Deleted use of Domain in ABNF, which permits address-literals; | |||
define domain-name to act in stead. | define domain-name to act in stead. | |||
F.7 Changes since -ietf-01 version | F.8. Changes since -ietf-01 version | |||
The following changes were made between draft-ietf-dkim-base-01 and | The following changes were made between draft-ietf-dkim-base-01 and | |||
draft-ietf-dkim-base-02: | draft-ietf-dkim-base-02: | |||
o Change wording on "x=" tag in DKIM-Signature header field | o Change wording on "x=" tag in DKIM-Signature header field | |||
regarding verifier handling of expired signatures from MUST to MAY | regarding verifier handling of expired signatures from MUST to MAY | |||
(per 20 April Jabber session). Also, make it clear that received | (per 20 April Jabber session). Also, make it clear that received | |||
time is to be preferred over current time if reliably available. | time is to be preferred over current time if reliably available. | |||
o Several changes to limit wording that would intrude into verifier | o Several changes to limit wording that would intrude into verifier | |||
skipping to change at page 76, line 44 | skipping to change at page 76, line 26 | |||
o Change "q=dns" query access method to "q=dnstxt" to emphasize the | o Change "q=dns" query access method to "q=dnstxt" to emphasize the | |||
use of the TXT record. The expectation is that a later extension | use of the TXT record. The expectation is that a later extension | |||
will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 | will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 | |||
May Jabber session.) | May Jabber session.) | |||
o Several typos fixed, including removing a paragraph that implied | o Several typos fixed, including removing a paragraph that implied | |||
that the DKIM-Signature header field should be hashed with the | that the DKIM-Signature header field should be hashed with the | |||
body (it should not). | body (it should not). | |||
F.8 Changes since -ietf-00 version | F.9. Changes since -ietf-00 version | |||
The following changes were made between draft-ietf-dkim-base-00 and | The following changes were made between draft-ietf-dkim-base-00 and | |||
draft-ietf-dkim-base-01: | draft-ietf-dkim-base-01: | |||
o Added section 8.9 (Information Leakage). | o Added section 8.9 (Information Leakage). | |||
o Replace section 4 (Multiple Signatures) with much less vague text. | o Replace section 4 (Multiple Signatures) with much less vague text. | |||
o Fixed ABNF for base64string. | o Fixed ABNF for base64string. | |||
skipping to change at page 77, line 22 | skipping to change at page 77, line 5 | |||
o Changed signing algorithm to use separate hash of the body of the | o Changed signing algorithm to use separate hash of the body of the | |||
message; this is represented as the "bh=" tag in the DKIM- | message; this is represented as the "bh=" tag in the DKIM- | |||
Signature header field. | Signature header field. | |||
o Changed "z=" tag so that it need not have the same header field | o Changed "z=" tag so that it need not have the same header field | |||
names as the "h=" tag. | names as the "h=" tag. | |||
o Significant wordsmithing. | o Significant wordsmithing. | |||
F.9 Changes since -allman-01 version | F.10. Changes since -allman-01 version | |||
The following changes were made between draft-allman-dkim-base-01 and | The following changes were made between draft-allman-dkim-base-01 and | |||
draft-ietf-dkim-base-00: | draft-ietf-dkim-base-00: | |||
o Remove references to Sender Signing Policy document. Such | o Remove references to Sender Signing Policy document. Such | |||
consideration is implicitly included in Section 6.3. | consideration is implicitly included in Section 6.3. | |||
o Added ABNF for all tags. | o Added ABNF for all tags. | |||
o Updated references (still includes some references to expired | o Updated references (still includes some references to expired | |||
drafts, notably ID-AUTH-RES. | drafts, notably ID-AUTH-RES. | |||
o Significant wordsmithing. | o Significant wordsmithing. | |||
F.10 Changes since -allman-00 version | F.11. Changes since -allman-00 version | |||
The following changes were made between draft-allman-dkim-base-00 and | The following changes were made between draft-allman-dkim-base-00 and | |||
draft-allman-dkim-base-01: | draft-allman-dkim-base-01: | |||
o Changed "c=" tag to separate out header from body | o Changed "c=" tag to separate out header from body | |||
canonicalization. | canonicalization. | |||
o Eliminated "nowsp" canonicalization in favor of "relaxed", which | o Eliminated "nowsp" canonicalization in favor of "relaxed", which | |||
is somewhat less relaxed (but more secure) than "nowsp". | is somewhat less relaxed (but more secure) than "nowsp". | |||
o Moved the (empty) Compliance section to the Sender Signing Policy | o Moved the (empty) Compliance section to the Sender Signing Policy | |||
document. | document. | |||
o Added several IANA Considerations. | o Added several IANA Considerations. | |||
o Fixed a number of grammar and formatting errors. | o Fixed a number of grammar and formatting errors. | |||
Intellectual Property Statement | Authors' Addresses | |||
Eric Allman | ||||
Sendmail, Inc. | ||||
6425 Christie Ave, Suite 400 | ||||
Emeryville, CA 94608 | ||||
USA | ||||
Phone: +1 510 594 5501 | ||||
Email: eric+dkim@sendmail.org | ||||
URI: | ||||
Jon Callas | ||||
PGP Corporation | ||||
3460 West Bayshore | ||||
Palo Alto, CA 94303 | ||||
USA | ||||
Phone: +1 650 319 9016 | ||||
Email: jon@pgp.com | ||||
Mark Delany | ||||
Yahoo! Inc | ||||
701 First Avenue | ||||
Sunnyvale, CA 95087 | ||||
USA | ||||
Phone: +1 408 349 6831 | ||||
Email: markd+dkim@yahoo-inc.com | ||||
URI: | ||||
Miles Libbey | ||||
Yahoo! Inc | ||||
701 First Avenue | ||||
Sunnyvale, CA 95087 | ||||
USA | ||||
Email: mlibbeymail-mailsig@yahoo.com | ||||
URI: | ||||
Jim Fenton | ||||
Cisco Systems, Inc. | ||||
MS SJ-24/2 | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134-1706 | ||||
USA | ||||
Phone: +1 408 526 5914 | ||||
Email: fenton@cisco.com | ||||
URI: | ||||
Michael Thomas | ||||
Cisco Systems, Inc. | ||||
MS SJ-9/2 | ||||
170 W. Tasman Drive | ||||
San Jose, CA 95134-1706 | ||||
Phone: +1 408 525 5386 | ||||
Email: mat@cisco.com | ||||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2007). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 79, line 29 | skipping to change at page 80, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
The IETF has been notified of intellectual property rights claimed in | ||||
regard to some or all of the specification contained in this | ||||
document. For more information consult the online list of claimed | ||||
rights. | ||||
Disclaimer of Validity | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | ||||
Copyright (C) The Internet Society (2007). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 122 change blocks. | ||||
309 lines changed or deleted | 380 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |