draft-ietf-dkim-overview-08.txt		draft-ietf-dkim-overview-09.txt
	DomainKeys Identified Mail T. Hansen		DomainKeys Identified Mail T. Hansen
	Internet-Draft AT&T Laboratories		Internet-Draft AT&T Laboratories
	Intended status: Informational D. Crocker		Intended status: Informational D. Crocker
	Expires: August 14, 2008 Brandenburg InternetWorking		Expires: August 28, 2008 Brandenburg InternetWorking
	P. Hallam-Baker		P. Hallam-Baker
	VeriSign Inc.		VeriSign Inc.
	February 11, 2008		February 25, 2008
	DomainKeys Identified Mail (DKIM) Service Overview		DomainKeys Identified Mail (DKIM) Service Overview
	draft-ietf-dkim-overview-08		draft-ietf-dkim-overview-09
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 August 14, 2008.		This Internet-Draft will expire on August 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document provides an overview of the DomainKeys Identified Mail		This document provides an overview of the DomainKeys Identified Mail
	(DKIM) service and describes how it can fit into a messaging service.		(DKIM) service and describes how it can fit into a messaging service.
	It also describes how DKIM relates to other IETF message signature		It also describes how DKIM relates to other IETF message signature
	technologies. It is intended for those who are adopting, developing,		technologies. It is intended for those who are adopting, developing,
	or deploying DKIM. DKIM allows an organization to take		or deploying DKIM. DKIM allows an organization to take
	responsibility for transmitting a message, in a way that can be		responsibility for transmitting a message, in a way that can be
	validated by a recipient. The organization can be the author's, the		validated by a recipient. The organization can be the author's, the
	originating sending site, an intermediary, or one of their agents.		originating sending site, an intermediary, or one of their agents.
	An organization may use one or more domain names to accomplish this.		An organization may use one or more domain names to accomplish this.
	DKIM defines a domain-level digital signature authentication		DKIM defines a domain-level digital signature authentication
	framework for email, using public-key cryptography and key server		framework for email, using public-key cryptography and key server
	technology [RFC4871]. This permits verifying a message source, an		technology [RFC4871]. This permits verification of a message source,
	intermediary, or one of their agents, as well as the integrity of its		an intermediary, or one of their agents, as well as the integrity of
	contents. DKIM will also provide a mechanism that permits potential		its contents. DKIM will also provide a mechanism that permits
	email signers to publish information about their email signing		potential email signers to publish information about their email
	practices; this will permit email receivers to make additional		signing practices; this will permit email receivers to make
	assessments about messages. Such protection of email identity can		additional assessments about messages. Such protection of email
	assist in the global control of "spam" and "phishing".		identity can assist in the global control of "spam" and "phishing".
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 6		1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 6
	1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6		1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6
	2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6		2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6
	2.1. Identity Verification . . . . . . . . . . . . . . . . . . 6		2.1. Identity Verification . . . . . . . . . . . . . . . . . . 7
	2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 7		2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 7
	3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 7		3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 9		3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 9
	4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 10		4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. The Basic Signing Service . . . . . . . . . . . . . . . . 11		4.1. The Basic Signing Service . . . . . . . . . . . . . . . . 11
	4.2. Characteristics of a DKIM signature . . . . . . . . . . . 11		4.2. Characteristics of a DKIM signature . . . . . . . . . . . 11
	4.3. The Selector construct . . . . . . . . . . . . . . . . . . 11		4.3. The Selector construct . . . . . . . . . . . . . . . . . . 11
	4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 12		4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 13		5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Administration and Maintenance . . . . . . . . . . . . . . 15		5.1. Administration and Maintenance . . . . . . . . . . . . . . 15
	5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 16		5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 16
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	9. Informative References . . . . . . . . . . . . . . . . . . . . 17		9. Informative References . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. Internet Mail Background . . . . . . . . . . . . . . 19		Appendix A. Internet Mail Background . . . . . . . . . . . . . . 19
	A.1. Administrative Management Domain (ADMD) . . . . . . . . . 19		A.1. Administrative Management Domain (ADMD) . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 23		Intellectual Property and Copyright Statements . . . . . . . . . . 23
	1. Introduction		1. Introduction
	This document provides a description of the architecture and		This document provides a description of the architecture and
	functionality for DomainKeys Identified Mail (DKIM). It is intended		functionality for DomainKeys Identified Mail (DKIM). It is intended
	for those who are adopting, developing, or deploying DKIM. It also		for those who are adopting, developing, or deploying DKIM. It will
	will be helpful for those who are considering extending DKIM, either		also be helpful for those who are considering extending DKIM, either
	into other areas of use or to support additional features. This		into other areas of use or to support additional features. This
	Overview does not provide information on threats to DKIM or email, or		overview does not provide information on threats to DKIM or email, or
	details on the protocol specifics, which can be found in [RFC4686]		details on the protocol specifics, which can be found in [RFC4686]
	and [RFC4871], respectively. The document assumes a background in		and [RFC4871], respectively. The document assumes a background in
	basic email and network security technology and services.		basic email and network security technology and services.
	DKIM allows an organization to take responsibility for a message, in		DKIM allows an organization to take responsibility for a message, in
	a way that can be validated by a recipient. The organization can be		a way that can be validated by a recipient. The organization can be
	the author's, the originating sending site, an intermediary, or one		the author's, the originating sending site, an intermediary, or one
	of their agents. DKIM defines a domain-level digital signature		of their agents. DKIM defines a domain-level digital signature
	authentication framework for email through the use of public-key		authentication framework for email through the use of public-key
	cryptography and key server technology. [RFC4871] It permits		cryptography and key server technology. [RFC4871] It permits
	verifying the signer of a message, as well as the integrity of its		verification of the signer of a message, as well as the integrity of
	contents. DKIM will also provide a mechanism that permits potential		its contents. DKIM will also provide a mechanism that permits
	email signers to publish information about their email signing		potential email signers to publish information about their email
	practices; this will permit email receivers to make additional		signing practices; this will permit email receivers to make
	assessments of unsigned messages. Such protection of email identity		additional assessments of unsigned messages. Such protection of
	can assist in the global control of "spam" and "phishing".		email identity can assist in the global control of "spam" and
			"phishing".
	Neither this document nor DKIM attempts to provide solutions to the		Neither this document nor DKIM attempts to provide solutions to the
	world's problems with spam, phishing, virii, worms, joe jobs, etc.		world's problems with spam, phishing, virii, worms, joe jobs, etc.
	DKIM provides one basic tool, in what needs to be a large arsenal,		DKIM provides one basic tool, in what needs to be a large arsenal,
	for improving basic trust in the Internet mail service. However by		for improving basic trust in the Internet mail service. However by
	itself, DKIM is not sufficient to that task and this Overview does		itself, DKIM is not sufficient to that task and this overview does
	not pursue the issues of integrating DKIM into these larger efforts,		not pursue the issues of integrating DKIM into these larger efforts,
	beyond a simple reference within a system diagram. Rather, it is a		beyond a simple reference within a system diagram. Rather, it is a
	basic introduction to the technology and its use.		basic introduction to the technology and its use.
	1.1. DKIM's Scope		1.1. DKIM's Scope
	DKIM signatures can be created by a direct handler of a message,		DKIM signatures can be created by a direct handler of a message,
	either as its author or as an intermediary. It can also be created		either as its author or as an intermediary. It can also be created
	by an independent service that is providing assistance to a handler		by an independent service that is providing assistance to a handler
	of the message. Whoever does the signing chooses the domain name to		of the message. Whoever does the signing chooses the domain name to
	be used as the basis for later assessments. Hence, the reputation		be used as the basis for later assessments. Hence, the reputation
	associated with that domain name is an additional basis for		associated with that domain name is an additional basis for
	evaluating whether to trust the message for delivery. The owner of		evaluating whether to trust the message for delivery. The owner of
	the domain name being used for a DKIM signature is declaring that		the domain name being used for a DKIM signature is declaring that
	they have some degree of accountability for the message.		they accept responsibility for the message and may thus be held
			accountable for it.
	DKIM is a value-added feature for email. Mail that is not signed by
	DKIM is handled in the same way as it was before DKIM was defined.
	The message will be evaluated by established analysis and filtering		DKIM is intended as a value-added feature for email. Mail that is
	techniques. (A signing policy may provide additional information for		not signed by DKIM is handled in the same way as it was before DKIM
	that analysis and filtering.) Over time, widespread DKIM adoption		was defined. The message will be evaluated by established analysis
	could permit more strict handling of messages that are not signed.		and filtering techniques. (A signing policy may provide additional
	However early benefits do not require this and probably do not		information for that analysis and filtering.) Over time, widespread
	warrant this.		DKIM adoption could permit more strict handling of messages that are
			not signed. However early benefits do not require this and probably
			do not warrant this.
	It is important to be clear about the narrow scope of DKIM's		DKIM's capabilities have a narrow scope. It is an enabling
	capabilities. It is an enabling technology, intended for use in the		technology, intended for use in the larger context of determining
	larger context of determining message legitimacy. This larger		message legitimacy. This larger context is complex, so it is easy to
	context is complex, so it is easy to assume that a component like		assume that a component like DKIM, which actually provides only a
	DKIM, which actually provides only a limited service, instead		limited service, instead satisfies the broader set of requirements.
	satisfies the broader set of requirements.
	A DKIM signature:		By itself, a DKIM signature:
	o Does not offer any assertions about the behaviors of the identity		o Does not offer any assertions about the behaviors of the identity
	doing the signing.		doing the signing.
	o Does not prescribe any specific actions for receivers to take upon		o Does not prescribe any specific actions for receivers to take upon
	successful signature verification.		successful signature verification.
	o Does not provide protection after signature verification.		o Does not provide protection after signature verification.
	o Does not protect against re-sending (replay of) a message that		o Does not protect against re-sending (replay of) a message that
	skipping to change at page 4, line 44		skipping to change at page 4, line 45
	1.2. Prior Work		1.2. Prior Work
	Historically, email delivery assessment decisions have been based on		Historically, email delivery assessment decisions have been based on
	an identity that used the IP Address of the system that directly sent		an identity that used the IP Address of the system that directly sent
	the message (that is, the previous email "hop"), [RFC4408] or on the		the message (that is, the previous email "hop"), [RFC4408] or on the
	message content (e.g. [RFC4406] and [RFC4407]). The IP Address is		message content (e.g. [RFC4406] and [RFC4407]). The IP Address is
	obtained via underlying Internet information mechanisms and is		obtained via underlying Internet information mechanisms and is
	therefore trusted to be accurate. Besides having some known security		therefore trusted to be accurate. Besides having some known security
	weaknesses, the use of addresses presents a number of functional and		weaknesses, the use of addresses presents a number of functional and
	operational problems. Consequently there is an industry desire to		operational problems. Consequently there is a widespread desire to
	use an identifier that has better correspondence to organizational		use an identifier that has better correspondence to organizational
	boundaries. Domain names are viewed as often satisfying this need.		boundaries. Domain names are viewed as often satisfying this need.
	There have been four previous IETF efforts at standardizing an		There have been four previous IETF efforts at standardizing an
	Internet email signature scheme. Their goals have differed from		Internet email signature scheme. Their goals have differed from
	those of DKIM.		those of DKIM.
	o Privacy Enhanced Mail (PEM) was first published in 1987.		o Privacy Enhanced Mail (PEM) was first published in 1987.
	[RFC0989]		[RFC0989]
	o PEM eventually transformed into MIME Object Security Services		o PEM eventually transformed into MIME Object Security Services
	(MOSS) in 1995. [RFC1848] Today, these two are only of historical		(MOSS) in 1995. [RFC1848] Today, these two are only of historical
	interest.		interest.
	o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and		o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
	first released in 1991. [RFC1991] A later version was		first released in 1991. [RFC1991] A later version was
	standardized as OpenPGP. [RFC2440] [RFC3156]		standardized as OpenPGP. [RFC2440] [RFC3156] [RFC4880]
	[I-D.ietf-openpgp-rfc2440bis]
	o RSA Security independently developed Secure MIME (S/MIME) to		o RSA Security independently developed Secure MIME (S/MIME) to
	transport a PKCS #7 data object. [RFC3851]		transport a PKCS #7 data object. [RFC3851]
	Development of both S/MIME and OpenPGP has continued. While each has		Development of both S/MIME and OpenPGP has continued. While each has
	achieved a significant user base, neither one has achieved ubiquity		achieved a significant user base, neither one has achieved ubiquity
	in deployment or use.		in deployment or use.
	To the extent that other message-signing services might have been		To the extent that other message-signing services might have been
	adapted to do the job that DKIM is designed to perform, it was felt		adapted to do the job that DKIM is designed to perform, it was felt
	skipping to change at page 6, line 25		skipping to change at page 6, line 25
	1.4. Discussion Venue		1.4. Discussion Venue
	NOTE TO RFC EDITOR: This "Discussion Venue" section is to be		NOTE TO RFC EDITOR: This "Discussion Venue" section is to be
	removed prior to publication.		removed prior to publication.
	This document is being discussed on the DKIM mailing list,		This document is being discussed on the DKIM mailing list,
	ietf-dkim@mipassoc.org.		ietf-dkim@mipassoc.org.
	2. The DKIM Value Proposition		2. The DKIM Value Proposition
	The nature and origins of a message are often falsely stated. DKIM		The nature and origins of a message are often falsely stated. Such
	provides a foundation for distinguishing legitimate mail, and thus a		misrepresentations may (but not necessarily) be employed in order to
	means of associating a verifiable identifier with a message. Given		perpetrate abuse. DKIM provides a foundation for distinguishing
	the presence of that identifier, a receiver can make decisions about		legitimate mail, and thus a means of associating a verifiable
	further handling of the message, based upon assessments of the		identifier with a message. Given the presence of that identifier, a
	identity that is associated with the identifier.		receiver can make decisions about further handling of the message,
			based upon assessments of the identity that is associated with the
			identifier.
	Receivers who successfully verify a signature can use information		Receivers who successfully verify a signature can use information
	about the signer as part of a program to limit spam, spoofing,		about the signer as part of a program to limit spam, spoofing,
	phishing, or other undesirable behavior. DKIM does not, itself,		phishing, or other undesirable behavior. DKIM does not, itself,
	prescribe any specific actions by the recipient; rather it is an		prescribe any specific actions by the recipient; rather it is an
	enabling technology for services that do.		enabling technology for services that do.
	These services will typically:		These services will typically:
	1. Determine a verified identity, if possible.		1. Determine a verified identity, if possible.
	skipping to change at page 8, line 21		skipping to change at page 8, line 23
	benefits of using domain names include simplifying key management,		benefits of using domain names include simplifying key management,
	enabling signing by the infrastructure as opposed to the MUA, and		enabling signing by the infrastructure as opposed to the MUA, and
	potential privacy issues.		potential privacy issues.
	Contrast this with OpenPGP and S/MIME, which provide end-to-end		Contrast this with OpenPGP and S/MIME, which provide end-to-end
	validation in terms of individual authors, notably using full email		validation in terms of individual authors, notably using full email
	addresses.		addresses.
	3.1.2. Implementation Locality		3.1.2. Implementation Locality
	DKIM signing and/or validating can be implemented anywhere along the		Any party, anywhere along the transit path can implement DKIM
	transit path, rather than only in the end systems or only in a		signing. Its use is not confined to the end systems or only in a
	boundary MTA.		boundary MTA.
	3.1.3. Allow delegation of signing to independent parties		3.1.3. Allow delegation of signing to independent parties
	Different parties have different roles in the process of email		Different parties have different roles in the process of email
	exchange. Some are easily visible to end users and others are		exchange. Some are easily visible to end users and others are
	primarily visible to operators of the service. DKIM needs to support		primarily visible to operators of the service. DKIM was designed to
	signing by any of these different parties and needs to permit them to		support signing by any of these different parties and to permit them
	sign with any domain name that they deem appropriate (and for which		to sign with any domain name that they deem appropriate (and for
	they are authorized.) As an example an organization that creates		which they hold authorized signing keys.) As an example an
	email content often delegates portions of its processing or		organization that creates email content often delegates portions of
	transmission to an outsourced group. DKIM supports this mode of		its processing or transmission to an outsourced group. DKIM supports
	activity, in a manner that is not normally visible to end users.		this mode of activity, in a manner that is not normally visible to
			end users.
	3.1.4. Distinguish the core authentication mechanism from its		3.1.4. Distinguish the core authentication mechanism from its
	derivative uses		derivative uses
	An authenticated identity can be subject to a variety of processing		An authenticated identity can be subject to a variety of processing
	policies, either ad hoc or standardized. The only semantics inherent		policies, either ad hoc or standardized. The only semantics inherent
	to a DKIM signature is that the signer is asserting (some)		to a DKIM signature is that the signer is asserting (some)
	responsibility for the message. All other mechanisms and meanings		responsibility for the message. All other mechanisms and meanings
	are built on this core service. One such mechanism might assert a		are built on this core service. One such mechanism might assert a
	relationship between the signing identity and the author, as		relationship between the signing identity and the author, as
	skipping to change at page 10, line 17		skipping to change at page 10, line 17
	schemes whereby authenticated mail from a known source with good		schemes whereby authenticated mail from a known source with good
	reputation is allowed to bypass some anti-abuse filters.		reputation is allowed to bypass some anti-abuse filters.
	In effect the email receiver is using their set of known		In effect the email receiver is using their set of known
	relationships to generate their own reputation data. This works		relationships to generate their own reputation data. This works
	particularly well for traffic between large sending providers and		particularly well for traffic between large sending providers and
	large receiving providers. However it also works well for any		large receiving providers. However it also works well for any
	operator, public or private, that has mail traffic dominated by		operator, public or private, that has mail traffic dominated by
	exchanges among a stable set of organizations.		exchanges among a stable set of organizations.
			Management of email deliverability problems currently represents a
			significant pain point for email administrators at every point on the
			mail transit path. Administrators who have deployed DKIM
			verification have an incentive to evangelize the use of DKIM
			signatures to senders who may subsequently complain that their email
			is not being delivered.
	3.2.4. Minimize the amount of required infrastructure		3.2.4. Minimize the amount of required infrastructure
	A new service, or an enhancement to an existing service, requires		A new service, or an enhancement to an existing service, requires
	adoption in a critical mass of system components, before it can be		adoption in a critical mass of system components, before it can be
	useful. The greater the number of required adopters, the higher the		useful. The greater the number of required adopters, the higher the
	adoption barrier. This becomes particularly serious when adoption is		adoption barrier. This becomes particularly serious when adoption is
	required by independent, intermediary -- that is, infrastructure --		required by independent, intermediary -- that is, infrastructure --
	service providers. In order to allow early adopters to gain early		service providers. In order to allow early adopters to gain early
	benefit, DKIM makes no changes to the core Internet Mail service and,		benefit, DKIM makes no changes to the core Internet Mail service and,
	instead, can provide a useful benefit for any individual pair of		instead, can provide a useful benefit for any individual pair of
	skipping to change at page 11, line 37		skipping to change at page 11, line 41
	such as From:, Date: and Subject:. By choosing the minimal set of		such as From:, Date: and Subject:. By choosing the minimal set of
	headers needed, the signature is likely to be considerably more		headers needed, the signature is likely to be considerably more
	robust against the handling vagaries of intermediary MTAs.		robust against the handling vagaries of intermediary MTAs.
	4.2. Characteristics of a DKIM signature		4.2. Characteristics of a DKIM signature
	A DKIM signature covers the message body and selected header fields.		A DKIM signature covers the message body and selected header fields.
	The signer computes a hash of the selected header fields and another		The signer computes a hash of the selected header fields and another
	hash of the body. The signer then uses a private key to		hash of the body. The signer then uses a private key to
	cryptographically encode this information, along with other signing		cryptographically encode this information, along with other signing
	parameters. Signature information is placed into a new [RFC2822]		parameters. Signature information is placed into the DKIM-Signature
	header field of the message.		header field, a new [RFC2822] header field of the message.
	4.3. The Selector construct		4.3. The Selector construct
	The key for a signature is associated with a domain name, as		The key for a signature is associated with a domain name, as
	specified in the d= DKIM-Signature header field parameters. That		specified in the d= parameter of the DKIM-Signature header. That
	domain name, or the domain name or address in the i= parameter,		domain name, or the domain name or address in the i= parameter,
	provide the complete identity used for making assessments about the		provide the complete identity used for making assessments about the
	signer. (The DKIM specification does not give any guidance on how to		signer. (The DKIM specification does not give any guidance on how to
	do an assessment.) However this name is not sufficient for making a		do an assessment.) However this name is not sufficient for making a
	DNS query to obtain the key needed to verify the signature.		DNS query to obtain the key needed to verify the signature.
	A single domain can use multiple signing keys and/or multiple		A single domain can use multiple signing keys and/or multiple
	potential signers. To support this, DKIM identifies a particular		potential signers. To support this, DKIM identifies a particular
	signature as a combination of the domain name and an added field,		signature as a combination of the domain name and an added field,
	called the "selector", coded into separate DKIM-Signature header		called the "selector", specified in separate DKIM-Signature header
	field parameters.		field parameters.
	NOTE: The selector is not intended to be part of the domain name		NOTE: The semantics of the selector (if any) are strictly reserved
	that is used for making assessments. Rather, the selector is		to the signer and should be treated as an opaque string by all
	strictly reserved for use in administering keys that are		other parties. If verifiers were to employ the selector as part
	associated with the domain name. If the selector becomes part of		of a name assessment mechanism, then there would be no remaining
	a name assessment mechanism, then there is no remaining mechanism		mechanism for making a transition from an old, or compromised, key
	for making a transition from an old, or compromised, key to a new		to a new one.
	one.
	Signers often need to support multiple assessments about their		Signers often need to support multiple assessments about their
	organization, such as to distinguish one type of message from		organization, such as to distinguish one type of message from
	another, or one portion of the organization from another. To permit		another, or one portion of the organization from another. To permit
	assessments that are independent, one method is for an organization		assessments that are independent, one method is for an organization
	to use different sub-domains in the "d=" parameter, such as		to use different sub-domains in the "d=" parameter, such as
	"transaction.example.com" versus "newsletter.example.com", or		"transaction.example.com" versus "newsletter.example.com", or
	"productA.example.com" versus "productB.example.com".		"productA.example.com" versus "productB.example.com".
	4.4. Verification		4.4. Verification
	skipping to change at page 15, line 26		skipping to change at page 15, line 26
	Note: Figure 1 does not show the effects on the message handling		Note: Figure 1 does not show the effects on the message handling
	when multiple signatures or non-author signatures are present.		when multiple signatures or non-author signatures are present.
	5.1. Administration and Maintenance		5.1. Administration and Maintenance
	A number of tables and services are used to provide external		A number of tables and services are used to provide external
	information. Each of these introduces administration and maintenance		information. Each of these introduces administration and maintenance
	requirements.		requirements.
	Key Store DKIM uses public/private (asymmetric) key technology. The		Key Store DKIM uses public/private (asymmetric) key cryptography.
	signer users a private key and the validator uses the		The signer users a private key and the validator uses the
	corresponding public key. The current DKIM signing specification		corresponding public key. The current DKIM signing specification
	provides for querying the Domain Names Service (DNS), to permit a		provides for querying the Domain Names Service (DNS), to permit a
	validator to obtain the public key. The signing organization		validator to obtain the public key. The signing organization
	therefore must have a means of adding a key to the DNS, for every		therefore must have a means of adding a key to the DNS, for every
	selector/domain-name combination. Further, the signing		selector/domain-name combination. Further, the signing
	organization needs policies for distributing and revising keys.		organization needs policies for distributing and revising keys.
	Reputation/Accreditation If a message contains a valid signature,		Reputation/Accreditation If a message contains a valid signature,
	then the verifier can evaluate the associated domain name's		then the verifier can evaluate the associated domain name's
	reputation. Quality-assessment information, which is associated		reputation. Quality-assessment information, which is associated
	skipping to change at page 17, line 41		skipping to change at page 17, line 41
	8. Acknowledgements		8. Acknowledgements
	Many people contributed to the development of the DomainKeys		Many people contributed to the development of the DomainKeys
	Identified Mail and the efforts of the DKIM Working Group is		Identified Mail and the efforts of the DKIM Working Group is
	gratefully acknowledged. In particular, we would like to thank Jim		gratefully acknowledged. In particular, we would like to thank Jim
	Fenton for his extensive feedback diligently provided on every		Fenton for his extensive feedback diligently provided on every
	version of this document.		version of this document.
	9. Informative References		9. Informative References
	[I-D.ietf-openpgp-rfc2440bis]
	Callas, J., "OpenPGP Message Format",
	draft-ietf-openpgp-rfc2440bis-22 (work in progress),
	April 2007.
	[I-D.kucherawy-sender-auth-header]		[I-D.kucherawy-sender-auth-header]
	Kucherawy, M., "Message Header Field for Indicating		Kucherawy, M., "Message Header Field for Indicating
	Message Authentication Status",		Message Authentication Status",
	draft-kucherawy-sender-auth-header-11 (work in progress),		draft-kucherawy-sender-auth-header-11 (work in progress),
	February 2008.		February 2008.
	[Kohnfelder]		[Kohnfelder]
	Kohnfelder, L., "Towards a Practical Public-key		Kohnfelder, L., "Towards a Practical Public-key
	Cryptosystem", May 1978.		Cryptosystem", May 1978.
	skipping to change at page 19, line 16		skipping to change at page 19, line 11
	Identified Mail (DKIM)", RFC 4686, September 2006.		Identified Mail (DKIM)", RFC 4686, September 2006.
	[RFC4870] Delany, M., "Domain-Based Email Authentication Using		[RFC4870] Delany, M., "Domain-Based Email Authentication Using
	Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,		Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
	May 2007.		May 2007.
	[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,		[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
	J., and M. Thomas, "DomainKeys Identified Mail (DKIM)		J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
	Signatures", RFC 4871, May 2007.		Signatures", RFC 4871, May 2007.
			[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
			Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
	Appendix A. Internet Mail Background		Appendix A. Internet Mail Background
	Internet Mail is split between the user world, in the form of Mail		Internet Mail is split between the user world, in the form of Mail
	User Agents (MUA), and the transmission world, in the form of the		User Agents (MUA), and the transmission world, in the form of the
	Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA).		Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA).
	The MHS is responsible for accepting a message from one user, the		The MHS is responsible for accepting a message from one user, the
	author, and delivering it to one or more other users, the recipients.		author, and delivering it to one or more other users, the recipients.
	This creates a virtual MUA-to-MUA exchange environment. The first		This creates a virtual MUA-to-MUA exchange environment. The first
	component of the MHS is called the Mail Submission Agent (MSA) and		component of the MHS is called the Mail Submission Agent (MSA) and
	the last is called the Mail Delivery Agent (MDA).		the last is called the Mail Delivery Agent (MDA).
End of changes. 28 change blocks.
	76 lines changed or deleted		82 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/