draft-ietf-dkim-base-09.txt   draft-ietf-dkim-base-10.txt 
DKIM E. Allman DKIM E. Allman
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Intended status: Standards Track J. Callas Intended status: Standards Track J. Callas
Expires: August 15, 2007 PGP Corporation Expires: August 19, 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.
February 11, 2007 February 15, 2007
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-base-09 draft-ietf-dkim-base-10
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 August 15, 2007. This Internet-Draft will expire on August 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . 35 Information . . . . . . . . . . . . . . . . . . . . . . . 36
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 . . . . . . . . . . . 36 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 37
5.5. Recommended Signature Content . . . . . . . . . . . . . . 39 5.5. Recommended Signature Content . . . . . . . . . . . . . . 39
5.6. Compute the Message Hash and Signature . . . . . . . . . . 40 5.6. Compute the Message Hash and Signature . . . . . . . . . . 40
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 41 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 41
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 41 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 41
6.1. Extract Signatures from the Message . . . . . . . . . . . 42 6.1. Extract Signatures from the Message . . . . . . . . . . . 42
6.2. Communicate Verification Results . . . . . . . . . . . . . 47 6.2. Communicate Verification Results . . . . . . . . . . . . . 47
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 48 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 49 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 49
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 50 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 50
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 50 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 50
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 51 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 51
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 51 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 52
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 52 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 52
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 52 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 53
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 53 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 53
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 53 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 54
8. Security Considerations . . . . . . . . . . . . . . . . . . . 53 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 53 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 54
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 54 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 55
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 55 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 56
8.4. Attacks Against DNS . . . . . . . . . . . . . . . . . . . 55 8.4. Attacks Against DNS . . . . . . . . . . . . . . . . . . . 56
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 56 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 57
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 56 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 57
8.7. Intentionally malformed Key Records . . . . . . . . . . . 57 8.7. Intentionally malformed Key Records . . . . . . . . . . . 57
8.8. Intentionally Malformed DKIM-Signature header fields . . . 57 8.8. Intentionally Malformed DKIM-Signature header fields . . . 58
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 57 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 58
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 57 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 58
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 57 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 58
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 57 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 58
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 58 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 58
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References . . . . . . . . . . . . . . . . . . . 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 59
9.2. Informative References . . . . . . . . . . . . . . . . . . 59 9.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 61
A.1. The user composes an email . . . . . . . . . . . . . . . . 60 A.1. The user composes an email . . . . . . . . . . . . . . . . 61
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 60 A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61 A.3. The email signature is verified . . . . . . . . . . . . . 62
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 63
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 64
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 66
Appendix C. Creating a public key (INFORMATIVE) . . . . . . . . . 67 Appendix C. Creating a public key (INFORMATIVE) . . . . . . . . . 68
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 69 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 70
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 70
Appendix F. Edit History . . . . . . . . . . . . . . . . . . . . 70 Appendix F. Edit History . . . . . . . . . . . . . . . . . . . . 71
F.1. Changes since -ietf-08 version . . . . . . . . . . . . . . 70 F.1. Changes since -ietf-09 version . . . . . . . . . . . . . . 71
F.2. Changes since -ietf-07 version . . . . . . . . . . . . . . 70 F.2. Changes since -ietf-08 version . . . . . . . . . . . . . . 71
F.3. Changes since -ietf-06 version . . . . . . . . . . . . . . 72 F.3. Changes since -ietf-07 version . . . . . . . . . . . . . . 72
F.4. Changes since -ietf-05 version . . . . . . . . . . . . . . 72 F.4. Changes since -ietf-06 version . . . . . . . . . . . . . . 73
F.5. Changes since -ietf-04 version . . . . . . . . . . . . . . 73 F.5. Changes since -ietf-05 version . . . . . . . . . . . . . . 74
F.6. Changes since -ietf-03 version . . . . . . . . . . . . . . 73 F.6. Changes since -ietf-04 version . . . . . . . . . . . . . . 74
F.7. Changes since -ietf-02 version . . . . . . . . . . . . . . 74 F.7. Changes since -ietf-03 version . . . . . . . . . . . . . . 75
F.8. Changes since -ietf-01 version . . . . . . . . . . . . . . 75 F.8. Changes since -ietf-02 version . . . . . . . . . . . . . . 76
F.9. Changes since -ietf-00 version . . . . . . . . . . . . . . 76 F.9. Changes since -ietf-01 version . . . . . . . . . . . . . . 77
F.10. Changes since -allman-01 version . . . . . . . . . . . . . 77 F.10. Changes since -ietf-00 version . . . . . . . . . . . . . . 77
F.11. Changes since -allman-00 version . . . . . . . . . . . . . 77 F.11. Changes since -allman-01 version . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 F.12. Changes since -allman-00 version . . . . . . . . . . . . . 78
Intellectual Property and Copyright Statements . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79
Intellectual Property and Copyright Statements . . . . . . . . . . 81
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 13, line 9 skipping to change at page 13, line 9
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 [FIPS.180-2.2002] as the hash-alg.
then signed by the signer using the RSA algorithm (defined in PKCS#1 That hash is then signed by the signer using the RSA algorithm
version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
The hash MUST NOT be truncated or converted into any form other than signer's private key. The hash MUST NOT be truncated or converted
the native binary form before being signed. The signing algorithm into any form other than the native binary form before being signed.
SHOULD use an exponent of 65537. The signing algorithm SHOULD use an exponent of 65537.
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 [FIPS.180-2.2002] as the hash-alg.
is then signed by the signer using the RSA algorithm (defined in That hash is then signed by the signer using the RSA algorithm
PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
private key. The hash MUST NOT be truncated or converted into any signer's private key. The hash MUST NOT be truncated or converted
form other than the native binary form before being signed. into any form other than the native binary form before being signed.
3.3.3. Key sizes 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
skipping to change at page 28, line 12 skipping to change at page 28, line 12
ABNF: ABNF:
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
0*( [FWS] ":" [FWS] key-h-tag-alg ) 0*( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word ; for future extension x-key-h-tag-alg = hyphenated-word ; for future extension
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an ASN.1 DER-encoded [X.660] RSAPublicKey indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey
[RFC3447] (see sections 3.1 and A.1.1) is being used in the p= [RFC3447] (see sections 3.1 and A.1.1) is being used in the p=
tag. (Note: the p= tag further encodes the value using the tag. (Note: the p= tag further encodes the value using the
base64 algorithm.) base64 algorithm.)
ABNF: ABNF:
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension x-key-k-tag-type = hyphenated-word ; for future extension
skipping to change at page 35, line 9 skipping to change at page 35, line 9
When evaluating a message with multiple signatures, a verifier SHOULD When evaluating a message with multiple signatures, a verifier SHOULD
evaluate signatures independently and on their own merits. For evaluate signatures independently and on their own merits. For
example, a verifier that by policy chooses not to accept signatures example, a verifier that by policy chooses not to accept signatures
with deprecated cryptographic algorithms would consider such with deprecated cryptographic algorithms would consider such
signatures invalid. Verifiers MAY process signatures in any order of signatures invalid. Verifiers MAY process signatures in any order of
their choice; for example, some verifiers might choose to process their choice; for example, some verifiers might choose to process
signatures corresponding to the From field in the message header signatures corresponding to the From field in the message header
before other signatures. See Section 6.1 for more information about before other signatures. See Section 6.1 for more information about
signature choices. signature choices.
INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate
valid signatures with invalid signatures in an attempt to guess
why a signature failed are ill-advised. In particular, there is
no general way that a verifier can determine that an invalid
signature was ever valid.
Verifiers SHOULD ignore failed signatures as though they were not Verifiers SHOULD ignore failed signatures as though they were not
present in the message. Verifiers SHOULD continue to check present in the message. Verifiers SHOULD continue to check
signatures until a signature successfully verifies to the signatures until a signature successfully verifies to the
satisfaction of the verifier. To limit potential denial-of-service satisfaction of the verifier. To limit potential denial-of-service
attacks, verifiers MAY limit the total number of signatures they will attacks, verifiers MAY limit the total number of signatures they will
attempt to verify. attempt to verify.
5. Signer Actions 5. Signer Actions
The following steps are performed in order by signers. The following steps are performed in order by signers.
skipping to change at page 44, line 33 skipping to change at page 44, line 39
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 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 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" signing entity. For example, signatures with d= values such as "com"
and "co.uk" may be ignored. and "co.uk" may be ignored. The list of unacceptable domains SHOULD
be configurable.
Verifiers MAY ignore the DKIM-Signature header field and return Verifiers MAY ignore the DKIM-Signature header field and return
PERMFAIL (unacceptable signature header) for any other reason, for PERMFAIL (unacceptable signature header) for any other reason, for
example, if the signature does not sign header fields that the example, if the signature does not sign header fields that the
verifier views to be essential. As a case in point, if MIME header verifier views to be essential. As a case in point, if MIME header
fields are not signed, certain attacks may be possible that the fields are not signed, certain attacks may be possible that the
verifier would prefer to avoid. verifier would prefer to avoid.
6.1.2. Get the Public Key 6.1.2. Get the Public Key
skipping to change at page 52, line 26 skipping to change at page 53, line 7
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 | [FIPS.180-2.2002] |
| sha256 | [SHA] | | sha256 | [FIPS.180-2.2002] |
+--------+-----------+ +--------+-------------------+
DKIM Hash Algorithms Initial Values DKIM Hash Algorithms Initial Values
7.7. DKIM Service Types Registry 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.
skipping to change at page 58, line 35 skipping to change at page 59, line 23
example, in the example above any of the domains could potentially example, in the example above any of the domains could potentially
simply delegate "example.podunk.ca.us" to a server of their choice simply delegate "example.podunk.ca.us" to a server of their choice
and completely replace all DNS-served information. Note that a and completely replace all DNS-served information. Note that a
verifier MAY ignore signatures that come from an unlikely domain verifier MAY ignore signatures that come from an unlikely domain
such as ".com", as discussed in Section 6.1.1. such as ".com", as discussed in Section 6.1.1.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS.180-2.2002]
U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-2, August 2002.
[ITU.X660.1997]
"Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.660, 1997.
[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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 59, line 11 skipping to change at page 60, line 9
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
March 2003. RFC 3490, March 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[SHA] U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-2, August 2002.
[X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
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.
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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considers Section in RFCs", BCP 26, October 1998. IANA Considers Section in RFCs", BCP 26, October 1998.
skipping to change at page 70, line 19 skipping to change at page 71, line 19
constructive criticism. 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-08 version F.1. Changes since -ietf-09 version
The following changes were made between draft-ietf-dkim-base-09 and
draft-ietf-dkim-base-10:
o Section 6.1.1, clarify that the list of unlikely domains should be
configurable in some fashion.
o Section 4.2, add informative note about the dangers of trying to
correlate valid and invalid signatures.
o Reference details added in XML (may not show up in .txt versions).
o Some XML adjustments for formatting.
F.2. Changes since -ietf-08 version
The following changes were made between draft-ietf-dkim-base-08 and The following changes were made between draft-ietf-dkim-base-08 and
draft-ietf-dkim-base-09: draft-ietf-dkim-base-09:
o Section 3.3.1, recommend use of an RSA exponent of 65537. 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 o Section 3.4.4, mention theoretical "ASCII Art" attack for relaxed
body canonicalization. body canonicalization.
o Section 5.4.1 moved to 5.5 (with old 5.5 et seq. pushed down) to o Section 5.4.1 moved to 5.5 (with old 5.5 et seq. pushed down) to
skipping to change at page 70, line 44 skipping to change at page 72, line 13
signatures from unlikely domains such as "com" and "co.uk". signatures from unlikely domains such as "com" and "co.uk".
o Section 6.3, try to clarify the wording about SMTP rejections. o Section 6.3, try to clarify the wording about SMTP rejections.
o Section 7, change IANA registration requirement to be any RFC o Section 7, change IANA registration requirement to be any RFC
having "IETF Consensus" (as defined in RFC2434), not necessarily having "IETF Consensus" (as defined in RFC2434), not necessarily
standards-track, as a result of overwhelming WG consensus. standards-track, as a result of overwhelming WG consensus.
o Informative References, add RFC 2434. o Informative References, add RFC 2434.
F.2. Changes since -ietf-07 version F.3. 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 10 skipping to change at page 73, line 25
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.3. Changes since -ietf-06 version F.4. 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 72, line 34 skipping to change at page 74, line 5
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.4. Changes since -ietf-05 version F.5. 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 10 skipping to change at page 74, line 29
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.5. Changes since -ietf-04 version F.6. 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 73, line 32 skipping to change at page 75, line 5
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.6. Changes since -ietf-03 version F.7. 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 74, line 32 skipping to change at page 76, line 4
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.7. Changes since -ietf-02 version F.8. 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 75, line 42 skipping to change at page 77, line 13
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.8. Changes since -ietf-01 version F.9. 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 26 skipping to change at page 77, line 44
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.9. Changes since -ietf-00 version F.10. 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 5 skipping to change at page 78, line 20
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.10. Changes since -allman-01 version F.11. 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.11. Changes since -allman-00 version F.12. 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".
 End of changes. 35 change blocks. 
90 lines changed or deleted 113 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/