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/