draft-ietf-dkim-rfc4871bis-05.txt | draft-ietf-dkim-rfc4871bis-06.txt | |||
---|---|---|---|---|
Network Working Group D. Crocker, Ed. | Network Working Group D. Crocker, Ed. | |||
Internet-Draft Brandenburg InternetWorking | Internet-Draft Brandenburg InternetWorking | |||
Obsoletes: 4871 (if approved) T. Hansen, Ed. | Obsoletes: 4871 (if approved) T. Hansen, Ed. | |||
Intended status: Standards Track AT&T Laboratories | Intended status: Standards Track AT&T Laboratories | |||
Expires: September 29, 2011 M. Kucherawy, Ed. | Expires: October 14, 2011 M. Kucherawy, Ed. | |||
Cloudmark | Cloudmark | |||
March 28, 2011 | April 12, 2011 | |||
DomainKeys Identified Mail (DKIM) Signatures | DomainKeys Identified Mail (DKIM) Signatures | |||
draft-ietf-dkim-rfc4871bis-05 | draft-ietf-dkim-rfc4871bis-06 | |||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) permits a person, role, or | DomainKeys Identified Mail (DKIM) permits a person, role, or | |||
organization that owns the signing domain to claim some | organization that owns the signing domain to claim some | |||
responsibility for a message by associating the domain with the | responsibility for a message by associating the domain with the | |||
message. This can be an author's organization, an operational relay | message. This can be an author's organization, an operational relay | |||
or one of their agents. DKIM separates the question of the identity | or one of their agents. DKIM separates the question of the identity | |||
of the signer of the message from the purported author of the | of the signer of the message from the purported author of the | |||
message. Assertion of responsibility is validated through a | message. Assertion of responsibility is validated through a | |||
skipping to change at page 1, line 43 | skipping to change at page 1, line 43 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 29, 2011. | This Internet-Draft will expire on October 14, 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 | |||
skipping to change at page 2, line 31 | skipping to change at page 2, line 31 | |||
1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 | 1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 | |||
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 | 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 | |||
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 | 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 | |||
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 | 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 | |||
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | 2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | |||
2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 | 2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 | |||
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 | 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 | |||
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 | 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 | 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 | |||
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 | 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 | |||
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 | |||
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 | |||
3.6. Key Management and Representation . . . . . . . . . . . . 28 | 3.6. Key Management and Representation . . . . . . . . . . . . 28 | |||
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 | |||
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 | |||
skipping to change at page 3, line 51 | skipping to change at page 3, line 51 | |||
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 | |||
Appendix D. Removal of Key Granularity . . . . . . . . . . . . . 74 | C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 | |||
Appendix E. MUA Considerations . . . . . . . . . . . . . . . . . 74 | ||||
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 | ||||
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 | |||
they are authorized to use. This can be an author's organization, an | they are authorized to use. This can be an author's organization, an | |||
operational relay or one of their agents. Assertion of | operational relay or one of their agents. Assertion of | |||
responsibility is validated through a cryptographic signature and | responsibility is validated through a cryptographic signature and | |||
querying the signer's domain directly to retrieve the appropriate | querying the signer's domain directly to retrieve the appropriate | |||
skipping to change at page 9, line 5 | skipping to change at page 9, line 5 | |||
The formal ABNF for these are (WSP and LWSP are given for information | The formal ABNF for these are (WSP and LWSP are given for information | |||
only): | only): | |||
WSP = SP / HTAB | WSP = SP / HTAB | |||
LWSP = *(WSP / CRLF WSP) | LWSP = *(WSP / CRLF WSP) | |||
FWS = [*WSP CRLF] 1*WSP | FWS = [*WSP CRLF] 1*WSP | |||
The definition of FWS is identical to that in [RFC5322] except for | The definition of FWS is identical to that in [RFC5322] except for | |||
the exclusion of obs-FWS. | the exclusion of obs-FWS. | |||
2.9. Common ABNF Tokens | 2.9. Imported ABNF Tokens | |||
The following ABNF tokens are used elsewhere in this document: | ||||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | ||||
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") | ||||
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) | ||||
[ [FWS] "=" [ [FWS] "=" ] ] | ||||
hdr-name = field-name | ||||
qp-hdr-value = dkim-quoted-printable ; with "|" encoded | ||||
2.10. Imported ABNF Tokens | ||||
The following tokens are imported from other RFCs as noted. Those | The following tokens are imported from other RFCs as noted. Those | |||
RFCs should be considered definitive. | RFCs should be considered definitive. | |||
The following tokens are imported from [RFC5321]: | The following tokens are imported from [RFC5321]: | |||
o "Local-part" (implementation warning: this permits quoted strings) | o "Local-part" (implementation warning: this permits quoted strings) | |||
o "sub-domain" | o "sub-domain" | |||
skipping to change at page 9, line 46 | skipping to change at page 9, line 36 | |||
o "hex-octet" (a quoted-printable encoded octet) | o "hex-octet" (a quoted-printable encoded octet) | |||
INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not | INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not | |||
obey the rules of [RFC5234] and must be interpreted accordingly, | obey the rules of [RFC5234] and must be interpreted accordingly, | |||
particularly as regards case folding. | particularly as regards case folding. | |||
Other tokens not defined herein are imported from [RFC5234]. These | Other tokens not defined herein are imported from [RFC5234]. These | |||
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, | are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, | |||
etc. | etc. | |||
2.10. Common ABNF Tokens | ||||
The following ABNF tokens are used elsewhere in this document: | ||||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | ||||
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") | ||||
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) | ||||
[ [FWS] "=" [ [FWS] "=" ] ] | ||||
hdr-name = field-name | ||||
qp-hdr-value = dkim-quoted-printable ; with "|" encoded | ||||
2.11. DKIM-Quoted-Printable | 2.11. DKIM-Quoted-Printable | |||
The DKIM-Quoted-Printable encoding syntax resembles that described in | The DKIM-Quoted-Printable encoding syntax resembles that described in | |||
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded | Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded | |||
as an "=" followed by two hexadecimal digits from the alphabet | as an "=" followed by two hexadecimal digits from the alphabet | |||
"0123456789ABCDEF" (no lowercase characters permitted) representing | "0123456789ABCDEF" (no lowercase characters permitted) representing | |||
the hexadecimal-encoded integer value of that character. All control | the hexadecimal-encoded integer value of that character. All control | |||
characters (those with values < %x20), 8-bit characters (values > | characters (those with values < %x20), 8-bit characters (values > | |||
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon | %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon | |||
(";", %x3B) MUST be encoded. Note that all whitespace, including | (";", %x3B) MUST be encoded. Note that all whitespace, including | |||
skipping to change at page 12, line 44 | skipping to change at page 12, line 44 | |||
to reuse selectors for new keys. A better strategy is to assign | to reuse selectors for new keys. A better strategy is to assign | |||
new keys to new selectors. | new keys to new selectors. | |||
3.2. Tag=Value Lists | 3.2. Tag=Value Lists | |||
DKIM uses a simple "tag=value" syntax in several contexts, including | DKIM uses a simple "tag=value" syntax in several contexts, including | |||
in messages and domain signature records. | in messages and domain signature records. | |||
Values are a series of strings containing either plain text, "base64" | Values are a series of strings containing either plain text, "base64" | |||
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, | text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, | |||
Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6). | Section 6.7), or "dkim-quoted-printable" (as defined in | |||
The name of the tag will determine the encoding of each value. | Section 2.11). The name of the tag will determine the encoding of | |||
Unencoded semicolon (";") characters MUST NOT occur in the tag value, | each value. Unencoded semicolon (";") characters MUST NOT occur in | |||
since that separates tag-specs. | the tag value, since that separates tag-specs. | |||
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined | |||
below (as "tag-value") only includes 7-bit characters, an | below (as "tag-value") only includes 7-bit characters, an | |||
implementation that wished to anticipate future standards would be | implementation that wished to anticipate future standards would be | |||
advised not to preclude the use of UTF8-encoded text in tag=value | advised not to preclude the use of UTF8-encoded text in tag=value | |||
lists. | lists. | |||
Formally, the ABNF syntax rules are as follows: | Formally, the ABNF syntax rules are as follows: | |||
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] | |||
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] | |||
skipping to change at page 29, line 36 | skipping to change at page 29, line 36 | |||
record. Records beginning with a "v=" tag with any other value | record. Records beginning with a "v=" tag with any other value | |||
MUST be discarded. Note that verifiers must do a string | MUST be discarded. Note that verifiers must do a string | |||
comparison on this value; for example, "DKIM1" is not the same as | comparison on this value; for example, "DKIM1" is not the same as | |||
"DKIM1.0". | "DKIM1.0". | |||
ABNF: | ABNF: | |||
key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 | key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 | |||
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to | |||
allowing all algorithms). A colon-separated list of hash | allowing all algorithms). A colon-separated list of hash | |||
algorithms that might be used. Signers and Verifiers MUST support | algorithms that might be used. Unrecognized algorithms MUST be | |||
the "sha256" hash algorithm. Verifiers MUST also support the | ignored. Refer to Section 3.3 for a discussion of the hash | |||
"sha1" hash algorithm. Unrecognized hash algorithms MUST be | algorithms implemented by Signers and Verifiers. . The set of | |||
ignored. | algorithms listed in this tag in each record is an operational | |||
choice made by the Signer. | ||||
ABNF: | ABNF: | |||
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg | |||
0*( [FWS] ":" [FWS] key-h-tag-alg ) | 0*( [FWS] ":" [FWS] key-h-tag-alg ) | |||
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg | key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg | |||
x-key-h-tag-alg = hyphenated-word ; for future extension | x-key-h-tag-alg = hyphenated-word ; for future extension | |||
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and | |||
verifiers MUST support the "rsa" key type. The "rsa" key type | verifiers MUST support the "rsa" key type. The "rsa" key type | |||
indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey | |||
[RFC3447] (see Sections Section 3.1 and A.1.1) is being used in | [RFC3447] (see Sections Section 3.1 and A.1.1) is being used in | |||
skipping to change at page 50, line 6 | skipping to change at page 50, line 6 | |||
if none, return to try another signature in the usual way". | if none, return to try another signature in the usual way". | |||
5. If the result returned from the query does not adhere to the | 5. If the result returned from the query does not adhere to the | |||
format defined in this specification, the verifier MUST ignore | format defined in this specification, the verifier MUST ignore | |||
the key record and return PERMFAIL (key syntax error). Verifiers | the key record and return PERMFAIL (key syntax error). Verifiers | |||
are urged to validate the syntax of key records carefully to | are urged to validate the syntax of key records carefully to | |||
avoid attempted attacks. In particular, the verifier MUST ignore | avoid attempted attacks. In particular, the verifier MUST ignore | |||
keys with a version code ("v=" tag) that they do not implement. | keys with a version code ("v=" tag) that they do not implement. | |||
6. If the "h=" tag exists in the public key record and the hash | 6. If the "h=" tag exists in the public key record and the hash | |||
algorithm implied by the a= tag in the DKIM-Signature header | algorithm implied by the "a=" tag in the DKIM-Signature header | |||
field is not included in the contents of the "h=" tag, the | field is not included in the contents of the "h=" tag, the | |||
verifier MUST ignore the key record and return PERMFAIL | verifier MUST ignore the key record and return PERMFAIL | |||
(inappropriate hash algorithm). | (inappropriate hash algorithm). | |||
7. If the public key data (the "p=" tag) is empty, then this key has | 7. If the public key data (the "p=" tag) is empty, then this key has | |||
been revoked and the verifier MUST treat this as a failed | been revoked and the verifier MUST treat this as a failed | |||
signature check and return PERMFAIL (key revoked). There is no | signature check and return PERMFAIL (key revoked). There is no | |||
defined semantic difference between a key that has been revoked | defined semantic difference between a key that has been revoked | |||
and a key record that has been removed. | and a key record that has been removed. | |||
skipping to change at page 53, line 31 | skipping to change at page 53, line 31 | |||
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). | |||
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 initial 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 | | |||
| a | (this document) | active | | | a | (this document) | active | | |||
| b | (this document) | active | | | b | (this document) | active | | |||
| bh | (this document) | active | | | bh | (this document) | active | | |||
| c | (this document) | active | | | c | (this document) | active | | |||
| d | (this document) | active | | | d | (this document) | active | | |||
| h | (this document) | active | | | h | (this document) | active | | |||
| i | (this document) | active | | | i | (this document) | active | | |||
| l | (this document) | active | | | l | (this document) | active | | |||
| q | (this document) | active | | | q | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
| t | (this document) | active | | | t | (this document) | active | | |||
| x | (this document) | active | | | x | (this document) | active | | |||
| z | (this document) | active | | | z | (this document) | active | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
Table 1: DKIM-Signature Tag Specification Registry Initial | Table 1: DKIM-Signature Tag Specification Registry Updated Values | |||
Values | ||||
7.2. DKIM-Signature Query Method Registry | 7.2. DKIM-Signature Query Method Registry | |||
The "q=" tag-spec (specified in Section 3.5) provides for a list of | The "q=" tag-spec (specified in Section 3.5) provides for a list of | |||
query methods. | query methods. | |||
IANA has established the DKIM-Signature Query Method Registry for | IANA has established the DKIM-Signature Query Method Registry for | |||
mechanisms that can be used to retrieve the key that will permit | mechanisms that can be used to retrieve the key that will permit | |||
validation processing of a message signed using DKIM. | validation processing of a message signed using DKIM. | |||
The initial entry in the registry comprises: | The updated entry in the registry comprises: | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
| TYPE | OPTION | REFERENCE | STATUS | | | TYPE | OPTION | REFERENCE | STATUS | | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
| dns | txt | (this document) | active | | | dns | txt | (this document) | active | | |||
+------+--------+-----------------+--------+ | +------+--------+-----------------+--------+ | |||
DKIM-Signature Query Method Registry Initial Values | DKIM-Signature Query Method Registry Updated Values | |||
7.3. DKIM-Signature Canonicalization Registry | 7.3. DKIM-Signature Canonicalization Registry | |||
The "c=" tag-spec (specified in Section 3.5) provides for a specifier | The "c=" tag-spec (specified in Section 3.5) provides for a specifier | |||
for canonicalization algorithms for the header and body of the | for canonicalization algorithms for the header and body of the | |||
message. | message. | |||
IANA has established the DKIM-Signature Canonicalization Algorithm | IANA has established the DKIM-Signature Canonicalization Algorithm | |||
Registry for algorithms for converting a message into a canonical | Registry for algorithms for converting a message into a canonical | |||
form before signing or verifying using DKIM. | form before signing or verifying using DKIM. | |||
The initial entries in the header registry comprise: | The updated entries in the header registry comprise: | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| simple | (this document) | active | | | simple | (this document) | active | | |||
| relaxed | (this document) | active | | | relaxed | (this document) | active | | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
DKIM-Signature Header Canonicalization Algorithm Registry | DKIM-Signature Header Canonicalization Algorithm Registry | |||
Initial Values | Updated Values | |||
The initial entries in the body registry comprise: | The updated entries in the body registry comprise: | |||
+---------+-----------------+--------+ | +---------+-----------------+--------+ | |||
| 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 | |||
Initial Values | Updated Values | |||
7.4. _domainkey DNS TXT Record Tag Specifications | 7.4. _domainkey DNS TXT Record Tag Specifications | |||
A _domainkey DNS TXT record provides for a list of tag | A _domainkey DNS TXT record provides for a list of tag | |||
specifications. IANA has established the DKIM _domainkey DNS TXT Tag | specifications. IANA has established the DKIM _domainkey DNS TXT Tag | |||
Specification Registry for tag specifications that can be used in DNS | Specification Registry for tag specifications that can be used in DNS | |||
TXT Records. | TXT Records. | |||
The initial 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 Record Tag Specification Registry | |||
Initial 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. | |||
The initial entry in the registry comprises: | The updated entry in the registry comprises: | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
| rsa | [RFC3447] | active | | | rsa | [RFC3447] | active | | |||
+------+-----------+--------+ | +------+-----------+--------+ | |||
DKIM Key Type Initial Values | DKIM Key Type Updated Values | |||
7.6. DKIM Hash Algorithms Registry | 7.6. DKIM Hash Algorithms Registry | |||
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- | |||
a-tag-h> (specified in Section 3.5) tags provide for a list of | a-tag-h> (specified in Section 3.5) tags provide for a list of | |||
mechanisms that can be used to produce a digest of message data. | mechanisms that can be used to produce a digest of message data. | |||
IANA has established the DKIM Hash Algorithms Registry for such | IANA has established the DKIM Hash Algorithms Registry for such | |||
mechanisms. | mechanisms. | |||
The initial entries in the registry comprise: | The updated entries in the registry comprise: | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
| sha1 | [FIPS-180-2-2002] | active | | | sha1 | [FIPS-180-2-2002] | active | | |||
| sha256 | [FIPS-180-2-2002] | active | | | sha256 | [FIPS-180-2-2002] | active | | |||
+--------+-------------------+--------+ | +--------+-------------------+--------+ | |||
DKIM Hash Algorithms Initial Values | DKIM Hash Algorithms Updated Values | |||
7.7. DKIM Service Types Registry | 7.7. DKIM Service Types Registry | |||
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a | |||
list of service types to which this selector may apply. | list of service types to which this selector may apply. | |||
IANA has established the DKIM Service Types Registry for service | IANA has established the DKIM Service Types Registry for service | |||
types. | types. | |||
The initial entries in the registry comprise: | The updated entries in the registry comprise: | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
| email | (this document) | active | | | email | (this document) | active | | |||
| * | (this document) | active | | | * | (this document) | active | | |||
+-------+-----------------+--------+ | +-------+-----------------+--------+ | |||
DKIM Service Types Registry Initial Values | DKIM Service Types Registry Updated Values | |||
7.8. DKIM Selector Flags Registry | 7.8. DKIM Selector Flags Registry | |||
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a | |||
list of flags to modify interpretation of the selector. | list of flags to modify interpretation of the selector. | |||
IANA has established the DKIM Selector Flags Registry for additional | IANA has established the DKIM Selector Flags Registry for additional | |||
flags. | flags. | |||
The initial entries in the registry comprise: | The updated entries in the registry comprise: | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| TYPE | REFERENCE | STATUS | | | TYPE | REFERENCE | STATUS | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
| y | (this document) | active | | | y | (this document) | active | | |||
| s | (this document) | active | | | s | (this document) | active | | |||
+------+-----------------+--------+ | +------+-----------------+--------+ | |||
DKIM Selector Flags Registry Initial Values | DKIM Selector Flags Registry Updated Values | |||
7.9. DKIM-Signature Header Field | 7.9. DKIM-Signature Header Field | |||
IANA has added DKIM-Signature to the "Permanent Message Header | IANA has added DKIM-Signature to the "Permanent Message Header | |||
Fields" registry (see [RFC3864]) for the "mail" protocol, using this | Fields" registry (see [RFC3864]) for the "mail" protocol, using this | |||
document as the reference. | document as the reference. | |||
8. Security Considerations | 8. Security Considerations | |||
It has been observed that any mechanism that is introduced that | It has been observed that any mechanism that is introduced that | |||
skipping to change at page 64, line 5 | skipping to change at page 64, line 5 | |||
include From: and Subject:, | include From: and Subject:, | |||
The resulting message violates section 3.6 of [RFC5322]. The way | The resulting message violates section 3.6 of [RFC5322]. The way | |||
such input will be handled and displayed by an MUA is unpredictable, | such input will be handled and displayed by an MUA is unpredictable, | |||
but in some cases it might display the newly added header fields | but in some cases it might display the newly added header fields | |||
rather than those that are part of the originally signed message | rather than those that are part of the originally signed message | |||
alongside some "valid DKIM signature" annotation. This might allow | alongside some "valid DKIM signature" annotation. This might allow | |||
an attacker to replay a previously sent, signed message with a | an attacker to replay a previously sent, signed message with a | |||
different Subject:, From: or To: field. | different Subject:, From: or To: field. | |||
Because of this, implementers are strongly advised to reject or treat | However, [RFC5322] also tolerates obsolete message syntax, which does | |||
as suspicious any message that has multiple copies of header fields | allow things like multiple From: fields on messages. The | |||
that are disallowed by Section 3.6 of [RFC5322] particularly those | implementation of DKIM thus potentially creates a more stringent | |||
that are typically displayed to end users (From:, To:, Cc:, | layer of expectation regarding the meaning of an identity, while that | |||
Subject:). A signing module could return an error rather than | additional meaning is either obscured from or incorrectly presented | |||
generate a signature; a verifying module might return a syntax error | to an end user in this context. | |||
code or arrange not to return a positive result even if the signature | ||||
technically validates. | Implementers need to consider this possibility when designing their | |||
input handling functions. Outright rejection of messages that | ||||
violate Section 3.6 of [RFC5322] will interfere with delivery of | ||||
legacy formats. Instead, given such input, a signing module could | ||||
return an error rather than generate a signature; a verifying module | ||||
might return a syntax error code or arrange not to return a positive | ||||
result even if the signature technically validates. | ||||
Senders concerned that their messages might be particularly | Senders concerned that their messages might be particularly | |||
vulnerable to this sort of attack and who do not wish to rely on | vulnerable to this sort of attack and who do not wish to rely on | |||
receiver filtering of invalid messages can ensure that adding | receiver filtering of invalid messages can ensure that adding | |||
additional header fields will break the DKIM signature by including | additional header fields will break the DKIM signature by including | |||
two copies of the header fields about which they are concerned in the | two copies of the header fields about which they are concerned in the | |||
signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See | |||
Sections 3.5 and 5.4 for further discussion of this mechanism. | Sections 3.5 and 5.4 for further discussion of this mechanism. | |||
Specific validity rules for all known header fields can be gleaned | Specific validity rules for all known header fields can be gleaned | |||
skipping to change at page 74, line 25 | skipping to change at page 74, line 25 | |||
-----END PUBLIC KEY----- | -----END PUBLIC KEY----- | |||
This public-key data (without the BEGIN and END tags) is placed in | This public-key data (without the BEGIN and END tags) is placed in | |||
the DNS: | the DNS: | |||
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" | |||
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" | |||
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" | |||
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" | |||
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") | |||
Appendix D. Removal of Key Granularity | C.1. Compatibility with DomainKeys Key Records | |||
An important change since [RFC4871] is the removal of the "g=" tag | DKIM key records were designed to be backwards-compatible in many | |||
from key records, which enabled signers to constrain use of a signing | cases with key records used by DomainKeys [RFC4870] (sometimes | |||
key to specific users by requiring a match to the local-part of the | referred to as "selector records" in the DomainKeys context). One | |||
"i=" tag. [RFC4871] also discussed enabling backward compatibility | area of incompatibility warrants particular attention. The "g=" tag/ | |||
with DomainKeys [RFC4870] when "g=" is present without a value. | value may be used in DomainKeys and [RFC4871] key records to provide | |||
finer granularity of the validity of the key record to a specific | ||||
local-part. A null "g=" value in DomainKeys is valid for all | ||||
addresses in the domain. This differs from the usage in the original | ||||
DKIM specification, where a null "g=" value is not valid for any | ||||
address. In particular, the example public key record in Section | ||||
3.2.3 of [RFC4870] with DKIM. | ||||
As use of "g=" is now deprecated, a verifier compliant with this | Although the "g=" tag has been deprecated in this version of the DKIM | |||
document will now ignore that tag completely for records that still | specification, signers are advised not to include the "g=" tag in key | |||
contain it. Signers should thus be aware that compliant verifiers | records because some [RFC4871]-compliant verifiers will be in use for | |||
will no longer constrain use of the key based on any value found in a | a considerable period to come. | |||
"g=" tag. | ||||
Appendix E. MUA Considerations | Appendix D. MUA Considerations | |||
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 | |||
the address in an alternate view, or it might even rewrite the | the address in an alternate view, or it might even rewrite the | |||
original From address using the verified information. Some MUAs | original From address using the verified information. Some MUAs | |||
skipping to change at page 75, line 20 | skipping to change at page 75, line 24 | |||
unsigned header fields in a way that might be construed by the end | unsigned header fields in a way that might be construed by the end | |||
user as having been signed. If the message has an l= tag whose value | user as having been signed. If the message has an l= tag whose value | |||
does not extend to the end of the message, the MUA might also hide or | does not extend to the end of the message, the MUA might also hide or | |||
mark the portion of the message body that was not signed. | mark the portion of the message body that was not signed. | |||
The aforementioned information is not intended to be exhaustive. The | The aforementioned information is not intended to be exhaustive. The | |||
MUA may choose to highlight, accentuate, hide, or otherwise display | MUA may choose to highlight, accentuate, hide, or otherwise display | |||
any other information that may, in the opinion of the MUA author, be | any other information that may, in the opinion of the MUA author, be | |||
deemed important to the end user. | deemed important to the end user. | |||
Appendix F. Acknowledgements | Appendix E. Acknowledgements | |||
The previous IETF version of DKIM [RFC4871] was edited by: Eric | The previous IETF version of DKIM [RFC4871] was edited by: Eric | |||
Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael | Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael | |||
Thomas. | Thomas. | |||
That specification was the result of an extended, collaborative | That specification was the result of an extended, collaborative | |||
effort, including participation by: Russ Allbery, Edwin Aoki, Claus | effort, including participation by: Russ Allbery, Edwin Aoki, Claus | |||
Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve | Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve | |||
Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis | Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis | |||
Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark | Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark | |||
End of changes. 35 change blocks. | ||||
70 lines changed or deleted | 82 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/ |