draft-ietf-dkim-rfc4871-errata-00.txt		draft-ietf-dkim-rfc4871-errata-01.txt
	DKIM D. Crocker, Ed.		DKIM D. Crocker, Ed.
	Internet-Draft Brandenburg InternetWorking		Internet-Draft Brandenburg InternetWorking
	Intended status: Standards Track January 25, 2009		Intended status: Standards Track February 2, 2009
	Expires: July 29, 2009		Expires: August 6, 2009
	RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Errata		RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Errata
	draft-ietf-dkim-rfc4871-errata-00		draft-ietf-dkim-rfc4871-errata-01
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 29, 2009.		This Internet-Draft will expire on August 6, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 21		skipping to change at page 2, line 21
	Email: dcrocker@bbiw.net		Email: dcrocker@bbiw.net
	Type		Type
	Technical		Technical
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Section 2.7 Identity Assessor . . . . . . . . . . . . . . . . . 3		2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Section 2.8 Signing Domain Identifier (SDID) . . . . . . . . . 3		3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . . 3
	4. Section 2.9 User Agent Identifier (UAID) . . . . . . . . . . . 4		4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4
	5. Section 3.9 Relationship Between SDID and UAID . . . . . . . . 4		5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4
	6. Section 3.5 The DKIM-Signature Header Field . . . . . . . . . . 5		6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4
	7. Section 3.5 The DKIM-Signature Header Field . . . . . . . . . . 5		7. RFC4871 Section 2.10 User Agent Identifier (UAID) . . . . . . . 4
	8. Section 3.8. Signing by Parent Domains . . . . . . . . . . . . 5		8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5
	9. Section 6.3. Interpret Results/Apply Local Policy . . . . . . 6		9. RFC4871 Section 3.9 Relationship Between SDID and UAID . . . . 5
	10. Section 6.3. Interpret Results/Apply Local Policy . . . . . . 6		10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . . 6
	11. Appendix D. MUA Considerations . . . . . . . . . . . . . . . . 7		11. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . . 6
	12. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		12. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . . 6
	13. Normative References . . . . . . . . . . . . . . . . . . . . . 7		13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 7
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7		14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . . 8
			16. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
			17. Normative References . . . . . . . . . . . . . . . . . . . . . 8
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	About the purpose for DKIM, [RFC4871] states:		About the purpose for DKIM, [RFC4871] states:
	The ultimate goal of this framework is to permit a signing domain		The ultimate goal of this framework is to permit a signing domain
	to assert responsibility for a message, thus protecting message		to assert responsibility for a message, thus protecting message
	signer identity...		signer identity...
	Hence, DKIM has a signer, a validator and a consumer of the validated		Hence, DKIM has a signer that produces a signed message, a verifier
	signing domain. In effect, the purpose of DKIM is to communicate		that confirms the signature and an assessor that consumes the
	that "responsible" domain name to a receive-side consuming module.		validated signing domain. so the simple purpose of DKIM is to
	For DKIM to be interoperable and useful, signer and consumer must		communicate an identifier to a receive-side assessor module. The
	share the same understanding of the details about the name.		identifier is in the form of a domain name that refers to a
			responsible identity. For DKIM to be interoperable and useful,
			signer and assessor must share the same understanding of the details
			about the identifier.
	However the specification defines two, potentially different		However the specification defines two, potentially different
	identifiers that are carried in the DKIM-Signature: header field and		identifiers that are carried in the DKIM-Signature: header field and
	might be delivered to a receiving processing module that consumes		might be delivered to a receiving processing module that consumes
	validated payload. The DKIM specification fails to clearly define		validated payload. The DKIM specification fails to clearly define
	what is "payload" to be delivered to a consuming module, versus what		what is "payload" to be delivered to a consuming module, versus what
	is internal and merely in support of achieving payload delivery.		is internal and merely in support of achieving payload delivery.
	This currently leaves signers and consumers with the potential for		This currently leaves signers and assessors with the potential for
	having differing -- and therefore non-interoperable --		having differing -- and therefore non-interoperable --
	interpretations of how DKIM operates.		interpretations of how DKIM operates.
	This erratum resolves this confusion. It defines new labels for the		This erratum resolves this confusion. It defines new labels for the
	two values, clarifies their nature, and specifies and their		two values, clarifies their nature, and specifies and their
	relationship.		relationship.
	2. Section 2.7 Identity Assessor		2. RFC 4871 Abstract
			Original Text: The ultimate goal of this framework is to permit a
			signing domain to assert responsibility
			Corrected Text: The ultimate goal of this framework is to permit a
			person, role or organization that owns the signing domain to
			assert responsibility
			3. RFC4871 Section 1. Introduction
			Original Text: permitting a signing domain to claim responsibility
			Corrected Text: permitting a person, role or organization that owns
			the signing domain to claim responsibility
			4. RFC4871 Section 2.7 Identity
			A person, role or organization.
	Original Text: (None. Additional text.)		Original Text: (None. Additional text.)
	Corrected Text: The name of the module which consumes DKIM's		Corrected Text: A person, role or organization.
	primary payload, the responsible Signing Domain Identifier (SDID).
	It can optionally consume the User Agent Identifier (UAID) value,
	if provided to the module. Details of this module are outside the
	scope of the DKIM specification.
	3. Section 2.8 Signing Domain Identifier (SDID)		5. RFC4871 Section 2.8 Identifier
	Original Text: (None. Additional text.)		Original Text: (None. Additional text.)
			Corrected Text: A label that refers to an identity.
			6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
			Original Text: (None. Additional text.)
	Corrected Text: A single, opaque value that is the mandatory		Corrected Text: A single, opaque value that is the mandatory
	payload output of DKIM and which refers to the identity claiming		payload output of DKIM and that refers to the identity claiming
	responsibility for the introduction of a message into the mail		responsibility for the introduction of a message into the mail
	stream.		stream. Within the scope of the DKIM Signing specification, the
			conventions and semantics used by a signer to create and use a
			specific SDID are outside the scope of the DKIM Signing
			specification, as is any use of those conventions and semantics.
	4. Section 2.9 User Agent Identifier (UAID)		7. RFC4871 Section 2.10 User Agent Identifier (UAID)
	Original Text: (None. Additional text.)		Original Text: (None. Additional text.)
	Corrected Text: A single, opaque value that is the optional,		Corrected Text: A single, opaque value that is the optional,
	additional payload output of DKIM and which identifies the user or		additional payload output of DKIM and that identifies the user or
	agent on behalf of whom the SDID has taken responsibility.		agent on behalf of whom the SDID has taken responsibility. The
			conventions and semantics used by a signer to create and use a
			specific UAID are outside the scope of the DKIM Signing
			specification, as is any use of those conventions and semantics.
	5. Section 3.9 Relationship Between SDID and UAID		8. RFC4871 Section 2.11 Identity Assessor
			Original Text: (None. Additional text.)
			Corrected Text: The name of the module that consumes DKIM's primary
			payload, the responsible Signing Domain Identifier (SDID). It can
			optionally consume the User Agent Identifier (UAID) value, if
			provided to the module. The conventions and semantics used by a
			signer to create and use a specific SDID or UAID are outside the
			scope of the DKIM Signing specification, as is any use of those
			conventions and semantics.
			9. RFC4871 Section 3.9 Relationship Between SDID and UAID
	Original Text: (None. This is an addition.)		Original Text: (None. This is an addition.)
	Corrected Text: DKIM's primary task is to communicate from the		Corrected Text: DKIM's primary task is to communicate from the
	Signer to a recipient-side Identity Assessor a single, responsible		Signer to a recipient-side Identity Assessor a single, Signing
	Signing Domain Identifier (SDID). The SDID MUST be the value of		Domain Identifier (SDID) that identifies a responsible identity.
	the d= tag. DKIM MAY optionally provide a single responsible User		The SDID MUST be the value of the d= tag. DKIM MAY optionally
	Agent Identifier (UAID); if the UAID is present, it MUST be the		provide a single responsible User Agent Identifier (UAID); if the
	value of the i= tag.		UAID is present, it MUST be the value of the i= tag.
	The SDID MUST correspond to a valid DNS name under which the DKIM		The SDID MUST correspond to a valid DNS name under which the DKIM
	key record is published.		key record is published.
	The UAID is specified as having the same syntax as an email		The UAID is specified as having the same syntax as an email
	address, but is not required to have the same semantics. Notably,		address, but is not required to have the same semantics. Notably,
	the domain name is not required to be registered in the DNS -- so		the domain name is not required to be registered in the DNS -- so
	it might not resolve in a query -- and the Local-part MAY be drawn		it might not resolve in a query -- and the Local-part MAY be drawn
	from a namespace that does not contain the user's mailbox. The		from a namespace that does not contain the user's mailbox. The
	details of the structure and semantics for the namespace are		details of the structure and semantics for the namespace are
	determined by -- and known only to -- the Signer. The Signer MAY		determined by the Signer. Any knowledge or use of those details
	choose to use the same namespace for its UAIDs as its users' email		by verifiers or assessors is outside the scope of the DKIM Signing
	addresses, or MAY choose other means of representing its users.		specification. The Signer MAY choose to use the same namespace
	However, the signer SHOULD use the same UAID for each message		for its UAIDs as its users' email addresses, or MAY choose other
	intended to be evaluated as being within the same sphere of		means of representing its users. However, the signer SHOULD use
	responsibility, if it wishes to offer receivers the option of		the same UAID for each message intended to be evaluated as being
	using the UAID as a finer grained, stable identifier than the		within the same sphere of responsibility, if it wishes to offer
	SDID.		receivers the option of using the UAID as a finer grained, stable
			identifier than the SDID.
	Hence, DKIM delivers to receive-side Identity Assessors		Hence, DKIM delivers to receive-side Identity Assessors
	responsible Identifiers that are individual, opaque values. Their		responsible Identifiers that are individual, opaque values. Their
	sub-structures and particular semantics are not publicly defined		sub-structures and particular semantics are not publicly defined
	and, therefore, cannot be assumed by an Identity Assessor.		and, therefore, cannot be assumed by an Identity Assessor.
	A receive-side DKIM validator MUST communicate the Signing Domain		A receive-side DKIM verifier MUST communicate the Signing Domain
	Identifier (d=) to a consuming Identity Assessor module and MAY		Identifier (d=) to a consuming Identity Assessor module and MAY
	communicate the User Agent Identifier (i=) if present.		communicate the User Agent Identifier (i=) if present.
	To the extent that a receiver chooses to attempt to interpret any		To the extent that a receiver attempts to intuit any structured
	structured semantics for either of the identifiers, this is a		semantics for either of the identifiers, this is a heuristic
	heuristic function that is outside the scope of DKIM's		function that is outside the scope of DKIM's specification and
	specification and semantics. Hence it is relegated to a higher-		semantics. Hence it is relegated to a higher-level service, such
	level service, such as a delivery handling filter that integrates		as a delivery handling filter that integrates a variety of inputs
	a variety of inputs and performs heuristic analysis of them.		and performs heuristic analysis of them.
	6. Section 3.5 The DKIM-Signature Header Field		10. RFC4871 Section 3.5 The DKIM-Signature Header Field
	Original Text: d= The domain of the signing entity.		Original Text: d= The domain of the signing entity.
	Corrected Text: d= Specifies the SDID claiming responsibility for		Corrected Text: d= Specifies the SDID claiming responsibility for
	the introduction of a message into the mail stream.		an introduction of a message into the mail stream.
	7. Section 3.5 The DKIM-Signature Header Field		11. RFC4871 Section 3.5 The DKIM-Signature Header Field
	Original Text: i= Identity of the user or agent (e.g., a mailing		Original Text: i= Identity of the user or agent (e.g., a mailing
	list manager) on behalf of which this message is signed		list manager) on behalf of which this message is signed
	Corrected Text: i= The responsible User Agent Identifier (UAID) on		Corrected Text: i= The responsible User Agent Identifier (UAID) on
	behalf of which the SDID is taking responsibility.		behalf of which the SDID is taking responsibility.
	8. Section 3.8. Signing by Parent Domains		12. RFC4871 Section 3.8. Signing by Parent Domains
	the section where the error appears		the section where the error appears
	Original Text: e.g., a key record for the domain example.com can be		Original Text: e.g., a key record for the domain example.com can be
	used to verify messages where the signing identity ("i=" tag of		used to verify messages where the signing identity ("i=" tag of
	the signature) is sub.example.com, or even sub1.sub2.example.com.		the signature) is sub.example.com, or even sub1.sub2.example.com.
	In order to limit the capability of such keys when this is not		In order to limit the capability of such keys when this is not
	intended, the "s" flag may be set in the "t=" tag of the key		intended, the "s" flag may be set in the "t=" tag of the key
	record to constrain the validity of the record to exactly the		record to constrain the validity of the record to exactly the
	domain of the signing identity. If the referenced key record		domain of the signing identity. If the referenced key record
	skipping to change at page 6, line 16		skipping to change at page 7, line 16
	tag of the signature) is sub.example.com, or even		tag of the signature) is sub.example.com, or even
	sub1.sub2.example.com. In order to limit the capability of such		sub1.sub2.example.com. In order to limit the capability of such
	keys when this is not intended, the "s" flag MAY be set in the		keys when this is not intended, the "s" flag MAY be set in the
	"t=" tag of the key record, to constrain the validity of the		"t=" tag of the key record, to constrain the validity of the
	domain of the UAID. If the referenced key record contains the "s"		domain of the UAID. If the referenced key record contains the "s"
	flag as part of the "t=" tag, the domain of the UAID ("i=" flag)		flag as part of the "t=" tag, the domain of the UAID ("i=" flag)
	MUST be the same as that of the SDID (d=) domain. If this flag is		MUST be the same as that of the SDID (d=) domain. If this flag is
	absent, the domain of the UAID MUST be the same as, or a subdomain		absent, the domain of the UAID MUST be the same as, or a subdomain
	of, the SDID.		of, the SDID.
	9. Section 6.3. Interpret Results/Apply Local Policy		13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy
	Original Text: It is beyond the scope of this specification to		Original Text: It is beyond the scope of this specification to
	describe what actions a verifier system should make, but an		describe what actions a verifier system should make, but an
	authenticated email presents an opportunity to a receiving system		authenticated email presents an opportunity to a receiving system
	that unauthenticated email cannot. Specifically, an authenticated		that unauthenticated email cannot. Specifically, an authenticated
	email creates a predictable identifier by which other decisions		email creates a predictable identifier by which other decisions
	can reliably be managed, such as trust and reputation.		can reliably be managed, such as trust and reputation.
	Corrected Text: It is beyond the scope of this specification to		Corrected Text: It is beyond the scope of this specification to
	describe what actions an Identity Assessor can make, but mail		describe what actions an Identity Assessor can make, but mail
	carrying a validated SDID presents an opportunity to an Identity		carrying a validated SDID presents an opportunity to an Identity
	Assessor that unauthenticated email does not Specifically, an		Assessor that unauthenticated email does not Specifically, an
	authenticated email creates a predictable identifier by which		authenticated email creates a predictable identifier by which
	other decisions can reliably be managed, such as trust and		other decisions can reliably be managed, such as trust and
	reputation.		reputation.
	10. Section 6.3. Interpret Results/Apply Local Policy		14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy
	Original Text: Once the signature has been verified, that		Original Text: Once the signature has been verified, that
	information MUST be conveyed to higher-level systems (such as		information MUST be conveyed to higher-level systems (such as
	explicit allow/whitelists and reputation systems) and/or to the		explicit allow/whitelists and reputation systems) and/or to the
	end user. If the message is signed on behalf of any address other		end user. If the message is signed on behalf of any address other
	than that in the From: header field, the mail system SHOULD take		than that in the From: header field, the mail system SHOULD take
	pains to ensure that the actual signing identity is clear to the		pains to ensure that the actual signing identity is clear to the
	reader.		reader.
	Corrected Text: Once the signature has been verified, that		Corrected Text: Once the signature has been verified, that
	information MUST be conveyed to the Identity Assessor (such as an		information MUST be conveyed to the Identity Assessor (such as an
	explicit allow/whitelist and reputation system) and/or to the end		explicit allow/whitelist and reputation system) and/or to the end
	user. If the UAID is not the same as the address in the From:		user. If the SDID is not the same as the address in the From:
	header field, the mail system SHOULD take pains to ensure that the		header field, the mail system SHOULD take pains to ensure that the
	actual UAID is clear to the reader.		actual SDID is clear to the reader.
	11. Appendix D. MUA Considerations		15. RFC4871 Appendix D. MUA Considerations
	Original Text: The tendency is to have the MUA highlight the		Original Text: The tendency is to have the MUA highlight the
	address associated with this signing identity in some way, in an		address associated with this signing identity in some way, in an
	attempt to show the user the address from which the mail was sent.		attempt to show the user the address from which the mail was sent.
	Corrected Text: The tendency is to have the MUA highlight the UAID,		Corrected Text: The tendency is to have the MUA highlight the SDID,
	in an attempt to show the user the identity that is claiming		in an attempt to show the user the identity that is claiming
	responsibility for the message.		responsibility for the message.
	12. Security Considerations		16. Security Considerations
	This Errata document clarifies core details about DKIM's payload. As		This Errata document clarifies core details about DKIM's payload. As
	such it affects interoperability, semantic characterization, and the		such it affects interoperability, semantic characterization, and the
	expectations for the identifiers carried with a DKIM signature.		expectations for the identifiers carried with a DKIM signature.
	Clarification of these details is likely to limit misinterpretation		Clarification of these details is likely to limit misinterpretation
	of DKIM's semantics. Since DKIM is fundamentally a security		of DKIM's semantics. Since DKIM is fundamentally a security
	protocol, this should improve its security characteristics.		protocol, this should improve its security characteristics.
	13. Normative References		17. Normative References
	[RFC4871] Sendmail, Inc., PGP Corporation, Yahoo! Inc, Yahoo! Inc,		[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
	Cisco Systems, Inc., and Cisco Systems, Inc., "DomainKeys		J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
	Identified Mail (DKIM) Signatures", RFC 4871, May 2007.		Signatures", RFC 4871, May 2007.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This document was initially formulated by an ad hoc design team,		This document was initially formulated by an ad hoc design team,
	comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray		comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray
	Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel,		Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel,
	Wietse Venema. It represents a rough consensus of that effort,		Wietse Venema. It represents a rough consensus of that effort,
	although the final wording of the submitted draft is the sole		although the final wording of the submitted draft is the sole
	responsibility (d=) of the listed author.		responsibility (d=) of the listed author.
End of changes. 32 change blocks.
	72 lines changed or deleted		118 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/