One document matched: draft-ietf-dkim-overview-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY ar PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kucherawy-sender-auth-header.xml'>
<!ENTITY rfc2440bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-openpgp-rfc2440bis.xml'>
<!ENTITY RFC1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc2821 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml'>
<!ENTITY rfc2822 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
<!ENTITY pem PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0989.xml'>
<!ENTITY moss PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1848.xml'>
<!ENTITY pgp1 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1991.xml'>
<!ENTITY rfc2440 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2440.xml'>
<!ENTITY rfc3156 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3156.xml'>
<!ENTITY syslog PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3164.xml'>
<!ENTITY rfc3851 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3851.xml'>
<!ENTITY dkimta PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4686.xml'>
<!ENTITY dkimbase PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4871.xml'>
<!ENTITY dk PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4870.xml'>
]>
<!-- 3 levels is messy --> <?rfc tocdepth="2" ?>
<!-- may be omitted for very short documents --> <?rfc toc="yes"?>
<!-- strict ID-nits compliance --> <?rfc strict="no"?>
<!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes"?> <?rfc subcompact="no"?>
<!-- use symbolic cross references instead of [1], and sort them -->
<?rfc symrefs="yes"?> <?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!-- other categories: bcp, exp, historic, std -->
<rfc category="info" ipr="full3978">
<front>
<title abbrev="DKIM Service Overview">DomainKeys Identified Mail (DKIM)
Service Overview</title>
<!-- add 'role="editor"' below for the editors if the requiring designation -->
<author fullname="Tony Hansen" initials="T." surname="Hansen">
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave.</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>tony+dkimov@maillennium.att.com </email>
</address>
</author>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author fullname="Phillip Hallam-Baker" initials="P."
surname="Hallam-Baker">
<organization>VeriSign Inc.</organization>
<address>
<email>pbaker@verisign.com</email>
</address>
</author>
<date year="2007" />
<area>Security</area>
<!-- WG name at the upperleft corner of the doc, IETF fine for individual submissions -->
<workgroup>DomainKeys Identified Mail</workgroup>
<keyword>Email</keyword>
<keyword>Electronic Mail</keyword>
<keyword>Internet Mail</keyword>
<keyword>Message Verification</keyword>
<abstract>
<t>DomainKeys Identified Mail (DKIM)
allows an organization to take responsibility for a message, in a
way that can be validated by a recipient. The organization can be
the author's, the originating sending site, an intermediary, or
one of their agent's. DKIM defines a domain-level digital
signature authentication framework for email, using public-key
cryptography and key server technology. This permits verifying the
signer of a message, as well as the integrity of its contents.
DKIM accomplishes this by defining a domain-level authentication
framework for email using public-key cryptography and key server
technology <xref target="RFC4871" />. This permits verifying a
message source, an intermediary, or one of their agents, as well
as the integrity of its contents. DKIM will also provide a
mechanism that permits potential email signers to publish
information about their email signing practices; this will permit
email receivers to make additional assessments of unsigned
messages. Such protection of email identity can assist in the
global control of "spam" and "phishing". This document provides an
overview of the DKIM service and describes how it can fit into a
messaging service. It also describes how DKIM relates to other
IETF message signature technologies. It is intended for those who
are adopting, developing, or deploying DKIM.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DomainKeys Identified Mail (DKIM) allows an organization to take
responsibility for a message, in a way that can be validated by a
recipient. The organization can be the author's, the originating
sending site, an intermediary, or one of their agent's. DKIM
defines a domain-level digital signature authentication framework
for email, using public-key cryptography and key server
technology. This permits verifying the signer of a message, as
well as the integrity of its contents. DKIM accomplishes this by
defining a domain-level authentication framework for email using
public-key cryptography and key server technology <xref
target="RFC4871" />. This permits verifying a message source,
an intermediary, or one of their agents, as well as the integrity
of its contents. DKIM will also provide a mechanism that permits
potential email signers to publish information about their email
signing practices; this will permit email receivers to make
additional assessments of unsigned messages.
Such protection of email identity can assist in the global
control of "spam" and "phishing". </t>
<t> This document provides a description of DKIM's architecture and
functionality. It is intended for those who are adopting,
developing, or deploying DKIM. It also will be helpful for those
who are considering extending DKIM, either into other areas of use
or to support additional features. This Overview does not provide
information on threats to DKIM or email, or details on the
protocol specifics, which can be found in <xref target="RFC4871"
/> and <xref target="RFC4686" />, respectively. The document
assumes a background in basic network security technology and
services. </t>
<t> Neither this document nor DKIM attempt to provide solutions to
the world's problems with spam, phishing, virii, worms, joe jobs,
etc. DKIM provides one basic tool, in what needs to be a large
arsenal, for improving basic trust in the Internet mail service.
However by itself, DKIM is not sufficient to that task and this
Overview does not pursue the issues of integrating DKIM into these
larger efforts, beyond a simple reference within a system diagram.
Rather, it is a basic introduction to the technology and its use. </t>
<section title="Prior Work">
<t>Historical email assessment based on identity has
used the IP Address of a system that
sent the message. The Address is obtained via underlying
Internet information mechanisms and is therefore trusted to be
accurate. Besides having some known security weaknesses, the
use of Addresses present a number of functional and operational
problems. Consequently there is an industry desire to use a
more stable value that has better correspondence to
organizational boundaries. Domain Names are viewed as
often satisfying this need.</t>
<t> There have been four previous efforts at standardizing an
Internet email signature scheme: <list style="symbols">
<t>Privacy Enhanced Mail (PEM) was first published in 1987.
<xref target="RFC0989" />
</t>
<t>PEM eventually transformed into MIME Object Security
Services (MOSS) in 1995. <xref target="RFC1848" /> Today,
these two are only of historical interest.</t>
<t> Pretty Good Privacy (PGP) was developed by Phil
Zimmermann and first released in 1991. <xref
target="RFC1991" /> A later version was standardized
as OpenPGP. <xref target="RFC2440" />
<xref target="RFC3156" />
<xref target="I-D.ietf-openpgp-rfc2440bis" />
</t>
<t>RSA Security independently developed Secure MIME (S/MIME)
to transport a PKCS #7 data object. <xref
target="RFC3851" /></t>
</list> Development of S/MIME and OpenPGP
has continued. While both have
achieved a significant user base, neither have achieved
ubiquity in deployment or use, and their goals differ from
those of DKIM. </t>
<t> 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 that re-purposing any of those would be more
problematic than creating a separate service. That said, DKIM
uses security algorithm components that have a long history,
including use within some of those other messaging security
services. </t>
<t> DKIM has a distinctive approach for distributing and vouching
for keys. It uses a key-centric Public Key Infrastructure (PKI)
rather than the more typical approaches based on a certificate
in the styles of Kohnfelder (X.509) or Zimmermann (web of
trust). For DKIM, the owner of a key asserts its validity,
rather than relying on the key having a broader semantic
implication of the assertion, such as a quality assessment of
the key's owner. DKIM treats quality assessment as an
independent, value-added service, beyond the initial work of
deploying a verifying signature service. </t>
<t> Further, DKIM's PKI is provided by adding
information records to the existing
Domain Name System (DNS) <xref target="RFC1034" />, rather than
requiring deployment of a new query infrastructure. This
approach has significant operational advantages. First, it
avoids the considerable barrier of creating a new
global infrastructure; hence it leverages a global base of
administrative experience and highly reliable distributed
operation. Second, the technical aspect of the DNS is already
known to be efficient. Any new service would have to undergo a
period of gradual maturation, with potentially problematic
early-stage behaviors. By (re-)using the DNS, DKIM avoids these
growing pains. </t>
</section>
<section title="Discussion Venue">
<t>
<list style="hanging">
<t hangText="NOTE TO RFC EDITOR: ">This "Discussion Venue"
section is to be removed prior to publication.</t>
</list>
</t>
<t> This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org. </t>
</section>
</section>
<section title="Internet Mail Background">
<t>Internet Mail has a simple split between the user world, in the
form of Mail User Agents (MUA), and the transmission world, in the
form of the Mail Handling Service (MHS) composed of Mail Transfer
Agents (MTA). The MHS is responsible for accepting a message from
one user, the author, and delivering it to one or more other
users, the recipients. This creates a virtual MUA-to-MUA exchange
environment. The first component of the MHS is called the Mail
Submission Agent (MSA) and the last is called the Mail Delivery
Agent (MDA).</t>
<t> An email Mediator is both an inbound MDA and outbound MSA. It
takes delivery of a message and re-posts it for further
distribution, retaining the original From header field. A mailing
list is a common example of a Mediator</t>
<t>The modern Internet Mail service is marked by many independent
operators, many different components for providing users with
service and many other components for performing message transfer.
Consequently, it is necessary to distinguish administrative
boundaries that surround sets of functional components, which are
subject to coherent operational policies.</t>
<t>As elaborated on below, every MSA is a
candidate for signing using DKIM, and every MDA is a candidate for
doing DKIM verification.</t>
<section anchor="AdminDomain"
title="Administrative Management Domain (ADMD)">
<t>Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an
independent ADministrative Management Domain (ADMD). An ADMD
operates with an independent set of policies and interacts with
other ADMDs according to differing types and amounts of trust.
Examples include: an end-user operating their desktop client
that connects to an independent email service, a department
operating a submission agent or a local Relay, an
organization's IT group that operates enterprise Relays, and an
ISP operating a public shared email service. </t>
<t>Each of these can be configured into many combinations of
administrative and operational relationships, with each ADMD
potentially having a complex arrangement of functional
components. <xref target="ADMD" /> depicts the relationships
among ADMDs. Perhaps the most salient aspect of an ADMD is the
differential trust that determines its policies for activities
within the ADMD, versus those involving interactions with other
ADMDs. </t>
<t>Basic types of ADMDs include: <list>
<t>
<list style="hanging">
<t hangText="Edge: ">Independent transfer services,
in networks at the edge of the Internet Mail
service.</t>
<t hangText="User: ">End-user services. These might
be subsumed under an Edge service, such as is
common for web-based email access.</t>
<t hangText="Transit: ">These are Mail Service
Providers (MSP) offering value-added capabilities
for Edge ADMDs, such as aggregation and
filtering.</t>
</list>
</t>
</list>
</t>
<figure anchor="ADMD"
title="ADministrative Management Domains (ADMD) Example">
<preamble>Note that Transit services are quite different from
packet-level transit operation. Whereas end-to-end packet
transfers usually go through intermediate routers, email
exchange across the open Internet is often directly between
the Edge ADMDs, at the email level. </preamble>
<?rfc needLines="15" ?>
<artwork name="ADministrative Management Domain (ADMD) Example"><![CDATA[
+--------+ +--------+ +--------+
| ADMD#1 | | ADMD#3 | | ADMD#4 |
| ------ | | ------ | | ------ |
| | +----------------------->| | | |
| User | | |--Edge--+--->|--User |
| | | | +--->| | | |
| V | | | +--------+ +--------+
| Edge---+---+ |
| | | +----------+ |
+--------+ | | ADMD#2 | |
| | ------ | |
| | | |
+--->|-Transit--+---+
| |
+----------+]]></artwork>
</figure>
<t> In <xref target="ADMD" />, ADMD numbers 1 and 2 are candidates
for doing DKIM signing, and ADMD numbers 2, 3 and 4 are
candidates for doing DKIM verification. <!-- QUESTION: Dumb one -
can we think of any sort of credible scenario where it would
make sense for ADMD#3 to do signing? /d --> </t>
<t>The distinction between Transit network and Edge network
transfer services is primarily significant because it
highlights the need for concern over interaction and protection
between independent administrations. The interactions between
functional components within a single ADMD are subject to the
policies of that domain. Although any pair of ADMDs
can arrange for whatever policies they wish, Internet Mail is
designed to permit inter-operation without prior arrangement.
</t>
<t>Common ADMD examples are: <list>
<t>
<list>
<t> Enterprise Service Providers: <list>
<t>Operators of an organization's internal data
and/or mail services.</t>
</list></t>
<t>Internet Service Providers: <list>
<t>Operators of underlying data communication
services that, in turn, are used by one or
more Relays and Users. It is not necessarily
their job to perform email functions, but
they can, instead, provide an environment in
which those functions can be performed.</t>
</list></t>
<t>Mail Service Providers: <list>
<t>Operators of email services, such as for
end-users, or mailing lists.</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="DKIM Placement within an ADMD">
<t>It is expected that the most common venue for a DKIM
implementation will be within the infrastructures of the
originating organization's outbound service and the receiving
organization's inbound service, such as a department or a
boundary MTA. DKIM can be implemented in an author's or
recipient MUA, but this is expected to be less typical, since
it has higher administration and support costs.</t>
<t>A Mediator, such as a mailing list, often can re-post a message
without breaking the DKIM signature. Furthermore it can add its
own signature. This can be added by the Mediator software
itself, or by any outbound component in the Mediator's ADMD.
</t>
</section>
</section>
<section title="The DKIM Value Proposition">
<t>The nature and origins of a message are often falsely stated. As a
foundation for distinguishing legitimate mail, DKIM provides a
means of associating a verifiable identity with a message. Given
the presence of that identity, a receiver can make decisions about
further handling of the message, based upon assessments of that
identity.</t>
<t>Receivers who successfully verify a signature can use information
about the signer as part of a program to limit spam, spoofing,
phishing, or other undesirable behavior. DKIM does not, itself,
prescribe any specific actions by the recipient; rather it is an
enabling technology for services that do. </t>
<t>These services will typically: <list style="numbers">
<t>Verify an identity</t>
<t>Determine whether the identity is known or unknown</t>
<t>Determine whether a known identity is trusted</t>
</list> The role of DKIM is in the first two of these; DKIM is an
enabler for the third. </t>
<t>An attack is made against an organization or against customers of
an organization. The name of the organization is linked to
particular Internet domain names. One point of leverage used by
attackers is either to use a legitimate domain name,
without authorization or to use a
"cousin" name that is similar to one that is legitimate, but is
not controlled by the target organization. A DKIM-based
assessment service can enforce a basic
separation between domains used by such known organizations and
domains used by others.</t>
<t>DKIM signatures can be created by a direct handler of a message,
either as its originator or as an intermediary. It can also be
created by an independent service, providing assistance to a
handler of the message. Whoever does the signing chooses the
domain name to be used as the basis for later assessments. Hence,
reputation associated with that domain name is the basis for
evaluating whether to trust the message for delivery. The owner of
the domain name being used for a DKIM signature is declaring that
they are accountable for the message. </t>
<t>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; it continues to be evaluated
by established analysis and filtering techniques. Over time,
widespread 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.</t>
<t>It is important to be clear about the narrow scope of DKIM's
capabilities. It is an enabling technology, intended for use in
the larger context of determining message legitimacy. This larger
context is complex, so it is easy to assume that
a component like DKIM, which actually provides only a limited
service, instead satisfies the broader set of requirements. A DKIM
signature: <list style="symbols">
<t>Does not offer any assertions about the behaviors of the
identity doing the signing. </t>
<t>Does not prescribe any specific actions for receivers to
take upon successful signature verification. </t>
<t>Does not provide protection after signature verification. </t>
<t>Does not protect against re-sending (replay of) a message
that already has a verified signature; therefore a transit
intermediary or a recipient can re-post the message in such
a way that the signature would remain verifiable, although
the new recipient(s) would not have been specified by the
author. </t>
</list>
</t>
</section>
<!--
I believe this section does not work. It has a worth goal, but I do not know how to fix it.
1. The first paragraph confuses me. I almost understand what it is trying to accomplish, but can't figure out how to fix it.
2. The second two paragraphs use definitions that are not widely accepted; I fear they invite controversy and, therefore, distraction for the document's progress.
Since the section is not mandatory for the document, I'm commenting it out until we can discuss it and find some text that will work better.
/Dave
<section title="The Role of Trust">
<t> As mentioned above, DKIM lets you verify the identity of a signer
and is an enabler for determining whether a now-known identity is
trusted; it does not itself provide that determination. Deciding
whether a non-known identity can be trusted must be handled by
accreditation and reputation services that are themselves
trustable. </t>
<t> An accreditation service provides an assessment of a sender's
trustworthiness on behalf of the sender. They reflect the
statement "this signer says they are good and I concur with that
statement." Accreditation services are almost always
network-based. </t>
<t> A reputation service provides an assessment of a sender's
trustworthiness on behalf of the receiver. They reflect the
statements "based on their past history or some private knowledge
about them, this signer can be trusted" or "not trusted."
Reputation services can be network-based or be based on local
white lists and black lists. </t>
</section>
-->
<section title="DKIM Goals">
<t>DKIM adds an end-to-end authentication mechanism to the existing
email transfer infrastructure. This motivates functional goals
about the authentication itself and operational goals about its
integration with the rest of the Internet email service.</t>
<section title="Functional Goals">
<section title="Use Domain-level granularity for assurance.">
<t>OpenPGP and S/MIME provide end-to-end validation in
terms of individual originators and recipients, notably
using full email addresses, whereas DKIM seeks accountability at the
more coarse granularity of an organization or, perhaps, a
department. An existing Internet service construct that
enables this granularity is the Domain Name <xref
target="RFC1034" />, to which the signing key record is
bound. Further DKIM signing and/or validating can be
implemented anywhere along the transit path, rather than
only in the end systems or only in the boundary MTA.</t>
</section>
<section
title="Allow delegation of signing to independent parties.">
<t> Different parties have different roles in the process of
email exchange. Some are easily visible to end users and
others are primarily visible to operators of the service.
DKIM needs to support signing by any of these different
parties and needs to permit them to sign with any domain
name that they deem appropriate (and for which they are
authorized.) As an example an organization that creates
email content often delegates portions of its processing or
transmission to an outsourced group. DKIM supports this mode
of activity, in a manner that is not visible to end users.
</t>
</section>
<section
title="Distinguish the core authentication mechanism from its
derivative uses.">
<t> An authenticated identity can be subject to a variety of
processing policies, either ad hoc or standardized. The only
semantics inherent to a DKIM signature is that the signer is
asserting (some) responsibility for the message. All other
mechanisms and meanings are independent of this core
service. One such mechanism might assert a relationship
between the signing identity and the author, as specified in
the From header field's domain identity<xref
target="RFC2822" />. Another might specify how to treat
an unsigned message with that From field domain.</t>
</section>
<section title="Retain ability to have anonymous email.">
<t>The ability to send a message that does not identify its
author is considered to be a valuable quality of the current
email service that needs to be retained. DKIM is compatible
with this goal since it permits an email system operator to
be authenticated, rather than the content author. Knowing
that a message definitely came from example.com does not
threaten the anonymity of the user who authored it, if it is
still possible to obtain effectively anonymous accounts at
example.com. </t>
</section>
</section>
<section title="Operational Goals">
<section
title="Treat verification failure the same as no signature present.">
<t>OpenPGP and S/MIME were designed for
strong cryptographic protection. This included treating
verification failure as message failure. As a sub-goal to
the requirement for transparency, a DKIM signature verifier
is to treat messages with signatures that fail as if they
were unsigned. Hence the message will revert to normal
handling, through the receiver's existing filtering
mechanisms. Thus, DKIM specifies that a sender is not to take a message that has a broken
signature and treat it any differently than if
the signature weren't there. </t>
</section>
<section
title="Make signatures transparent to non-supporting recipients.">
<t>S/MIME and OpenPGP modify the message
body. Hence, their presence is potentially visible to email
recipients, whose user software needs to process the associated
constructs. In order to facilitate incremental adoption,
DKIM is designed to be transparent to recipients that do not
support it. A DKIM signature does not "get in the way" for such
recipients. </t>
</section>
<section
title="Permit incremental adoption for incremental benefit.">
<t>DKIM can immediately provide benefits between any two
organizations that exchange email and implement DKIM. In the
usual manner of "network effects", the benefits of DKIM
increase dramatically as its adoption increases.</t>
<t>Although it is envisioned that this mechanism will call upon
independent services to aid in the assessment of DKIM
results, they are not essential in order to obtain initial
benefit. For example DKIM allows (possibly large) pair-wise
sets of email providers and spam filtering companies to
distinguish mail that is associated with a known
organization, from mail that might deceptively purport to
have the affiliation. This in turn allows the development of
"whitelist" schemes whereby authenticated
mail from a known source with good reputation is allowed to
bypass some anti-abuse filters.</t>
<t>In effect the email receiver is using their set of known
relationships to generate their own reputation data. This
works particularly well for traffic between large sending
providers and large receiving providers. However it also
works well for any operator, public or private, that has
mail traffic dominated by exchanges among a stable set of
organizations.</t>
</section>
<section title="Minimize the amount of required infrastructure">
<t>A new service, or an enhancement to an existing service,
requires adoption by some number of systems, before it can
be useful. The greater the number of required adopters, the
higher the adoption barrier. This becomes particularly
serious when adoption is required by intermediary -- that
is, infrastructure -- service providers. In order to allow
early adopters to gain early benefit, DKIM makes no changes
to the core Internet Mail service and, instead, can provide
a useful benefit for any signer/verifier pair of
participants exchanging mail. Similarly, DKIM's reliance on
the Domain Name System greatly reduces the amount of new
administrative infrastructure that is need, across the open
Internet.</t>
</section>
<section title="Permit wide range of deployment choices.">
<t>DKIM can be deployed at a variety of places within an
organization's email service. This permits the organization
to choose how much or how little they want DKIM to be part
of their service, rather than part of a more localized
operation.</t>
</section>
</section>
</section>
<section title="DKIM Function">
<t>DKIM has a very constrained set of capabilities, primarily
targeting email while it is in transit, from an author to a set of
recipients. It creates the ability to associate verifiable
information with a message, especially a responsible identity.
When a message is not signed, DKIM will permit the domain name of the author to be used for
obtaining information about their signing practices. </t>
<section anchor="basicsign" title="The Basic Signing Service">
<t>With the DKIM signature mechanism, a signer chooses a signing
identity based on their domain name, performs digital signing
on the message, and records signature information in a DKIM
header field. A verifier obtains the domain name and the
"selector" from the DKIM header field,
queries for a public key associated with the name, and verifies
the signature.</t>
<t>DKIM permits any domain name to be used for signing, and
supports extensible choices for various algorithms. As is
typical for Internet standards, there is a core set of
algorithms that all implementations are required to support, in
order to guarantee basic interoperability.</t>
<t>DKIM permits restricting the use of a signature key to
signing messages for particular types
of services, such as only for email. This is helpful when
delegating signing authority, such as to a particular
department or to a third-party outsourcing service.</t>
<t>With DKIM the signer explicitly lists the headers that are
signed. By choosing the minimal set of headers needed, the
signature is likely to be considerably more robust against the
handling vagaries of intermediary MTAs.</t>
</section>
<section title="Characteristics of a DKIM signature">
<!-- -->
<t>A DKIM signature covers the message body and selected header
fields. The signer computes a hash of the selected header
fields and another hash of the body. The signer then uses a
private key to cryptographically encode this information, along
with other signing parameters. Signature information is placed
into a new <xref target="RFC2822" /> header field of the
message. </t>
</section>
<section title="The Selector construct">
<!-- -->
<t>The key for a signature is associated
with a domain name, as specified in the d= DKIM-Signature header field
parameter. That domain name is the complete identity used for
making assessments about the signer. However this name is not
sufficient for making a DNS query to obtain the key needed to
verify the signature. </t>
<t>A single domain can use multiple signing keys and/or multiple
signers. To support this, DKIM identifies a particular
signature as a combination of the domain name and an added
field, called the "selector", coded into separate
DKIM-Signature header field parameters. </t>
<t>
<list style="hanging">
<t hangText="NOTE: ">The selector is not intended to be
part of the domain name that is used for making
assessments. Rather, the selector is strictly reserved
for use in administering keys that are associated with
the domain name. If the selector becomes part of a name
assessment mechanism, then there is no remaining
mechanism for making a transition from an old, or
compromised, key to a new one.</t>
</list>
</t>
<t>Signers often need to support multiple assessments about their
organization, such as to distinguish one type of message from
another, or one portion of the organization from another. To
permit assessments that are independent, one method is for an
organization to use different sub-domains in the "d="
parameter, such as "transaction.example.com" versus
"newsletter.example.com", or "productA.example.com" versus
"productB.example.com".</t>
</section>
<section title="Verification">
<!-- -->
<t>After a message has been signed, any agent in the message
transit path can verify the signature, to determine that the
signing identity took responsibility for the message. Message
recipients can verify the signature by querying the DNS for the
signer's domain directly, to retrieve the appropriate public
key, and thereby confirm that the message was attested to by a
party in possession of the private key for the signing domain.
Typically, verification will be done by an agent in the ADMD of
the message recipient. </t>
</section>
</section>
<section title="Service Architecture">
<!-- 6 -->
<figure anchor="DKIMSvc" title="DKIM Service Architecture">
<preamble>The DKIM service is divided into components that can be
performed using different, external services, such as for key
retrieval. However the basic DKIM signing specification defines
an initial set of these services, in order to ensure a basic
level of interoperability.</preamble>
<?rfc needLines="43" ?>
<artwork name="DKIM Service Architecture"><![CDATA[
|
|- RFC2822 Message
V
+------------------------------------+
| ORIGINATING OR RELAYING ADMD (MSA) |
| |
+..>| Sign Message |
. +--------------+---------------------+
. |
.private |
+---+---+ |
| Key | | +-----------+
| Store | [Internet] | Sender |
+---+---+ | | Practices |
.public | +-----+-----+
. V .
. +-----------------------------------+ .
. | RELAYING OR DELIVERING ADMD (MDA) | .
. | | .
. | Message Signed? | .
. +-------+----------------+----------+ .
. |yes |no .
. V V .
. +-----------+ +-----------+ .
+.....>| Verify | +-->| Check |<.......+
| Signature | | | Practices |<.......+
+---+-----+-+ | +---+-------+ .
| | | | .
| +---+ | .
pass| fail | .
V | +-----+-----+
+--------+ | | Local |
+.......>| Assess | | | Sender |
. | Signer | | | Practices |
. +---+----+ | +-----------+
. assessment| |
. +------+ +------+
. | |
+-+-----------+ V V
| Reputation/ | +-----------+
|Accreditation| | Message |
| Info | | Filtering |
+-----+-------+ | Engine |
+-----------+]]>></artwork>
</figure>
<t>As shown in <xref target="DKIMSvc" />, basic message processing is
divided between the MSA and the MDA. <list style="hanging">
<t hangText="The MSA"> The MSA signs the message, using private
information from the Key Store. </t>
<t hangText="The MDA"> The MDA verifies the signature or
determines whether a signature was required. Verifying the
signature uses public information from the Key Store. If the
signature passes, reputation information is used to asses
the signer and that information is passed to the message
filtering system. If the signature fails or there is no
signature, information about the sender's practices is
retrieved remotely and/or locally, and that information is
passed to the message filtering system. </t>
<t hangText="Note:">
<xref target="DKIMSvc" /> does not show the effects on the message-handling flow <!-- QUESTION:
what does "flow" refer to, here? --> when multiple signatures or
third-party signatures are present. </t>
</list>
</t>
<section title="Administration and Maintenance">
<t> A number of tables and services are used to provide external
information. Each of these introduces administration and
maintenance requirements. <list style="hanging">
<t hangText="Key Store"> DKIM uses public/private
(asymmetric) key technology. The signer users a private
key and the validator uses the corresponding public key.
The current DKIM signing specification provides for
querying the Domain Names Service (DNS), to permit a
validator to obtain the public key. The signing
organization therefore must have a means of adding a key
to the DNS, for every selector/domain-name combination.
Further, the signing organization needs policies for
distributing and revising keys. </t>
<t hangText="Sender Practices"> If a message contains a
valid signature, then the verifier can evaluate the
associated domain name's reputation. If a message does
not contain a valid signature, that fact could be useful,
if the verifier can discover information about the
DKIM-related practices of one of the agents purportedly
involved with the message, such as the domain listed in
the author's FROM header field. Such information might
come from tables developed through private agreement or
from standards-based mechanisms. As they are defined,
each domain name owner will need to consider what
information to publish through the mechanism and then
will need to create and maintain it. </t>
<t hangText="Reputation/Accreditation">
"Reputation/Accreditation" provides quality-assessment
information that is associated with a domain name, and
comes in many forms and from many sources. DKIM does not
define these services. It's relevance to them is to
provide a validated domain name, upon which assessments
can be made. </t>
</list>
</t>
</section>
<section title="Signing">
<t>Signing can be performed by a component of the ADMD that
creates the message, and/or within any ADMD along the relay
path. The signer uses the appropriate private key.</t>
</section>
<section title="Verifying">
<t>Verification can be performed by any functional component along
the relay and delivery path. Verifiers retrieve the public key
based upon the parameters stored in the message. </t>
</section>
<section title="Unverified or Unsigned Mail">
<t>Note that a failed signature causes the message to be treated
in the same manner as one that is unsigned. Messages lacking a
valid originator signature (a signature associated with the
originator of the message as opposed to a signature associated
with an intermediary) prompt a query for any published "sender
practices" information, as an aid in determining whether the
sender information has been used without authorization.</t>
</section>
<section title="Evaluating">
<t>The Figure shows the verified identity as being used to assess
an associated reputation, but it could be applied for other
tasks, such as management tracking of mail. A popular use of
reputation information is as input to a filtering engine that
decides whether to deliver -- and possibly whether to specially
mark -- a message. Filtering engines have become complex and
sophisticated. Their details are outside of DKIM's scope, other
than the expectation that DKIM-related information is added to
the varied soup of rules used by the engines. The rules can
cover signed messages and can deal with unsigned messages from
a domain, if the domain has published information about is
practices</t>
</section>
</section>
<section title="Security Considerations">
<t> TBD </t>
</section>
<section title="IANA Considerations">
<t> TBD </t>
</section>
<section title="Acknowledgements">
<t> TBD </t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<!-- references title="Normative References"> </references -->
<references title="Informative References">&dkimbase; &dkimta;
&RFC1034; &rfc2822; &dk; &pem; &moss; &pgp1;
&rfc2821; &rfc2440; &rfc3156; &rfc2440bis;
&syslog; &rfc3851; &ar; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:52 |