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/