draft-ietf-dkim-rfc4871bis-12.txt   draft-ietf-dkim-rfc4871bis-13.txt 
Network Working Group D. Crocker, Ed. Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871, 5672 T. Hansen, Ed. Obsoletes: 4871, 5672 T. Hansen, Ed.
(if approved) AT&T Laboratories (if approved) AT&T Laboratories
Intended status: Standards Track M. Kucherawy, Ed. Intended status: Standards Track M. Kucherawy, Ed.
Expires: December 17, 2011 Cloudmark Expires: December 26, 2011 Cloudmark
June 15, 2011 June 24, 2011
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-12 draft-ietf-dkim-rfc4871bis-13
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 45 skipping to change at page 1, line 45
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 December 17, 2011. This Internet-Draft will expire on December 26, 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. DKIM Architecture Documents . . . . . . . . . . . . . . . 6 1.1. DKIM Architecture Documents . . . . . . . . . . . . . . . 6
1.2. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 1.2. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6
1.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Simple Key Management . . . . . . . . . . . . . . . . . . 6 1.4. Simple Key Management . . . . . . . . . . . . . . . . . . 6
1.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 7
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 21 skipping to change at page 4, line 7
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 42 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 42
5.5. Recommended Signature Content . . . . . . . . . . . . . . 44 5.5. Recommended Signature Content . . . . . . . . . . . . . . 44
5.6. Compute the Message Hash and Signature . . . . . . . . . . 45 5.6. Compute the Message Hash and Signature . . . . . . . . . . 45
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 46 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 46
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46
6.1. Extract Signatures from the Message . . . . . . . . . . . 47 6.1. Extract Signatures from the Message . . . . . . . . . . . 47
6.2. Communicate Verification Results . . . . . . . . . . . . . 52 6.2. Communicate Verification Results . . . . . . . . . . . . . 52
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 54 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 54
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 55
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 55 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 55
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 56 7.4. _domainkey DNS TXT Resource Record Tag Specifications . . 56
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 57
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 57 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 57
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 58 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 58
8. Security Considerations . . . . . . . . . . . . . . . . . . . 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 58 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 58
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 61
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62
8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62
8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64
9.2. Informative References . . . . . . . . . . . . . . . . . . 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67
A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 A.3. The Email Signature is Verified . . . . . . . . . . . . . 68
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74
C.2. RFC4871 Compatibility . . . . . . . . . . . . . . . . . . 74
Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 74 Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 74
Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 75 Appendix E. Changes since RFC4871 . . . . . . . . . . . . . . . . 75
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 77 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
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], which associating a domain name [RFC1034] with the message [RFC5322], which
skipping to change at page 8, line 28 skipping to change at page 8, line 28
A single identifier that refers to the agent or user on behalf of A single identifier that refers to the agent or user on behalf of
whom the Signing Domain Identifier (SDID) has taken responsibility. whom the Signing Domain Identifier (SDID) has taken responsibility.
The AUID comprises a domain name and an optional <Local-part>. The The AUID comprises a domain name and an optional <Local-part>. The
domain name is the same as that used for the SDID or is a sub-domain domain name is the same as that used for the SDID or is a sub-domain
of it. For DKIM processing, the domain name portion of the AUID has of it. For DKIM processing, the domain name portion of the AUID has
only basic domain name semantics; any possible owner-specific only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM. It is specified in semantics are outside the scope of DKIM. It is specified in
Section 3.5. Section 3.5.
Note the constraint on the value of "i=" that can be imposed by the Note that acceptable values for the AUID may be constrained via a
"t=s" tag of the stored key record. (See Section 3.6.1.) flag in the public key record. (See Section 3.6.1.)
2.7. Identity Assessor 2.7. Identity Assessor
A module that consumes DKIM's mandatory payload, which is the A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier. Other DKIM dedicated to the assessment of the delivered identifier. Other DKIM
(and non-DKIM) values can also be delivered to this module as well as (and non-DKIM) values can also be delivered to this module as well as
to a more general message evaluation filtering engine. However, this to a more general message evaluation filtering engine. However, this
additional activity is outside the scope of the DKIM signature additional activity is outside the scope of the DKIM signature
specification. specification.
skipping to change at page 20, line 41 skipping to change at page 20, line 41
v= Version (MUST be included). This tag defines the version of this v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison on the value "1". Note that verifiers must do a string comparison on
this value; for example, "1" is not the same as "1.0". this value; for example, "1" is not the same as "1.0".
ABNF: ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1" sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected INFORMATIVE NOTE: DKIM-Signature version numbers may increase
to increase arithmetically as new versions of this arithmetically as new versions of this specification are
specification are released. released.
a= The algorithm used to generate the signature (plain-text; a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of the algorithms. description of the algorithms.
ABNF: ABNF:
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
skipping to change at page 23, line 34 skipping to change at page 23, line 34
actual header field names in a case-insensitive manner. This list actual header field names in a case-insensitive manner. This list
MUST NOT be empty. See Section 5.4 for a discussion of choosing MUST NOT be empty. See Section 5.4 for a discussion of choosing
header fields to sign. header fields to sign.
ABNF: ABNF:
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( [FWS] ":" [FWS] hdr-name ) 0*( [FWS] ":" [FWS] hdr-name )
INFORMATIVE EXPLANATION: By "signing" header fields that do not INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those header actually exist, a signer can allow a verifier to detect
fields before verification. However, since a signer cannot insertion of those header fields after signing. However, since
possibly know what header fields might be created in the a signer cannot possibly know what header fields might be
future, and that some MUAs might present header fields that are created in the future, and that some MUAs might present header
embedded inside a message (e.g., as a message/rfc822 content fields that are embedded inside a message (e.g., as a message/
type), the security of this solution is not total. rfc822 content type), the security of this solution is not
total.
INFORMATIVE EXPLANATION: The exclusion of the header field name INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent and colon as well as the header field value for non-existent
header fields prevents an attacker from inserting an actual header fields allows detection of an attacker that inserts an
header field with a null value. actual header field with a null value.
i= The Agent or User Identifier (AUID) on behalf of which the SDID is i= The Agent or User Identifier (AUID) on behalf of which the SDID is
taking responsibility (dkim-quoted-printable; OPTIONAL, default is taking responsibility (dkim-quoted-printable; OPTIONAL, default is
an empty Local-part followed by an "@" followed by the domain from an empty Local-part followed by an "@" followed by the domain from
the "d=" tag). the "d=" tag).
The syntax is a standard email address where the Local-part MAY be The syntax is a standard email address where the Local-part MAY be
omitted. The domain part of the address MUST be the same as, or a omitted. The domain part of the address MUST be the same as, or a
subdomain of, the value of the "d=" tag. subdomain of, the value of the "d=" tag.
Internationalized domain names MUST be encoded as A-Labels, as Internationalized domain names MUST be encoded as A-Labels, as
described in Section 2.3 of [RFC5890]. described in Section 2.3 of [RFC5890].
ABNF: ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
"@" domain-name "@" domain-name
The AUID is specified as having the same syntax as an email The AUID is specified as having the same syntax as an email
address, but need not have the same semantics. Notably, the address, but need not have the same semantics. Notably, the
domain name is need not be registered in the DNS -- so it might domain name need not be registered in the DNS -- so it might not
not resolve in a query -- and the Local-part MAY be drawn from a resolve in a query -- and the Local-part MAY be drawn from a
namespace unrelated to any mailbox. The details of the structure namespace unrelated to any mailbox. The details of the structure
and semantics for the namespace are determined by the Signer. Any and semantics for the namespace are determined by the Signer. Any
knowledge or use of those details by verifiers or assessors is knowledge or use of those details by verifiers or assessors is
outside the scope of the DKIM Signing specification. The Signer outside the scope of the DKIM Signing specification. The Signer
MAY choose to use the same namespace for its AUIDs as its users' MAY choose to use the same namespace for its AUIDs as its users'
email addresses or MAY choose other means of representing its email addresses or MAY choose other means of representing its
users. However, the signer SHOULD use the same AUID for each users. However, the signer SHOULD use the same AUID for each
message intended to be evaluated as being within the same sphere message intended to be evaluated as being within the same sphere
of responsibility, if it wishes to offer receivers the option of of responsibility, if it wishes to offer receivers the option of
using the AUID as a stable identifier that is finer grained than using the AUID as a stable identifier that is finer grained than
skipping to change at page 26, line 24 skipping to change at page 26, line 24
q= A colon-separated list of query methods used to retrieve the q= A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns/txt"). Each public key (plain-text; OPTIONAL, default is "dns/txt"). Each
query method is of the form "type[/options]", where the syntax and query method is of the form "type[/options]", where the syntax and
semantics of the options depend on the type and specified options. semantics of the options depend on the type and specified options.
If there are multiple query mechanisms listed, the choice of query If there are multiple query mechanisms listed, the choice of query
mechanism MUST NOT change the interpretation of the signature. mechanism MUST NOT change the interpretation of the signature.
Implementations MUST use the recognized query mechanisms in the Implementations MUST use the recognized query mechanisms in the
order presented. Unrecognized query mechanisms MUST be ignored. order presented. Unrecognized query mechanisms MUST be ignored.
Currently, the only valid value is "dns/txt", which defines the Currently, the only valid value is "dns/txt", which defines the
DNS TXT record lookup algorithm described elsewhere in this DNS TXT resource record (RR) lookup algorithm described elsewhere
document. The only option defined for the "dns" query type is in this document. The only option defined for the "dns" query
"txt", which MUST be included. Verifiers and signers MUST support type is "txt", which MUST be included. Verifiers and signers MUST
"dns/txt". support "dns/txt".
ABNF: ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method) *([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args] ["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value x-sig-q-tag-args = qp-hdr-value
skipping to change at page 29, line 35 skipping to change at page 29, line 35
DKIM keys can potentially be stored in multiple types of key servers DKIM keys can potentially be stored in multiple types of key servers
and in multiple formats. The storage and format of keys are and in multiple formats. The storage and format of keys are
irrelevant to the remainder of the DKIM algorithm. irrelevant to the remainder of the DKIM algorithm.
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 RRs 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.
skipping to change at page 31, line 34 skipping to change at page 31, line 34
code for any DKIM-Signature header field with a selector code for any DKIM-Signature header field with a selector
referencing a revoked key. (See Section 6.1.2 for details.) referencing a revoked key. (See Section 6.1.2 for details.)
ABNF: ABNF:
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] key-p-tag = %x70 [FWS] "=" [ [FWS] base64string]
INFORMATIVE NOTE: A base64string is permitted to include white INFORMATIVE NOTE: A base64string is permitted to include white
space (FWS) at arbitrary places; however, any CRLFs must be space (FWS) at arbitrary places; however, any CRLFs must be
followed by at least one WSP character. Implementors and followed by at least one WSP character. Implementors and
administrators are cautioned to ensure that selector TXT administrators are cautioned to ensure that selector TXT RRs
records conform to this specification. conform to this specification.
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- s= Service Type (plain-text; OPTIONAL; default is "*"). A colon-
separated list of service types to which this record applies. separated list of service types to which this record applies.
Verifiers for a given service type MUST ignore this record if the Verifiers for a given service type MUST ignore this record if the
appropriate type is not listed. Unrecognized service types MUST appropriate type is not listed. Unrecognized service types MUST
be ignored. Currently defined service types are as follows: be ignored. Currently defined service types are as follows:
* matches all service types * matches all service types
email electronic mail (not necessarily limited to SMTP) email electronic mail (not necessarily limited to SMTP)
skipping to change at page 33, line 7 skipping to change at page 33, line 7
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
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 RRs as a key service is hereby defined. All
All implementations MUST support this binding. implementations MUST support this binding.
3.6.2.1. Namespace 3.6.2.1. Namespace
All DKIM keys are stored in a subdomain named "_domainkey". Given a All DKIM keys are stored in a subdomain named "_domainkey". Given a
DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag
of "foo.bar", the DNS query will be for of "foo.bar", the DNS query will be for
"foo.bar._domainkey.example.com". "foo.bar._domainkey.example.com".
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 RR. A later
(RR). A later extension of this standard may define another RR type. 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 whitespace. TXT RRs MUST be unique for a particular intervening whitespace. 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
skipping to change at page 50, line 11 skipping to change at page 50, line 11
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 a wildcard TXT record that covers a queried DKIM NOTE: The use of a wildcard TXT RR that covers a queried DKIM domain
domain name will produce a response to a DKIM query that is name will produce a response to a DKIM query that is unlikely to
unlikely to be valid DKIM key record. This problem is not be valid DKIM key record. This problem is not specific to DKIM
specific to DKIM and applies to many other types of queries. and applies to many other types of queries. Client software that
Client software that processes DNS responses needs to take this 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
selector from the "s=" tag. selector from the "s=" tag.
skipping to change at page 54, line 18 skipping to change at page 54, line 18
are assigned only for values that have been documented in a published are assigned only for values that have been documented in a published
RFC that has IETF Consensus [RFC5226]. RFC that has IETF Consensus [RFC5226].
This memo updates these registries as described below. Of note is This memo updates these registries as described below. Of note is
the addition of a new "status" column. All registrations into these the addition of a new "status" column. All registrations into these
namespaces MUST include the name being registered, the document in namespaces MUST include the name being registered, the document in
which it was registered or updated, and an indication of its current which it was registered or updated, and an indication of its current
status which MUST be one of "active" (in current use) or "historic" status which MUST be one of "active" (in current use) or "historic"
(no longer in current use). (no longer in current use).
No new tags are defined in this specification compared to [RFC4871],
but one has been obsoleted.
7.1. DKIM-Signature Tag Specifications 7.1. DKIM-Signature Tag Specifications
A DKIM-Signature provides for a list of tag specifications. IANA has A DKIM-Signature provides for a list of tag specifications. IANA has
established the DKIM-Signature Tag Specification Registry for tag established the DKIM-Signature Tag Specification Registry for tag
specifications that can be used in DKIM-Signature fields. specifications that can be used in DKIM-Signature fields.
The updated entries in the registry comprise: The updated entries in the registry comprise:
+------+-----------------+--------+ +------+-----------------+--------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
skipping to change at page 56, line 5 skipping to change at page 56, line 10
+---------+-----------------+--------+ +---------+-----------------+--------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
+---------+-----------------+--------+ +---------+-----------------+--------+
| simple | (this document) | active | | simple | (this document) | active |
| relaxed | (this document) | active | | relaxed | (this document) | active |
+---------+-----------------+--------+ +---------+-----------------+--------+
DKIM-Signature Body Canonicalization Algorithm Registry DKIM-Signature Body Canonicalization Algorithm Registry
Updated Values Updated Values
7.4. _domainkey DNS TXT Record Tag Specifications 7.4. _domainkey DNS TXT Resource Record Tag Specifications
A _domainkey DNS TXT record provides for a list of tag A _domainkey DNS TXT RR provides for a list of tag specifications.
specifications. IANA has established the DKIM _domainkey DNS TXT Tag IANA has established the DKIM _domainkey DNS TXT Tag Specification
Specification Registry for tag specifications that can be used in DNS Registry for tag specifications that can be used in DNS TXT resource
TXT Records. records.
The updated entries in the registry comprise: The updated entries in the registry comprise:
+------+-----------------+----------+ +------+-----------------+----------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
+------+-----------------+----------+ +------+-----------------+----------+
| v | (this document) | active | | v | (this document) | active |
| g | [RFC4871] | historic | | g | [RFC4871] | historic |
| h | (this document) | active | | h | (this document) | active |
| k | (this document) | active | | k | (this document) | active |
| n | (this document) | active | | n | (this document) | active |
| p | (this document) | active | | p | (this document) | active |
| s | (this document) | active | | s | (this document) | active |
| t | (this document) | active | | t | (this document) | active |
+------+-----------------+----------+ +------+-----------------+----------+
DKIM _domainkey DNS TXT Record Tag Specification Registry DKIM _domainkey DNS TXT Tag Specification Registry
Updated Values Updated Values
7.5. DKIM Key Type Registry 7.5. DKIM Key Type Registry
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig-
a-tag-k> (specified in Section 3.5) tags provide for a list of a-tag-k> (specified in Section 3.5) tags provide for a list of
mechanisms that can be used to decode a DKIM signature. mechanisms that can be used to decode a DKIM signature.
IANA has established the DKIM Key Type Registry for such mechanisms. IANA has established the DKIM Key Type Registry for such mechanisms.
skipping to change at page 65, line 26 skipping to change at page 65, line 30
[RFC5890] Klensin, J., "Internationalizing Domain Names in [RFC5890] Klensin, J., "Internationalizing Domain Names in
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
9.2. Informative References 9.2. Informative References
[BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th
USENIX Security Symposium, 2003. USENIX Security Symposium, 2003.
[I-D.DKIM-MAILINGLISTS]
Kucherawy, M., "DKIM And Mailing Lists",
I-D draft-ietf-dkim-mailinglists, June 2011.
[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", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004. RFC 3766, 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.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
skipping to change at page 73, line 18 skipping to change at page 73, line 18
signature or if they have some other basis for knowing that the signature or if they have some other basis for knowing that the
message is not spoofed. message is not spoofed.
A common practice among systems that are primarily redistributors of A common practice among systems that are primarily redistributors of
mail is to add a Sender header field to the message, to identify the mail is to add a Sender header field to the message, to identify the
address being used to sign the message. This practice will remove address being used to sign the message. This practice will remove
any preexisting Sender header field as required by [RFC5322]. The any preexisting Sender header field as required by [RFC5322]. The
forwarder applies a new DKIM-Signature header field with the forwarder applies a new DKIM-Signature header field with the
signature, public key, and related information of the forwarder. signature, public key, and related information of the forwarder.
See [I-D.DKIM-MAILINGLISTS] for additional related topics and
discussion.
Appendix C. Creating a Public Key (INFORMATIVE) Appendix C. Creating a Public Key (INFORMATIVE)
The default signature is an RSA signed SHA-256 digest of the complete The default signature is an RSA signed SHA-256 digest of the complete
email. For ease of explanation, the openssl command is used to email. For ease of explanation, the openssl command is used to
describe the mechanism by which keys and signatures are managed. One describe the mechanism by which keys and signatures are managed. One
way to generate a 1024-bit, unencrypted private key suitable for DKIM way to generate a 1024-bit, unencrypted private key suitable for DKIM
is to use openssl like this: is to use openssl like this:
$ openssl genrsa -out rsa.private 1024 $ openssl genrsa -out rsa.private 1024
For increased security, the "-passin" parameter can also be added to For increased security, the "-passin" parameter can also be added to
encrypt the private key. Use of this parameter will require entering encrypt the private key. Use of this parameter will require entering
skipping to change at page 74, line 40 skipping to change at page 74, line 40
referred to as "selector records" in the DomainKeys context). One referred to as "selector records" in the DomainKeys context). One
area of incompatibility warrants particular attention. The "g=" tag/ area of incompatibility warrants particular attention. The "g=" tag/
value may be used in DomainKeys and [RFC4871] key records to provide value may be used in DomainKeys and [RFC4871] key records to provide
finer granularity of the validity of the key record to a specific finer granularity of the validity of the key record to a specific
local-part. A null "g=" value in DomainKeys is valid for all local-part. A null "g=" value in DomainKeys is valid for all
addresses in the domain. This differs from the usage in the original addresses in the domain. This differs from the usage in the original
DKIM specification, where a null "g=" value is not valid for any DKIM specification, where a null "g=" value is not valid for any
address. In particular, the example public key record in Section address. In particular, the example public key record in Section
3.2.3 of [RFC4870] with DKIM. 3.2.3 of [RFC4870] with DKIM.
C.2. RFC4871 Compatibility
Although the "g=" tag has been deprecated in this version of the DKIM Although the "g=" tag has been deprecated in this version of the DKIM
specification, signers are advised not to include the "g=" tag in key specification (and thus MUST now be ignored), signers are advised not
records because some [RFC4871]-compliant verifiers will be in use for to include the "g=" tag in key records because some [RFC4871]-
a considerable period to come. compliant verifiers will be in use for a considerable period to come.
Appendix D. MUA Considerations (INFORMATIVE) Appendix D. MUA Considerations (INFORMATIVE)
When a DKIM signature is verified, the processing system sometimes When a DKIM signature is verified, the processing system sometimes
makes the result available to the recipient user's MUA. How to makes the result available to the recipient user's MUA. How to
present this information to the user in a way that helps them is a present this information to the user in a way that helps them is a
matter of continuing human factors usability research. The tendency matter of continuing human factors usability research. The tendency
is to have the MUA highlight the SDID, in an attempt to show the user is to have the MUA highlight the SDID, in an attempt to show the user
the identity that is claiming responsibility for the message. An MUA the identity that is claiming responsibility for the message. An MUA
might do this with visual cues such as graphics, or it might include might do this with visual cues such as graphics, or it might include
skipping to change at page 76, line 14 skipping to change at page 76, line 16
* 1386 applied * 1386 applied
* 1461 applied * 1461 applied
* 1487 applied * 1487 applied
* 1532 applied * 1532 applied
* 1596 applied * 1596 applied
o Introductory section enumerating relevent architectural documents o Introductory section enumerating relevant architectural documents
added. added.
o Introductory section briefly discussing the matter of data o Introductory section briefly discussing the matter of data
integrity added. integrity added.
o Allow tolerance of some clock drift. o Allow tolerance of some clock drift.
o Drop "g=" tag from key records. The implementation report o Drop "g=" tag from key records. The implementation report
indicates that it is not in use. indicates that it is not in use.
 End of changes. 29 change blocks. 
50 lines changed or deleted 75 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/