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/ |