doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc5585.txt b/doc/rfc/rfc5585.txt
new file mode 100644
index 0000000..8f779d1
--- /dev/null
+++ b/doc/rfc/rfc5585.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                          T. Hansen
+Request for Comments: 5585                             AT&T Laboratories
+Category: Informational                                       D. Crocker
+                                             Brandenburg InternetWorking
+                                                         P. Hallam-Baker
+                                             Default Deny Security, Inc.
+                                                               July 2009
+
+
+           DomainKeys Identified Mail (DKIM) Service Overview
+
+Abstract
+
+   This document provides an overview of the DomainKeys Identified Mail
+   (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.  DKIM allows an organization to take
+   responsibility for transmitting a message, in a way that can be
+   verified by a recipient.  The organization can be the author's, the
+   originating sending site, an intermediary, or one of their agents.  A
+   message can contain multiple signatures from the same or different
+   organizations involved with the message.  DKIM defines a domain-level
+   digital signature authentication framework for email, using public-
+   key cryptography, with the domain name service as its key server
+   technology (RFC 4871).  This permits verification of a responsible
+   organization, as well as the integrity of the message contents.  DKIM
+   also enables a mechanism that permits potential email signers to
+   publish information about their email signing practices; this will
+   permit email receivers to make additional assessments about messages.
+   DKIM's authentication of email identity can assist in the global
+   control of "spam" and "phishing".
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                      [Page 1]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. DKIM's Scope ...............................................4
+      1.2. Prior Work .................................................5
+      1.3. Internet Mail Background ...................................6
+   2. The DKIM Value Proposition ......................................6
+      2.1. Identity Verification ......................................7
+      2.2. Enabling Trust Assessments .................................7
+      2.3. Establishing Message Validity ..............................8
+   3. DKIM Goals ......................................................8
+      3.1. Functional Goals ...........................................9
+      3.2. Operational Goals .........................................10
+   4. DKIM Function ..................................................12
+      4.1. Basic Signing .............................................12
+      4.2. Characteristics of a DKIM Signature .......................12
+      4.3. The Selector Construct ....................................13
+      4.4. Verification ..............................................13
+      4.5. Sub-Domain Assessment .....................................13
+   5. Service Architecture ...........................................14
+      5.1. Administration and Maintenance ............................15
+      5.2. Signing ...................................................16
+      5.3. Verifying .................................................16
+      5.4. Unverified or Unsigned Mail ...............................16
+      5.5. Assessing .................................................17
+      5.6. DKIM Processing within an ADMD ............................17
+   6. Considerations .................................................17
+      6.1. Security Considerations ...................................17
+      6.2. Acknowledgements ..........................................17
+   7. Informative References .........................................18
+   Appendix A.  Internet Mail Background .............................20
+     A.1.  Core Model ................................................20
+     A.2.  Trust Boundaries ..........................................20
+   Index .............................................................22
+
+
+
+
+
+
+Hansen, et al.               Informational                      [Page 2]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+1.  Introduction
+
+   This document provides a description of the architecture and
+   functionality for DomainKeys Identified Mail (DKIM), that is, the
+   core mechanism for signing and verifying messages.  It is intended
+   for those who are adopting, developing, or deploying DKIM.  It will
+   also 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 [RFC4686]
+   and [RFC4871], respectively.  Because the scope of this overview is
+   restricted to the technical details of signing and verifying using
+   DKIM, it does not explore operational issues, the details of services
+   that DKIM uses, or those that, in turn, use DKIM.  Nor does it
+   discuss services that build upon DKIM for enforcement of policies or
+   assessments.  The document assumes a background in basic email and
+   network security technology and services.
+
+   DKIM allows an organization to take responsibility for a message in a
+   way that can be verified by a recipient.  The organization can be a
+   direct handler of the message, such as the author's, the originating
+   sending site's, or an intermediary's along the transit path.
+   However, it can also be an indirect handler, such as an independent
+   service that is providing assistance to a direct handler.  DKIM
+   defines a domain-level digital signature authentication framework for
+   email through the use of public-key cryptography and using the domain
+   name service as its key server technology [RFC4871].  It permits
+   verification of the signer of a message, 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.  DKIM's authentication
+   of email identity can assist in the global control of "spam" and
+   "phishing".
+
+   Neither this document nor DKIM attempts to provide solutions to the
+   world's problems with spam, phishing, viruses, 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.
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                      [Page 3]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+1.1.  DKIM's Scope
+
+   A person or organization has an "identity" -- that is, a
+   constellation of characteristics that distinguish them from any other
+   identity.  Associated with this abstraction can be a label used as a
+   reference, or "identifier".  This is the distinction between a thing
+   and the name of the thing.  DKIM uses a domain name as an identifier,
+   to refer to the identity of a responsible person or organization.  In
+   DKIM, this identifier is called the Signing Domain IDentifier (SDID)
+   and is contained in the DKIM-Signature header fields "d=" tag.  Note
+   that the same identity can have multiple identifiers.
+
+   A DKIM signature can be created by a direct handler of a message,
+   such as the message's author or by an intermediary.  A signature also
+   can be created by an independent service that is providing assistance
+   to a handler of the message.  Whoever does the signing chooses the
+   SDID to be used as the basis for later assessments.  Hence, the
+   reputation associated with that domain name might be an additional
+   basis for evaluating whether to trust the message for delivery.  The
+   owner of the SDID is declaring that they accept responsibility for
+   the message and can thus be held accountable for it.
+
+   DKIM is intended as 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 techniques.  (A signing policy can provide additional
+   information for that analysis and filtering.)  Over time, widespread
+   DKIM adoption could permit stricter handling of messages that are not
+   signed.  However, early benefits do not require this and probably do
+   not warrant this.
+
+   DKIM has a narrow scope.  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.
+
+   By itself, a DKIM signature:
+
+   o  Does not authenticate or verify the contents of the message header
+      or body, such as the author From field, beyond certifying data
+      integrity between the time of signing and the time of verifying.
+
+   o  Does not offer any assertions about the behaviors of the signer.
+
+   o  Does not prescribe any specific actions for receivers to take upon
+      successful signature verification.
+
+
+
+
+Hansen, et al.               Informational                      [Page 4]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   o  Does not provide protection after signature verification.
+
+   o  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 -- that is,
+      post it as a new message -- with the original signature remaining
+      verifiable, even though the new recipient(s) might be different
+      from those who were originally specified by the author.
+
+1.2.  Prior Work
+
+   Historically, the IP Address of the system that directly sent the
+   message -- that is, the previous email "hop" -- has been treated as
+   an identity to use for making assessments.  For example, see
+   [RFC4408], [RFC4406], and [RFC4407] for some current uses of the
+   sending system's IP Address.  The IP 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 presents a number of functional and operational
+   problems.  Consequently, there is a widespread desire to use an
+   identifier that has better correspondence to organizational
+   boundaries.  Domain names can satisfy this need.
+
+   There have been four previous IETF Internet Mail signature standards.
+   Their goals have differed from those of DKIM.  PEM and MOSS are only
+   of historical interest.
+
+   o  Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989].
+
+   o  Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
+      first released in 1991.  A later version was standardized as
+      OpenPGP [RFC1991] [RFC2440] [RFC3156] [RFC4880].
+
+   o  PEM eventually transformed into MIME Object Security Services
+      (MOSS) in 1995 [RFC1848].
+
+   o  RSA Security independently developed Secure MIME (S/MIME) to
+      transport a Public Key Cryptographic System (PKCS) #7 data object.
+      It was standardized as [RFC3851].
+
+   Development of both S/MIME and OpenPGP has continued.  While each has
+   achieved a significant user base, neither one has achieved ubiquity
+   in deployment or use.
+
+   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 repurposing any of those would be more problematic than creating
+
+
+
+
+Hansen, et al.               Informational                      [Page 5]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   a separate service.  That said, DKIM only uses cryptographic
+   components that have a long history, including use within some of
+   those other messaging security services.
+
+   DKIM is differentiated by its reliance on an identifier that is
+   specific to DKIM use.
+
+   DKIM also has a distinctive approach for distributing and vouching
+   for keys.  It uses a key-centric, public-key management scheme,
+   rather than the more typical approaches based on a certificate in the
+   styles of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of
+   trust) [WebofTrust].  For DKIM, the owner of the SDID asserts the
+   validity of a key, rather than having the validity of the key
+   attested to by a trusted third party, often including other
+   assertions, 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 signature verification
+   service.
+
+   Further, DKIM's key management is provided by adding information
+   records to the existing Domain Name System (DNS) [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.
+
+1.3.  Internet Mail Background
+
+   The basic Internet email service has evolved extensively over its
+   several decades of continuous operation.  Its modern architecture
+   comprises a number of specialized components.  A discussion about
+   Mail User Agents (MUAs), Mail Handling Services (MHSs), Mail Transfer
+   Agents (MTAs), Mail Submission Agents (MSAs), Mail Delivery Agents
+   (MDAs), Mail Service Providers (MSPs), Administrative Management
+   Domains (ADMDs), Mediators, and their relationships can be found in
+   Appendix A.
+
+2.  The DKIM Value Proposition
+
+   The nature and origins of a message often are falsely stated.  Such
+   misrepresentations may be employed for legitimate or nefarious
+   reasons.  DKIM provides a foundation for distinguishing legitimate
+   mail, and thus a means of associating a verifiable identifier with a
+
+
+
+Hansen, et al.               Informational                      [Page 6]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   message.  Given the presence of that identifier, a 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
+   about the signer as part of a program to limit spam, spoofing,
+   phishing, or other undesirable behaviors.  DKIM does not, itself,
+   prescribe any specific actions by the recipient; rather, it is an
+   enabling technology for services that do.
+
+   These services will typically:
+
+   1.  Determine a verified identity as taking responsibility for the
+       message, if possible.
+
+   2.  Evaluate the trustworthiness of this/these identities.
+
+   The role of DKIM is to perform the first of these; DKIM is an enabler
+   for the second.
+
+2.1.  Identity Verification
+
+   Consider an attack made against an organization or against customers
+   of an organization.  The name of the organization is linked to
+   particular Internet domain names (identifiers).  Attackers can
+   leverage using either a legitimate domain name, one without
+   authorization, or a "cousin" name that is similar to one that is
+   legitimate, but is not controlled by the target organization.  An
+   assessment service that uses DKIM can differentiate between a domain
+   (SDID) used by a known organization and a domain used by others.  As
+   such, DKIM performs the positive step of identifying messages
+   associated with verifiable identities, rather than the negative step
+   of identifying messages with problematic use of identities.  Whether
+   a verified identity belongs to a Good Actor or a Bad Actor is a
+   question for later stages of assessment.
+
+2.2.  Enabling Trust Assessments
+
+   Email receiving services are faced with a basic decision: whether to
+   accept and deliver a newly arrived message to the indicated
+   recipient?  That is, does the receiving service trust that the
+   message is sufficiently "safe" to be viewed?  For the modern
+   Internet, most receiving services have an elaborate engine that
+   formulates this quality assessment.  These engines take a variety of
+   information as input to the decision, such as from reputation lists
+   and accreditation services.  As the engine processes information, it
+   raises or lowers its trust assessment for the message.
+
+
+
+
+Hansen, et al.               Informational                      [Page 7]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   In order to formulate reputation information, an accurate, stable
+   identifier is needed.  Otherwise, the information might not pertain
+   to the identified organization's own actions.  When using an IP
+   Address, accuracy is based on the belief that the underlying Internet
+   infrastructure supplies an accurate address.  When using domain-based
+   reputation data, some other form of verification is needed, since it
+   is not supplied independently by the infrastructure.
+
+   DKIM satisfies this requirement by declaring a valid "responsible"
+   identity -- referenced through the SDID -- about which the engine can
+   make quality assessments and by using a digital signature to ensure
+   that use of the identifier is authorized.  However, by itself, a
+   valid DKIM signature neither lowers nor raises the level of trust
+   associated with the message, but it enables other mechanisms to be
+   used for doing so.
+
+   An organization might build upon its use of DKIM by publishing
+   information about its Signing Practices (SP).  This could permit
+   detecting some messages that purport to be associated with a domain,
+   but which are not.  As such, an SP can cause the trust assessment to
+   be reduced, or leave it unchanged.
+
+2.3.  Establishing Message Validity
+
+   Though man-in-the-middle attacks are historically rare in email, it
+   is nevertheless theoretically possible for a message to be modified
+   during transit.  An interesting side effect of the cryptographic
+   method used by DKIM is that it is possible to be certain that a
+   signed message (or, if l= is used, the signed portion of a message)
+   has not been modified between the time of signing and the time of
+   verifying.  If it has been changed in any way, then the message will
+   not be verified successfully with DKIM.
+
+   As described above, this validity neither lowers nor raises the level
+   of trust associated with the message.  If it was an untrustworthy
+   message when initially sent, the verifier can be certain that the
+   message will be equally untrustworthy upon receipt and successful
+   verification.
+
+3.  DKIM Goals
+
+   DKIM adds an end-to-end authentication capability to the existing
+   email transfer infrastructure.  That is, there can be multiple email
+   relaying hops between signing and verifying.  Hence, it defines a
+   mechanism that only needs to be supported by the signer and the
+
+
+
+
+
+
+Hansen, et al.               Informational                      [Page 8]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   verifier, rather than any of the functional components along the
+   handling path.  This motivates functional goals about the
+   authentication itself and operational goals about its integration
+   with the rest of the Internet email service.
+
+3.1.  Functional Goals
+
+3.1.1.  Use Domain-Level Granularity for Assurance
+
+   DKIM provides accountability at the coarse granularity of an
+   organization or, perhaps, a department.  An existing construct that
+   enables this granularity is the Domain Name [RFC1034].  DKIM binds a
+   signing key record to a Domain Name as the SDID.  Further benefits of
+   using domain names include simplifying key management, enabling
+   signing by the infrastructure as opposed to the MUA, and reducing
+   privacy concerns.
+
+   Contrast this with OpenPGP and S/MIME, which associate verification
+   with individual authors, using their full email addresses.
+
+3.1.2.  Implementation Locality
+
+   Any party, anywhere along the transit path, can implement DKIM
+   signing.  Its use is not confined to particular systems, such as the
+   author's MUA or the inbound boundary MTA, and there can be more than
+   one signature per message.
+
+3.1.3.  Allow Delegation of Signing to Independent Parties
+
+   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 was designed to
+   support signing by any of these different parties and to permit them
+   to sign with any domain name that they deem appropriate (and for
+   which they hold authorized signing keys).  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 normally visible to
+   end users.  Similarly, a reputation provider can delegate a signing
+   key for a domain under the control of the provider, to be used by an
+   organization for which the provider is prepared to vouch.
+
+3.1.4.  Distinguish the Core Authentication Mechanism from Its
+        Derivative Uses
+
+   An authenticated identity can be subject to a variety of assessment
+   policies, either ad hoc or standardized.  DKIM separates basic
+   authentication from assessment.  The only semantics inherent to a
+
+
+
+Hansen, et al.               Informational                      [Page 9]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   DKIM signature are that the signer is asserting some kind of
+   responsibility for the message.  Any interpretation of this kind of
+   responsibility is the job of services building on DKIM, but the
+   details are beyond the scope of that core.  One such mechanism might
+   assert a relationship between the SDID and the author, as specified
+   in the rfc5322.From: header field's domain identity.  Another might
+   specify how to treat an unsigned message with that rfc5322.From:
+   field domain.
+
+3.1.5.  Retain Ability to Have Anonymous Email
+
+   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 authentication of the email system operator, rather than the
+   content author.  If it is possible to obtain effectively anonymous
+   accounts at example.com, knowing that a message definitely came from
+   example.com does not threaten the anonymity of the user who authored
+   it.
+
+3.2.  Operational Goals
+
+3.2.1.  Make Presence of Signature Transparent to Non-Supporting
+        Recipients
+
+   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.
+
+   Contrast this with S/MIME and OpenPGP, which modify the message body.
+   Hence, their presence is potentially visible to email recipients,
+   whose user software needs to process the associated constructs.
+
+3.2.2.  Treat Verification Failure the Same as No Signature Present
+
+   DKIM must also be transparent to existing assessment mechanisms.
+   Consequently, 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 an assessing site is
+   not to take a message that has a broken signature and treat it any
+   differently than if the signature weren't there.
+
+   Contrast this with OpenPGP and S/MIME, which were designed for strong
+   cryptographic protection.  This included treating verification
+   failure as message failure.
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 10]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+3.2.3.  Permit Incremental Adoption for Incremental Benefit
+
+   DKIM can be used by any two organizations that exchange email and
+   implement DKIM; it does not require adoption within the open
+   Internet's email infrastructure.  In the usual manner of "network
+   effects", the benefits of DKIM increase as its adoption increases.
+   Although this mechanism can be used in association with independent
+   assessment services, such services are not essential in order to
+   obtain initial benefit.  For example, DKIM allows (possibly large)
+   pairwise sets of email providers and spam filtering companies to
+   distinguish mail that is associated with a known organization, versus
+   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.
+
+   In effect, the email receiver can use 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.
+
+   Management of email delivery 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 encourage senders (who might
+   subsequently complain that their email is not being delivered) to use
+   DKIM signatures.
+
+3.2.4.  Minimize the Amount of Required Infrastructure
+
+   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 individual pair of signers and verifiers who
+   are exchanging mail.  Similarly, DKIM's reliance on the Domain Name
+   System greatly reduces the amount of new administrative
+   infrastructure that is needed across the open Internet.
+
+3.2.5.  Permit a Wide Range of Deployment Choices
+
+   DKIM can be deployed at a variety of places within an organization's
+   email service.  This affords flexibility in terms of who administers
+   its use, as well as what traffic carries a DKIM signature.  For
+   example, employing DKIM at an outbound boundary MTA will mean that it
+   is administered by the organization's central IT department and that
+   internal messages are not signed.
+
+
+
+
+Hansen, et al.               Informational                     [Page 11]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+4.  DKIM Function
+
+   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 associates verifiable information with a message, especially a
+   responsible identity.  When a message does not have a valid signature
+   associated with the author, a DKIM SP will permit the domain name of
+   the author to be used for obtaining information about their signing
+   practices.
+
+4.1.  Basic Signing
+
+   With the DKIM signature mechanism, a signer chooses an SDID, performs
+   digital signing on the message, and adds the signature information
+   using a DKIM header field.  A verifier obtains the domain name and
+   the "selector" from the DKIM header field, obtains the public key
+   associated with the name, and verifies the signature.
+
+   DKIM permits any domain name to be used as the SDID, 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.
+
+   DKIM permits restricting the use of a signature key to signing
+   messages for particular types of services, such as only for a single
+   source of email.  This is intended to be helpful when delegating
+   signing authority, such as to a particular department or to a third-
+   party outsourcing service.
+
+   With DKIM, the signer explicitly lists the headers that are signed,
+   such as From:, Date:, and Subject:.  By choosing the minimal set of
+   headers needed, the signature is likely to be considerably more
+   robust against the handling vagaries of intermediary MTAs.
+
+4.2.  Characteristics of a DKIM Signature
+
+   A DKIM signature applies to 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 DKIM-Signature:, a
+   new [RFC5322] message header field.
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 12]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+4.3.  The Selector Construct
+
+   The key for a signature is associated with an SDID.  That domain name
+   provides the complete identity used for making assessments about the
+   signer.  (The DKIM specification does not give any guidance on how to
+   do an assessment.)  However, this name is not sufficient for making a
+   DNS query to obtain the key needed to verify the signature.
+
+   A single SDID can have multiple signing keys and/or multiple
+   potential signers.  To support this, DKIM identifies a particular
+   signature as using a combination of the SDID and an added field,
+   called the "selector", specified in a separate DKIM-Signature: header
+   field parameter.
+
+   NOTE:   The semantics of the selector (if any) are strictly reserved
+      to the signer and is to be treated as an opaque string by all
+      other parties.  If verifiers were to employ the selector as part
+      of an assessment mechanism, then there would be no remaining
+      mechanism for making a transition from an old, or compromised, key
+      to a new one.
+
+4.4.  Verification
+
+   After a message has been signed, any agent in the message transit
+   path can verify the signature to determine that the owner of the SDID
+   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 signed by a party in possession of the private key for
+   the SDID.  Typically, verification will be done by an agent in the
+   Administrative Management Domain (ADMD) of the message recipient.
+
+4.5.  Sub-Domain Assessment
+
+   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 as the SDID tag, such as
+   "transaction.example.com" versus "newsletter.example.com", or
+   "productA.example.com" versus "productB.example.com".  These can be
+   entirely separate from the rfc5322.From header field domain.
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 13]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+5.  Service Architecture
+
+   DKIM uses external service components, such as for key retrieval and
+   relaying email.  This specification defines an initial set, using DNS
+   and SMTP, for basic interoperability.
+                                  |
+                                  |- RFC5322 Message
+                                  V
+     +--------+    +--------------------------------+
+     | Private|    |  ORIGINATING OR RELAYING ADMD  |
+     | Key    +...>|  Sign Message with SDID        |
+     | Store  |    +---------------+----------------+
+     +--------+                    |
+      (paired)                 [Internet]
+     +--------+                    |                     +-----------+
+     | Public |    +--------------------------------+    | Remote    |
+     | Key    |    |  RELAYING OR DELIVERING ADMD   |    | Sender    |
+     | Store  |    |  Message Signed?               |    | Practices |
+     +----+---+    +-----+--------------------+-----+    +-----+-----+
+          .              |yes                 |no              .
+          .              V                    |                .
+          .        +-------------+            |                .
+          +.......>|  Verify     +--------+   |                .
+                   |  Signature  |        |   |                .
+                   +------+------+        |   |                .
+                      pass|           fail|   |                .
+                          V               |   |                .
+                   +-------------+        |   |                .
+                   |             |        |   |                .
+          +.......>| Assessments |        |   |                .
+          .        |             |        V   V                .
+          .        +-----+--+----+      +-------+              .
+          .              |  |          / Check   \<............+
+          .              |  +-------->/  Signing  \
+          .              |           /   Practices \<..........+
+          .              |          +-------+-------+          .
+          .              |                  |                  .
+          .              |                  V                  .
+     +----+--------+     |            +-----------+     +------+-----+
+     |Reputation/  |     |            | Message   |     | Local Info |
+     |Accreditation|     +----------->| Filtering |     | on Sender  |
+     |Info         |                  | Engine    |     | Practices  |
+     +-------------+                  +-----------+     +------------+
+
+                    Figure 1: DKIM Service Architecture
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 14]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   As shown in Figure 1, basic message processing is divided between a
+   signing Administrative Management Domain (ADMD) and a verifying ADMD.
+   At its simplest, this is between the originating ADMD and the
+   delivering ADMD, but can involve other ADMDs in the handling path.
+
+   signing:   Signing is performed by an authorized module within the
+      signing ADMD and uses private information from the Key Store, as
+      discussed below.  Within the originating ADMD, this might be
+      performed by the MUA, MSA, or an MTA.
+
+   verifying:   verifying is performed by an authorized module within
+      the verifying ADMD.  Within a delivering ADMD, verifying might be
+      performed by an MTA, MDA, or MUA.  The module verifies the
+      signature or determines whether a particular signature was
+      required.  Verifying the signature uses public information from
+      the Key Store.  If the signature passes, reputation information is
+      used to assess the signer and that information is passed to the
+      message filtering system.  If the signature fails or there is no
+      signature using the author's domain, information about signing
+      practices related to the author can be retrieved remotely and/or
+      locally, and that information is passed to the message filtering
+      system.
+
+   If a message has more than one valid signature, the order in which
+   the signers are assessed and the interactions among the assessments
+   are not defined by the DKIM specification.
+
+5.1.  Administration and Maintenance
+
+   A number of tables and services are used to provide external
+   information.  Each of these introduces administration and maintenance
+   requirements.
+
+   Key Store:   DKIM uses public-/private-key (asymmetric) cryptography.
+      The signer users a private key and the verifier uses the
+      corresponding public key.  The current DKIM Signing specification
+      provides for querying the Domain Names Service (DNS), to permit a
+      verifier to obtain the public key.  The signing organization
+      therefore needs to have a means of adding a key to the DNS, for
+      every selector/SDID combination.  Further, the signing
+      organization needs policies for distributing and revising keys.
+
+   Reputation/Accreditation:   If a message contains a valid signature,
+      then the verifier can evaluate the associated domain name's
+      reputation, in order to determine appropriate delivery or display
+      options for that message.  Quality assessment information, which
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 15]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+      is associated with a domain name, comes in many forms and from
+      many sources.  DKIM does not define assessment services.  Its
+      relevance to them is to provide a verified domain name, upon which
+      assessments can be made.
+
+   Signing Practices (SP):   Separate from determining the validity of a
+      signature, and separate from assessing the reputation of the
+      organization that is associated with the signed identity, there is
+      an opportunity to determine any organizational practices
+      concerning a domain name.  Practices can range widely.  They can
+      be published by the owner of the domain or they can be maintained
+      by the evaluating site.  They can pertain to the use of the domain
+      name, such as whether it is used for signing messages, whether all
+      mail having that domain name in the author rfc5322.From: header
+      field is signed, or even whether the domain owner recommends
+      discarding messages in the absence of an appropriate signature.
+      The statements of practice are made at the level of a domain name,
+      and are distinct from assessments made about particular messages,
+      as occur in a Message Filtering Engine.  Such assessments of
+      practices can provide useful input for the Message Filtering
+      Engine's determination of message handling.  As practices are
+      defined, each domain name owner needs to consider what information
+      to publish.  The nature and degree of checking practices, if any
+      are performed, is optional to the evaluating site and is strictly
+      a matter of local policy.
+
+5.2.  Signing
+
+   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 that is associated with the SDID.
+
+5.3.  Verifying
+
+   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.
+
+5.4.  Unverified or Unsigned Mail
+
+   Messages lacking a valid author signature (a signature associated
+   with the author of the message as opposed to a signature associated
+   with an intermediary) can prompt a query for any published "signing
+   practices" information, as an aid in determining whether the author
+   information has been used without authorization.
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 16]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+5.5.  Assessing
+
+   Figure 1 shows the verified identity as being used to assess an
+   associated reputation, but it could be applied to other tasks, such
+   as management tracking of mail.  Local policy guidelines may cause
+   signing practices to be checked or the message may be sent directly
+   to the message Filtering Engine.
+
+   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 the scope of DKIM,
+   other than the expectation that the verified identity produced by
+   DKIM can accumulate its own reputation, and will be 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 its practices.
+
+5.6.  DKIM Processing within an ADMD
+
+   It is expected that the most common venue for a DKIM implementation
+   will be within the infrastructures of the authoring 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's MUA, but this is expected to be less
+   typical, since it has higher administration and support costs.
+
+   A Mediator is an MUA that receives a message and can repost a
+   modified version of it, such as to a mailing list.  A DKIM signature
+   can survive some types of modifications through this process.
+   Furthermore, the Mediator can add its own signature.  This can be
+   added by the Mediator software itself, or by any outbound component
+   in the Mediator's ADMD.
+
+6.  Considerations
+
+6.1.  Security Considerations
+
+   The security considerations of the DKIM protocol are described in the
+   DKIM base specification [RFC4871], with [RFC4686] as their basis.
+
+6.2.  Acknowledgements
+
+   Many people contributed to the development of the DomainKeys
+   Identified Mail and the effort of the DKIM Working Group is
+   gratefully acknowledged.  In particular, we would like to thank Jim
+   Fenton for his extensive feedback diligently provided on every
+   version of this document.
+
+
+
+Hansen, et al.               Informational                     [Page 17]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+7.  Informative References
+
+   [Kohnfelder]  Kohnfelder, L., "Towards a Practical Public-key
+                 Cryptosystem", May 1978.
+
+   [RFC0989]     Linn, J. and IAB Privacy Task Force, "Privacy
+                 enhancement for Internet electronic mail: Part I:
+                 Message encipherment and authentication procedures",
+                 RFC 989, February 1987.
+
+   [RFC1034]     Mockapetris, P., "Domain names - concepts and
+                 facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1113]     Linn, J., "Privacy enhancement for Internet electronic
+                 mail: Part I - message encipherment and authentication
+                 procedures", RFC 1113, August 1989.
+
+   [RFC1848]     Crocker, S., Galvin, J., Murphy, S., and N. Freed,
+                 "MIME Object Security Services", RFC 1848,
+                 October 1995.
+
+   [RFC1991]     Atkins, D., Stallings, W., and P. Zimmermann, "PGP
+                 Message Exchange Formats", RFC 1991, August 1996.
+
+   [RFC2440]     Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+                 "OpenPGP Message Format", RFC 2440, November 1998.
+
+   [RFC3156]     Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
+                 "MIME Security with OpenPGP", RFC 3156, August 2001.
+
+   [RFC3851]     Ramsdell, B., "Secure/Multipurpose Internet Mail
+                 Extensions (S/MIME) Version 3.1 Message Specification",
+                 RFC 3851, July 2004.
+
+   [RFC4406]     Lyon, J. and M. Wong, "Sender ID: Authenticating
+                 E-Mail", RFC 4406, April 2006.
+
+   [RFC4407]     Lyon, J., "Purported Responsible Address in E-Mail
+                 Messages", RFC 4407, April 2006.
+
+   [RFC4408]     Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
+                 for Authorizing Use of Domains in E-Mail, Version 1",
+                 RFC 4408, April 2006.
+
+   [RFC4686]     Fenton, J., "Analysis of Threats Motivating DomainKeys
+                 Identified Mail (DKIM)", RFC 4686, September 2006.
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 18]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   [RFC4871]     Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
+                 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
+                 Signatures", RFC 4871, May 2007.
+
+   [RFC4880]     Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
+                 R. Thayer, "OpenPGP Message Format", RFC 4880,
+                 November 2007.
+
+   [RFC5322]     Resnick, P., Ed., "Internet Message Format", RFC 5322,
+                 October 2008.
+
+   [WebofTrust]  Network Associates, Inc. and its Affiliated Companies,
+                 "How PGP works, in Introduction to Cryptography", 1999,
+                 <http://www.pgpi.org/doc/pgpintro/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 19]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+Appendix A.  Internet Mail Background
+
+A.1.  Core Model
+
+   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
+   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).
+
+   An email Mediator is both an inbound MDA and outbound MSA.  It takes
+   delivery of a message, makes changes appropriate to its service, and
+   then reposts it for further distribution.  Typically, the new message
+   will retain the original rfc5322.From: header field.  A mailing list
+   is a common example of a Mediator.
+
+   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.
+
+   As elaborated on below, every MSA is a candidate for signing using
+   DKIM, and every MDA is a candidate for doing DKIM verification.
+
+A.2.  Trust Boundaries
+
+   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 a 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.
+
+   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.
+   Figure 2 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.
+
+
+
+Hansen, et al.               Informational                     [Page 20]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   Basic types of ADMDs include:
+
+      Edge:  Independent transfer services, in networks at the edge of
+         the Internet Mail service.
+
+      User:  End-user services.  These might be subsumed under an Edge
+         service, such as is common for web-based email access.
+
+      Transit:  These are Mail Service Providers (MSP) offering value-
+         added capabilities for Edge ADMDs, such as aggregation and
+         filtering.
+
+   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
+   often is directly between the Edge ADMDs, at the email level.
+
+       +--------+                            +--------+    +--------+
+       | ADMD#1 |                            | ADMD#3 |    | ADMD#4 |
+       | ------ |                            | ------ |    | ------ |
+       |        |   +----------------------->|        |    |        |
+       | User   |   |                        |--Edge--+--->|--User  |
+       |  |     |   |                   +--->|        |    |        |
+       |  V     |   |                   |    +--------+    +--------+
+       | Edge---+---+                   |
+       |        |   |    +----------+   |
+       +--------+   |    |  ADMD#2  |   |
+                    |    |  ------  |   |
+                    |    |          |   |
+                    +--->|-Transit--+---+
+                         |          |
+                         +----------+
+
+        Figure 2: ADministrative Management Domains (ADMD) Example
+
+   In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM
+   signing, and ADMD numbers 2, 3, and 4 are candidates for doing DKIM
+   verification.
+
+   The distinction between Transit network and Edge network transfer
+   services is primarily significant because it highlights the need for
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 21]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+   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.
+
+   Common ADMD examples are:
+
+         Enterprise Service Providers:
+
+            Operators of an organization's internal data and/or mail
+            services.
+
+         Internet Service Providers:
+
+            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.
+
+         Mail Service Providers:
+
+            Operators of email services, such as for end users, or
+            mailing lists.
+
+Index
+
+   A
+      ADMD  6
+      Administrative Management Domain  6
+      assessment  7
+
+   D
+      DKIM-Signature  12-13
+      DNS  6, 13-15
+
+   I
+      identifier  4-8
+      identity  3-7, 9, 12
+      infrastructure  5-6, 8-11, 17
+
+   M
+      Mail Delivery Agent  6
+      Mail Handling Service  6
+      Mail Service Provider  6
+      Mail Submission Agent  6
+
+
+
+Hansen, et al.               Informational                     [Page 22]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+      Mail Transfer Agent  6
+      Mail User Agent  6
+      MDA  6
+      MHS  6
+      MIME Object Security Services  5
+      MOSS  5
+      MSA  6
+      MSP  6
+      MTA  6
+      MUA  6
+
+   O
+      OpenPGP  5
+
+   P
+      PEM  5
+      PGP  5
+      Pretty Good Privacy  5
+      Privacy Enhanced Mail  5
+
+   S
+      S/MIME  5
+
+   T
+      trust  3, 7-8, 20
+
+   V
+      verification  4, 7-8, 10-11, 13, 16, 20-21
+
+   W
+      Web of Trust  6
+
+   X
+      X.509  6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 23]
+
+RFC 5585                 DKIM Service Overview                 July 2009
+
+
+Authors' Addresses
+
+   Tony Hansen
+   AT&T Laboratories
+   200 Laurel Ave.
+   Middletown, NJ  07748
+   USA
+
+   EMail: tony+dkimov@maillennium.att.com
+
+
+   Dave Crocker
+   Brandenburg InternetWorking
+   675 Spruce Dr.
+   Sunnyvale, CA  94086
+   USA
+
+   EMail: dcrocker@bbiw.net
+
+
+   Phillip Hallam-Baker
+   Default Deny Security, Inc.
+
+   EMail: phillip@hallambaker.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Informational                     [Page 24]
+