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/