draft-ietf-dkim-rfc4871bis-03.txt   draft-ietf-dkim-rfc4871bis-04.txt 
Network Working Group D. Crocker, Ed. Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871 (if approved) T. Hansen, Ed. Obsoletes: 4871 (if approved) T. Hansen, Ed.
Intended status: Standards Track AT&T Laboratories Intended status: Standards Track AT&T Laboratories
Expires: August 20, 2011 M. Kucherawy, Ed. Expires: September 29, 2011 M. Kucherawy, Ed.
Cloudmark Cloudmark
February 16, 2011 March 28, 2011
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-03 draft-ietf-dkim-rfc4871bis-04
Abstract Abstract
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the responsibility for a message by associating the domain with the
message. This can be an author's organization, an operational relay message. This can be an author's organization, an operational relay
or one of their agents. DKIM separates the question of the identity or one of their agents. DKIM separates the question of the identity
of the signer of the message from the purported author of the of the signer of the message from the purported author of the
message. Assertion of responsibility is validated through a message. Assertion of responsibility is validated through a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6
1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 6 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9
2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12
3.3. Signing and Verification Algorithms . . . . . . . . . . . 12 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19
3.6. Key Management and Representation . . . . . . . . . . . . 27 3.6. Key Management and Representation . . . . . . . . . . . . 28
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 34 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 34 3.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 35
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 35 3.10. Relationship between SDID and AUID . . . . . . . . . . . . 36
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 35 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1. Determine Whether the Email Should Be Signed and by 5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2. Select a Private Key and Corresponding Selector 5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 38 Information . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Normalize the Message to Prevent Transport Conversions . . 40
5.3. Normalize the Message to Prevent Transport Conversions . . 39 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 39 5.5. Recommended Signature Content . . . . . . . . . . . . . . 43
5.5. Recommended Signature Content . . . . . . . . . . . . . . 41 5.6. Compute the Message Hash and Signature . . . . . . . . . . 44
5.6. Compute the Message Hash and Signature . . . . . . . . . . 43 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 43 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44 6.1. Extract Signatures from the Message . . . . . . . . . . . 46
6.1. Extract Signatures from the Message . . . . . . . . . . . 45 6.2. Communicate Verification Results . . . . . . . . . . . . . 51
6.2. Communicate Verification Results . . . . . . . . . . . . . 50 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 52 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 53 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 54 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 59 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 59 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 60 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62
8.14. Attacks Involving Addition of Header Fields . . . . . . . 61 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1. Normative References . . . . . . . . . . . . . . . . . . . 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64
9.2. Informative References . . . . . . . . . . . . . . . . . . 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66
A.3. The Email Signature is Verified . . . . . . . . . . . . . 65 A.3. The Email Signature is Verified . . . . . . . . . . . . . 67
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 72 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by organization to claim some responsibility for a message by
associating a domain name [RFC1034] with the message [RFC5322]. This associating a domain name [RFC1034] with the message [RFC5322], which
can be an author's organization, an operational relay or one of their they are authorized to use. This can be an author's organization, an
agents. Assertion of responsibility is validated through a operational relay or one of their agents. Assertion of
cryptographic signature and querying the signer's domain directly to responsibility is validated through a cryptographic signature and
retrieve the appropriate public key. Message transit from author to querying the signer's domain directly to retrieve the appropriate
recipient is through relays that typically make no substantive change public key. Message transit from author to recipient is through
to the message content and thus preserve the DKIM signature. A relays that typically make no substantive change to the message
message can contain multiple signatures, from the same or different content and thus preserve the DKIM signature. A message can contain
organizations involved with the message. multiple signatures, from the same or different organizations
involved with the message.
The approach taken by DKIM differs from previous approaches to The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that:
o the message signature is written as a message header field so that o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent) neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the software is confused by signature-related content appearing in the
message body; message body;
skipping to change at page 6, line 40 skipping to change at page 7, line 40
Elements in the mail system that verify signatures are referred to as Elements in the mail system that verify signatures are referred to as
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.
In most cases it is expected that verifiers will be close to an end In most cases it is expected that verifiers will be close to an end
user (reader) of the message or some consuming agent such as a user (reader) of the message or some consuming agent such as a
mailing list exploder. mailing list exploder.
2.3. Identity 2.3. Identity
A person, role, or organization. In the context of DKIM, examples A person, role, or organization. In the context of DKIM, examples
include author, author's organization, an ISP along the handling include the author, the author's organization, an ISP along the
path, an independent trust assessment service, and a mailing list handling path, an independent trust assessment service, and a mailing
operator. list operator.
2.4. Identifier 2.4. Identifier
A label that refers to an identity. A label that refers to an identity.
2.5. Signing Domain Identifier (SDID) 2.5. Signing Domain Identifier (SDID)
A single domain name that is the mandatory payload output of DKIM and A single domain name that is the mandatory payload output of DKIM and
that refers to the identity claiming responsibility for introduction that refers to the identity claiming responsibility for introduction
of a message into the mail stream. For DKIM processing, the name has of a message into the mail stream. For DKIM processing, the name has
skipping to change at page 8, line 13 skipping to change at page 9, line 13
the exclusion of obs-FWS. the exclusion of obs-FWS.
2.9. Common ABNF Tokens 2.9. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document: The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ] [ [FWS] "=" [ [FWS] "=" ] ]
hdr-name = field-name hdr-name = field-name
qp-hdr-value = dkim-quoted-printable ; with "|" encoded qp-hdr-value = dkim-quoted-printable ; with "|" encoded
2.10. Imported ABNF Tokens 2.10. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive. RFCs should be considered definitive.
The following tokens are imported from [RFC5321]: The following tokens are imported from [RFC5321]:
o "Local-part" (implementation warning: this permits quoted strings) o "Local-part" (implementation warning: this permits quoted strings)
skipping to change at page 33, line 26 skipping to change at page 34, line 26
beginning with a "." to avoid confusion with the SMTP end-of-message beginning with a "." to avoid confusion with the SMTP end-of-message
marker, as specified in [RFC5321]). marker, as specified in [RFC5321]).
With the exception of the canonicalization procedure described in With the exception of the canonicalization procedure described in
Section 3.4, the DKIM signing process treats the body of messages as Section 3.4, the DKIM signing process treats the body of messages as
simply a string of octets. DKIM messages MAY be either in plain-text simply a string of octets. DKIM messages MAY be either in plain-text
or in MIME format; no special treatment is afforded to MIME content. or in MIME format; no special treatment is afforded to MIME content.
Message attachments in MIME format MUST be included in the content Message attachments in MIME format MUST be included in the content
that is signed. that is signed.
More formally, the ABNF of the algorithm for the signature is as More formally, pseudo-code for the signature algorithm is:
follows: body-hash = hash-alg (canon-body, l-param)
body-hash = bh-hash-alg (canon-body, l-param) data-hash = hash-alg (h-headers, D-SIG, content-hash)
data-hash = a-hash-alg (h-headers, D-SIG, content-hash)
signature = sig-alg (d-domain, selector, data-hash) signature = sig-alg (d-domain, selector, data-hash)
where: where:
body-hash: is the output of a function to hash the Body. body-hash: is the output from hashing the body, using hash-alg.
bh-hash-alg: is the hashing algorithm specified in the "bh" hash-alg: is the hashing algorithm specified in the "a"
parameter. parameter.
canon-body: is a canonicalized representation of the body. canon-body: is a canonicalized representation of the body,
produced by using the body algorithm specified in the "c"
parameter, as defined in Section 3.4 and excluding the
DKIM-Signature field.
l-param: is the value of the l= length parameter. l-param: is the length-of-body value of the "l" parameter.
data-hash: is the output from hashing the header, the data-hash: is the output from using the hash-alg algorithm, to
DOSETA-Signature header, and the Content hash. hash the header including the DKIM-Signature header, and the
body hash.
a-hash-alg: is the hash algorithm specified by the "a=" tag,
h-headers: is the list of headers to be signed, as specified in h-headers: is the list of headers to be signed, as specified in
the h= parameter. the "h" parameter.
D-SIG: is the canonicalized DOSETA-Signature field sans the
signature value itself.
canon-body: is the canonicalized Body as defined in Section 3.4 D-SIG: is the canonicalized DKIM-Signature field without the
(excluding the DKIM-Signature field). signature value portion of the parameter, itself; that is, an
empty parameter value.
signature: is the signature value produced by the signing signature: is the signature value produced by the signing
algorithm. algorithm.
sig-alg: is the signature algorithm specified by the "a=" tag, sig-alg: is the signature algorithm specified by the "a"
parameter.
d-domain: is the domain name specified in the d= parameter. d-domain: is the domain name specified in the "d" parameter.
selector: is the value of the s= selector parameter selector: is the selector value specified in the "s" parameter.
NOTE: Many digital signature APIs provide both hashing and NOTE: Many digital signature APIs provide both hashing and
application of the RSA private key using a single "sign()" application of the RSA private key using a single "sign()"
primitive. When using such an API, the last two steps in the primitive. When using such an API, the last two steps in the
algorithm would probably be combined into a single call that would algorithm would probably be combined into a single call that would
perform both the "a-hash-alg" and the "sig-alg". perform both the "a-hash-alg" and the "sig-alg".
3.8. Signing by Parent Domains 3.8. Input Requirements
DKIM's design is predicated on valid input. Therefore, signers and
verifiers SHOULD take reasonable steps to ensure that the messages
they are processing are valid according to [RFC5322], [RFC2045], and
any other relevant message format standards. See Section 8.15 for
additional discussion and references.
3.9. Signing by Parent Domains
In some circumstances, it is desirable for a domain to apply a In some circumstances, it is desirable for a domain to apply a
signature on behalf of any of its subdomains without the need to signature on behalf of any of its subdomains without the need to
maintain separate selectors (key records) in each subdomain. By maintain separate selectors (key records) in each subdomain. By
default, private keys corresponding to key records can be used to default, private keys corresponding to key records can be used to
sign messages for any subdomain of the domain in which they reside; sign messages for any subdomain of the domain in which they reside;
for example, a key record for the domain example.com can be used to for example, a key record for the domain example.com can be used to
verify messages where the AUID ("i=" tag of the signature) is verify messages where the AUID ("i=" tag of the signature) is
sub.example.com, or even sub1.sub2.example.com. In order to limit sub.example.com, or even sub1.sub2.example.com. In order to limit
the capability of such keys when this is not intended, the "s" flag the capability of such keys when this is not intended, the "s" flag
MAY be set in the "t=" tag of the key record, to constrain the MAY be set in the "t=" tag of the key record, to constrain the
validity of the domain of the AUID. If the referenced key record validity of the domain of the AUID. If the referenced key record
contains the "s" flag as part of the "t=" tag, the domain of the AUID contains the "s" flag as part of the "t=" tag, the domain of the AUID
("i=" flag) MUST be the same as that of the SDID (d=) domain. If ("i=" flag) MUST be the same as that of the SDID (d=) domain. If
this flag is absent, the domain of the AUID MUST be the same as, or a this flag is absent, the domain of the AUID MUST be the same as, or a
subdomain of, the SDID. subdomain of, the SDID.
3.9. Relationship between SDID and AUID 3.10. Relationship between SDID and AUID
DKIM's primary task is to communicate from the Signer to a recipient- DKIM's primary task is to communicate from the Signer to a recipient-
side Identity Assessor a single Signing Domain Identifier (SDID) that side Identity Assessor a single Signing Domain Identifier (SDID) that
refers to a responsible identity. DKIM MAY optionally provide a refers to a responsible identity. DKIM MAY optionally provide a
single responsible Agent or User Identifier (AUID). single responsible Agent or User Identifier (AUID).
Hence, DKIM's mandatory output to a receive-side Identity Assessor is Hence, DKIM's mandatory output to a receive-side Identity Assessor is
a single domain name. Within the scope of its use as DKIM output, a single domain name. Within the scope of its use as DKIM output,
the name has only basic domain name semantics; any possible owner- the name has only basic domain name semantics; any possible owner-
specific semantics are outside the scope of DKIM. That is, within specific semantics are outside the scope of DKIM. That is, within
skipping to change at page 39, line 29 skipping to change at page 40, line 38
to modification during transit, notably conversion to 7-bit form. to modification during transit, notably conversion to 7-bit form.
Such conversions will break DKIM signatures. In order to minimize Such conversions will break DKIM signatures. In order to minimize
the chances of such breakage, signers SHOULD convert the message to a the chances of such breakage, signers SHOULD convert the message to a
suitable MIME content transfer encoding such as quoted-printable or suitable MIME content transfer encoding such as quoted-printable or
base64 as described in [RFC2045] before signing. Such conversion is base64 as described in [RFC2045] before signing. Such conversion is
outside the scope of DKIM; the actual message SHOULD be converted to outside the scope of DKIM; the actual message SHOULD be converted to
7-bit MIME by an MUA or MSA prior to presentation to the DKIM 7-bit MIME by an MUA or MSA prior to presentation to the DKIM
algorithm. algorithm.
Similarly, a message that is not compliant with RFC5322, RFC2045 and Similarly, a message that is not compliant with RFC5322, RFC2045 and
RFC2047, can be subject to attempts by intermediaries to correct or RFC2047 can be subject to attempts by intermediaries to correct or
interpret such content. See Section 8 of [RFC4409] for examples of interpret such content. See Section 8 of [RFC4409] for examples of
changes that are commonly made. Such "corrections" may break DKIM changes that are commonly made. Such "corrections" may break DKIM
signatures or have other undesirable effects. Therefore, a verifier signatures or have other undesirable effects. Therefore, a verifier
SHOULD NOT validate a message that is not compliant with those SHOULD NOT validate a message that is not compliant with those
specifications. specifications.
If the message is submitted to the signer with any local encoding If the message is submitted to the signer with any local encoding
that will be modified before transmission, that modification to that will be modified before transmission, that modification to
canonical [RFC5322] form MUST be done before signing. In particular, canonical [RFC5322] form MUST be done before signing. In particular,
bare CR or LF characters (used by some systems as a local line bare CR or LF characters (used by some systems as a local line
skipping to change at page 48, line 5 skipping to change at page 49, line 6
The public key for a signature is needed to complete the verification The public key for a signature is needed to complete the verification
process. The process of retrieving the public key depends on the process. The process of retrieving the public key depends on the
query type as defined by the "q=" tag in the DKIM-Signature header query type as defined by the "q=" tag in the DKIM-Signature header
field. Obviously, a public key need only be retrieved if the process field. Obviously, a public key need only be retrieved if the process
of extracting the signature information is completely successful. of extracting the signature information is completely successful.
Details of key management and representation are described in Details of key management and representation are described in
Section 3.6. The verifier MUST validate the key record and MUST Section 3.6. The verifier MUST validate the key record and MUST
ignore any public key records that are malformed. ignore any public key records that are malformed.
NOTE: The use of wildcard TXT records in the DNS will produce a NOTE: The use of a wildcard TXT record that covers a queried DKIM
response to a DKIM query that is unlikely to be valid DKIM key domain name will produce a response to a DKIM query that is
record. This problem applies to many other types of queries, and unlikely to be valid DKIM key record. This problem is not
client software that processes DNS responses needs to take this specific to DKIM and applies to many other types of queries.
Client software that processes DNS responses needs to take this
problem into account. problem into account.
When validating a message, a verifier MUST perform the following When validating a message, a verifier MUST perform the following
steps in a manner that is semantically the same as performing them in steps in a manner that is semantically the same as performing them in
the order indicated -- in some cases the implementation may the order indicated -- in some cases the implementation may
parallelize or reorder these steps, as long as the semantics remain parallelize or reorder these steps, as long as the semantics remain
unchanged: unchanged:
1. Retrieve the public key as described in Section 3.6 using the 1. Retrieve the public key as described in Section 3.6 using the
algorithm in the "q=" tag, the domain from the "d=" tag, and the algorithm in the "q=" tag, the domain from the "d=" tag, and the
skipping to change at page 61, line 7 skipping to change at page 62, line 7
by refusing to verify signatures that reference selectors with public by refusing to verify signatures that reference selectors with public
keys having unreasonable exponents. keys having unreasonable exponents.
In general, an attacker might try to overwhelm a verifier by flooding In general, an attacker might try to overwhelm a verifier by flooding
it with messages requiring verification. This is similar to other it with messages requiring verification. This is similar to other
MTA denial-of-service attacks and should be dealt with in a similar MTA denial-of-service attacks and should be dealt with in a similar
fashion. fashion.
8.13. Inappropriate Signing by Parent Domains 8.13. Inappropriate Signing by Parent Domains
The trust relationship described in Section 3.8 could conceivably be The trust relationship described in Section 3.9 could conceivably be
used by a parent domain to sign messages with identities in a used by a parent domain to sign messages with identities in a
subdomain not administratively related to the parent. For example, subdomain not administratively related to the parent. For example,
the ".com" registry could create messages with signatures using an the ".com" registry could create messages with signatures using an
"i=" value in the example.com domain. There is no general solution "i=" value in the example.com domain. There is no general solution
to this problem, since the administrative cut could occur anywhere in to this problem, since the administrative cut could occur anywhere in
the domain name. For example, in the domain "example.podunk.ca.us" the domain name. For example, in the domain "example.podunk.ca.us"
there are three administrative cuts (podunk.ca.us, ca.us, and us), there are three administrative cuts (podunk.ca.us, ca.us, and us),
any of which could create messages with an identity in the full any of which could create messages with an identity in the full
domain. domain.
skipping to change at page 62, line 11 skipping to change at page 63, line 11
To resist this specific attack the signed header field list can To resist this specific attack the signed header field list can
include an additional reference for each field that was present at include an additional reference for each field that was present at
signing. For example, a proper message with one From: field could be signing. For example, a proper message with one From: field could be
signed using "h=From:From:..." Due to the way header fields are signed using "h=From:From:..." Due to the way header fields are
canonicalized for input to the hash function, the extra field canonicalized for input to the hash function, the extra field
references will prevent instances of the cited fields from being references will prevent instances of the cited fields from being
added after signing, as doing so would render the signature invalid. added after signing, as doing so would render the signature invalid.
The From: field is used above to illustrate this issue, but it is The From: field is used above to illustrate this issue, but it is
only one of > several fields that Section 3.6 of [RFC5322] constrains only one of several fields that Section 3.6 of [RFC5322] constrains
in this way. In reality any agent that forgives malformations, or is in this way. In reality any agent that forgives malformations, or is
careless about identifying which parts of a message were careless about identifying which parts of a message were
authenticated, is open to exploitation. authenticated, is open to exploitation.
8.15. Malformed Inputs
DKIM allows additional header fields to be added to a signed message
without breaking the signature. This tolerance can be abused, for
example in a replay attack. The attack is accomplished by creating
additional instances of header fields to an already signed message,
without breaking the signature. These then might be displayed to the
end user or are used as filtering input. Salient fields could
include From: and Subject:,
The resulting message violates section 3.6 of [RFC5322]. The way
such input will be handled and displayed by an MUA is unpredictable,
but in some cases it might display the newly added header fields
rather than those that are part of the originally signed message
alongside some "valid DKIM signature" annotation. This might allow
an attacker to replay a previously sent, signed message with a
different Subject:, From: or To: field.
Because of this, DKIM implementers are strongly advised to reject or
treat as suspicious any message that has multiple copies of header
fields that are disallowed by section 3.6 of [MAIL], particularly
those that are typically displayed to end users (From:, To:, Cc:,
Subject:). A signing module could return an error rather than
generate a signature; a verifying module might return a syntax error
code or arrange not to return a positive result even if the signature
technically validates.
Senders concerned that their messages might be particularly
vulnerable to this sort of attack and who do not wish to rely on
receiver filtering of invalid messages can ensure that adding
additional header fields will break the DKIM signature by including
two copies of the header fields about which they are concerned in the
signature (e.g. "h= ... from:from:to:to:subject:subject ...). See
Sections 3.5 and 5.4 for further discussion of this mechanism.
Specific validity rules for all known header fields can be gleaned
from the IANA "Permanent Header Field Registry" and the reference
documents it identifies.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-180-2-2002] [FIPS-180-2-2002]
U.S. Department of Commerce, "Secure Hash Standard", FIPS U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-2, August 2002. PUB 180-2, August 2002.
[ITU-X660-1997] [ITU-X660-1997]
"Information Technology - ASN.1 encoding rules: "Information Technology - ASN.1 encoding rules:
 End of changes. 29 change blocks. 
128 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/