DomainKeys Identified Mail                                     T. Hansen
Internet-Draft                                         AT&T Laboratories
Intended status: Informational                           P. Hallam-Baker                                 E. Siegel
Expires: May 7, August 13, 2009                          Constant Contact, Inc.
                                                         P. Hallam-Baker
                                                           VeriSign Inc.
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                               E. Siegel
                                                  Constant Contact, Inc.
                                                        November 3, 2008
                                                        February 9, 2009

DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
                     draft-ietf-dkim-deployment-02
                     draft-ietf-dkim-deployment-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 7, August 13, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   DomainKeys Identified Mail (DKIM) allows an organization to take claim
   responsibility for transmitting 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 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, using the domain name service as its key server
   technology [RFC4871].  This permits verification of a responsible
   organization, as well as the integrity of the message 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 about messages.
   DKIM's authentication of email identity can assist in the global
   control of "spam" and "phishing. "phishing".  This document provides
   implementation, deployment, operational and migration considerations
   for DKIM.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  5
   2.  Key Generation, Storage, and Management  Using DKIM as Part of Trust Assessment . . . . . . . . . . .  3 .  5
     2.1.  General Coding Criteria for Cryptographic Applications  A Systems View of Email Trust Assessment . .  3 . . . . . . .  5
     2.2.  Key Generation and Storage  Choosing a DKIM Tag for the Assessment Identifier  . . . .  7
     2.3.  Choosing the Signing Domain Name . . . . . . . . . . . .  4
     2.3.  DNS Signature Record Deployment and Maintenance
           Considerations .  9
     2.4.  Recipient-based Assessments  . . . . . . . . . . . . . . . 11
     2.5.  Filtering  . . . . . .  5
   3.  Signing . . . . . . . . . . . . . . . . . . 12
   3.  DKIM Key Generation, Storage, and Management . . . . . . . . .  8 14
     3.1.  Private Key Management: Deployment and Ongoing
           Operations . . . . . . . . . . . . . . . . . . . . . . . .  8 15
     3.2.  Mailing Lists  Storing Public Keys: DNS Server Software Considerations  . 16
     3.3.  Per User Signing Key Management Issues . . . . . . . . . . 17
     3.4.  Third Party Signer Key Management and Selector
           Administration . . . . . . . . . . . . 10
     3.3.  Signature Transition Strategy . . . . . . . . . . 17
     3.5.  Key Pair / Selector Lifecycle Management . . . . 12
   4.  Verifying . . . . . 18
   4.  Signing  . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Verifier . . . . . . 19
     4.1.  DNS Records  . . . . . . . . . . . . . . . . . . . . 14
     4.2.  DNS Client . . . 19
     4.2.  Signing Module . . . . . . . . . . . . . . . . . . . . . . 14 20
     4.3.  Boundary Enforcement  Signing Policies and Practices . . . . . . . . . . . . . . 20
   5.  Verifying  . . . . . 15
     4.4.  Filtering Software . . . . . . . . . . . . . . . . . . . . 15
   5.  DKIM Deployment Considerations for Email Agents . 21
   6.  Taxonomy of Signatures . . . . . . . . . . 15
     5.1.  Email Infrastructure Agents . . . . . . . . . . 21
     6.1.  Single Domain Signature  . . . . . 15
     5.2.  Mail User Agent . . . . . . . . . . . . 21
     6.2.  Parent Domain Signature  . . . . . . . . . . 17
   6.  Migrating from DomainKeys . . . . . . . 22
     6.3.  Third Party Signature  . . . . . . . . . . . . 17
     6.1. . . . . . . 23
     6.4.  Using Trusted 3rd Party Senders  . . . . . . . . . . . . . 24
     6.5.  Multiple Signatures  . . . . . . . . . . . . . . . . . . . 25
   7.  Example Usage Scenarios  . . . . . . . . . . . . . . . . . . . 27
     7.1.  Author's Organization - Simple . . . . . . . . . . . . . . 27
     7.2.  Author's Organization - Differentiated Types of Mail . . . 27
     7.3.  Author Signature . . . . . . . . . . . . . . . . . . . . . 27
     7.4.  Author Domain Signing Practices  . . . . . . . . . . . . . 28
     7.5.  Delegated Signing  . . . . . . . . . . . . 17
     6.2.  Verifying . . . . . . . . 28
     7.6.  Independent Third Party Service Providers  . . . . . . . . 28
     7.7.  Mail Streams Based on Behavioral Assessment  . . . . . . . 29
     7.8.  Agent or Mediator Signatures . 18
   7.  Example Uses . . . . . . . . . . . . . . 29
   8.  Usage Considerations . . . . . . . . . . . 18
     7.1. . . . . . . . . . . 30
     8.1.  Non-standard Submission and Delivery Scenarios . . . . . . 30
     8.2.  Protection of Internal Mail  . . . . . . . . . . . . . . . 18
     7.2.  Recipient-based Assessments 31
     8.3.  Signature Granularity  . . . . . . . . . . . . . . . 19
     7.3.  DKIM Support in the Client . . . 31
     8.4.  Email Infrastructure Agents  . . . . . . . . . . . . . 19
     7.4.  Per user signatures . . 32
     8.5.  Mail User Agent  . . . . . . . . . . . . . . . . . 19
   8.  Security . . . . 34
   9.  Other Considerations . . . . . . . . . . . . . . . . . . . 20
   9.  IANA . . 35
     9.1.  Security Considerations  . . . . . . . . . . . . . . . . . 35
     9.2.  IANA Considerations  . . . . . . 20 . . . . . . . . . . . . . 35
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 35
   11. Informative References . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses 35
   Appendix A.  Migrating from DomainKeys . . . . . . . . . . . . . . 37
     A.1.  Signers  . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 23

1.  Introduction

   There are many areas to be considered when deploying . . . . . 37
     A.2.  Verifiers  . . . . . . . . . . . . . . . . . . . . . . . . 40
   Appendix B.  General Coding Criteria for Cryptographic
                Applications  . . . . . . . . . . . . . . . . . . . . 41
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42

1.  Introduction

   DomainKeys Identified Mail (DKIM). (DKIM) allows an organization to claim
   responsibility for transmitting a message, in a way that can be
   validated by a recipient.  This document provides practical tips for:
   those who are developing DKIM software, mailing list managers,
   filtering strategies based on the output from DKIM verification, and
   DNS servers; those who are deploying DKIM software, keys, mailing
   list software, and migrating from DomainKeys; and those who are
   responsible for the on-going operations of an email infrastructure
   that has deployed DKIM.

   The document is organized aorund around the key concepts related to DKIM.
   Within each section, additional considerations specific to
   development, deployment, or ongoing operations are highlighted where
   appropriate.

   [[anchor2: MSK: maybe this is a good place to mention the possibility
   of collecting verification history for selectors domains as a means
   of observing over time behaviour of signers for the purpose of
   asserting local reputation]]

2.  Key Generation, Storage, and Management  Using DKIM defines a domain-level digital signature authentication
   framework for email, using public key cryptography, using the domain
   name service as its key server technology [RFC4871].  This section
   covers considerations around generating, deploying, and managing the
   public and private keys required for DKIM to function. Part of Trust Assessment

2.1.  General Coding Criteria for Cryptographic Applications

   NOTE: This section could possibly be changed into  A Systems View of Email Trust Assessment

   DKIM participates in a reference trust-oriented enhancement to
   something else, the Internet's
   email service, to facilitate message handling decisions, such as another rfc.

   Correct implementation for
   delivery and for content display.  Trust-oriented message handling
   has substantial differences from approaches that consider messages in
   terms of a cryptographic algorithm risk and abuse.  With trust, there is a necessary
   but not collaborative
   exchange between a sufficient condition for willing participant along the coding of cryptographic
   applications.  Coding of cryptographic libraries requires close
   attention to security considerations that are unique to cryptographic
   applications. sending path and a
   willing participant at the recipient site.  In addition to contrast, the usual security coding considerations, such as
   avoiding buffer or integer overflow and underflow, implementers
   should pay close attention to management risk
   model entails independent action by the recipient site, in the face
   of cryptographic private
   keys and session keys, ensuring that these are correctly initialized a potentially unknown, hostile and disposed of.

   Operating system mechanisms that permit deceptive sender.  This
   translates into a very basic technical difference: In the confidentiality face of
   private keys to be protected against other processes should be used
   when available.  In particular, great care
   unilateral action by the recipient and even antagonistic efforts by
   the sender, risk-oriented mechanisms must be taken when
   releasing memory pages to based on heuristics,
   that is, on guessing.  Guessing produces statistical results with
   some false negatives and some false positives.  For trust-based
   exchanges, the operating system to ensure goal is the deterministic exchange of information.
   For DKIM, that private
   key information is not disclosed to other processes.

   Certain implementations of public key algorithms such as RSA may be
   vulnerable to the one identifier that represents a timing analysis attack.

   Support for cryptographic hardware providing key management
   capabilities is strongly encouraged.  In addition to offering
   performance benefits, many cryptographic hardware devices provide
   robust and verifiable management
   stream of private keys.

   Fortunately appropriately designed and coded cryptographic libraries
   are available mail for most operating system platforms under license terms
   compatible with commercial, open source and free software license
   terms.  Use of standard cryptographic libraries which an independent assessment is strongly
   encouraged.  These have been extensively tested, reduce development
   time and support sought (by the
   signer.)

   A trust-based service is built upon a wide range validated Responsible
   Identifier that labels a stream of cryptographic hardware.

2.2.  Key Generation mail and Storage

2.2.1.  Assignment of Selectors

   Selectors  Selectors are assigned according to the administrative
      needs is controlled by an
   identity (role, person or organization.)  The identity is
   acknowledging some degree of the signing domain, such as responsibility for rolling over to the message stream.
   Given a new key
      or basis for delegating of believing that an identifier is being used in an
   authorized manner, the right to authenticate a portion recipient site can make and use an assessment
   of the
      namespace to a trusted third party.

   Examples include:   jun2005.eng._domainkey.example.com

      widget.promotion._domainkey.example.com

   NOTE:   It is intended that assessments of DKIM identities be based associated identity.  An identity can use different
   identifiers, on the domain name, and not include assumption that the selector.  This permits different streams might
   produce different assessments.  For example, even the selector best-run
   marketing campaigns will tend to be used only for key administration, rather than
      having an effect on reputation assessment.

      [[anchor7: The produce some complaints that can
   affect the reputation of the associated identifier.  Whereas a selector could become relevant if
      it stream
   of transactional messages is known likely to have "gone rogue" before the DNS owner has a chance
      to published a new zone update which contains more pristine
   reputation.

   Determining that the identifier's use is valid is quite different
   from determining that the content of a revoked key.]]

2.2.2.  Third Party Key Management

   ????????????????

   [[anchor9: what are we trying to cover here? message is valid.  The case where a 3rd
   party generates keys and provides the public key to former
   means only that the domain owner
   to publish?  Or identifier for the case where responsible role, person or
   organization has been legitimately associated with a message.  The
   latter means that the domain owner generates keys and
   provides content of the private key to message can be believed and,
   typically, that the third party?  Either way, I think we
   need some discussion claimed author of 1st vs. 3rd party (preferably that the
   distinction has little relevance except in content is correct.  DKIM
   validates only the presence of ADSP,
   since otherwise the reputation identifier used to sign the
   message.  Even when this identifier is validated, DKIM carries no
   implication that any of the signing domain and not message content, including the 1st
   or 3rd party nature of it is what
   RFC5322.From field, is relevant.]]

   3rd party generates valid.  Surprisingly, this limit to the public / private key pair and sends
   semantics of a DKIM signature applies even when the
   public key to be published validated signing
   identifier is the same domain name as is used in the DNS.

2.2.3.  Storing Public Keys: DNS Server Software Considerations

   At a minimum, a DNS server From: field!
   DKIM's only claim about message content is that handles queries for DKIM key records
   must allow the server administrators to add free-form TXT records.
   It would be better if the content cited in
   the DKIM records could be entered using DKIM-Signature: field's h= tag have been delivered without
   modification.  That is, it asserts message content integrity, not
   message content validity.

   As shown in Figure 1, this enhancement is a
   structured form, supporting communication between a
   responsible role, person or organization that signs the DKIM-specific fields.

2.2.4.  Private Key Management: Deployment message and Ongoing Operations

   The permissions of private key files must be carefully managed.  If
   key management hardware support is available, it should be used.
   Auditing software should be used periodically to verify a
   recipient organization that assesses its trust in the
   permissions on the private key files remain secure.

2.3.  DNS Signature Record Deployment signer and Maintenance Considerations

   Even with use then
   makes handling decisions based on a collection of assessments, of
   which the DNS, one challenge is that DNS record management
   is usually operated by an administrative staff that DKIM mechanism is different from
   those who operate an organization's email service. only a part.  In order to
   ensure that DKIM DNS records are accurate, this imposes model, validation
   is an intermediary step, having the sole task of passing a requirement
   for careful coordination between validated
   Responsible Identifier to the two operations groups. Identity Assessor.  The key point to remember communication
   is of a single Responsible Identifier that the DNS DKIM selectors WILL Responsible Identity
   wishes to have used by the Identity Assessor.  The Identifier is the
   sole, formal input and
   should be changed over time.  Some reasons for changing output value of DKIM
   selectors are well understood, while others are still theoretical.
   There signing.  The Identity
   Assessor uses this single, provided Identifier for consulting
   whatever assessment data bases are several schemes that may be used to determine deemed appropriate by the policies
   for changing DKIM selectors:

   o  time based

   o  associations
   assessing entity.  In turn, output from the Identity Assessor is fed
   into a Handling Filter engine that considers a range of factors,
   along with clusters this single output value; the range of servers
   o factors can include
   ancillary information from the use DKIM validation.

   Identity Assessment covers a range of third party signers

   o  security considerations

   A potential mistake in creating possible functions.  It can be
   as simple as determining whether the DNS key record identifier is the erroneous
   use of a backslash (\) member of some
   list, such as authorized operators or participants in the definition.  Some implementations
   reading a zone file allow a backslash to be used anywhere, stripping
   any such occurrences.  Other implementations only allow it to group that
   might be used
   in front of an quotation mark, storing the backslash in the record
   and causing interest for recipient assessment.  Equally, it can
   indicate a syntax error degree of trust (reputation) that is to be generated by DKIM implementations
   reading afforded the record.

2.3.1.  Time Basis and Security Considerations
   actor using that identifier.  The reason for changing the selector periodically is usually related extent to which the security exposure assessment
   affects handling of a system.  When the potential exposure message is, of course, determined later, by
   the private keys associated with the Handling Filter.

     +------+------+                            +------+------+
     |   Author    |                            |  Recipient  |
     +------+------+                            +------+------+
            |                                          ^
            |                                          |
            |                                   +------+------+
            |                                -->|  Handling   |<--
            |                                -->|   Filter    |<--
            |                                   +-------------+
            |                                          ^
            V                  Responsible             |
     +-------------+           Identifier       +------+------+
     | Responsible |. .       . . . . . . . . .>|  Identity   |
     |  Identity   |  .       .                 |  Assessor   |
     +------+------+  .       .                 +-------------+
            |         .       .                       ^ ^
            V         .       .                       | |
   +------------------.-------.--------------------+  | |
   | +------+------+  . . . . .   +-------------+  |  | |  +-------------+
   | | Identifier  |              |  Identifier +--|--+ +--+ Assessment  |
   | |   Signer    +------------->|  Validator  |  |       | Databases   |
   | +-------------+              +-------------+  |       +-------------+
   |                 DKIM Service                  |
   +-----------------------------------------------+

              Figure 1: Actors in a Trust Sequence using DKIM selector have reached
   sufficient levels,

2.2.  Choosing a DKIM Tag for the selector should be changed.  (It is unclear
   currently what kinds Assessment Identifier

   The signer of metrics can a message needs to be used able to aid in deciding when
   the exposure has reached sufficient levels provide precise data and
   know what that data will mean upon delivery to warrant changing the
   selector.)

   For example,

   o  Selectors should Assessor.  If
   there is ambiguity in the choice that will be changed more frequently made on systems the receive
   side, then the sender cannot know what basis for assessment will be
   used.  DKIM has three values that are
      widely exposed, than on systems that are less widely exposed.  For
      example, a gateway system that has numerous externally-accessible
      services running on specify identification information
   and it is more widely exposed than easy to confuse their use, although only one that ONLY
      runs a mail server.

   o  Selectors should be changed more frequently on operating systems
      that are under wide attack.

   o  While defines the use
   formal input and output of DKIM information is transient, keys DKIM, with
      sufficient exposure do become stale the other two being used for
   internal protocol functioning and should be changed.

   o  Whenever you make a substantial system change, adjunct purposes, such as bringing up
      a new server, or making a major operating system change, you
      should consider changing auditing
   and debugging.

   The salient values include the selector.

      [[anchor14: above you refer to changing s=, d= and i= parameters in the key, here you refer DKIM-
   Signature: header field.  In order to
      changing achieve the selector; they have not been explicitly declared as
      synonymous so end-to-end
   determinism needed for this could be confusing]]

   o  Whenever there is either suspicion or evidence of the compromise
      of the system or collaborative exchange from the private keys, you should change signer to
   the selector.

2.3.2.  Deploying New Selectors

   A primary consideration in changing assessor, the selector is remembering to
   change it.  It core model needs to be specify that the signer MUST
   provide the assessor with a standard part of single, opaque value that the operational staff
   Methods and Procedures signer
   wishes to have used for your systems.  If they are separate, both assessment.  This value MUST be the mail team and basis for
   DKIM-based assessment.  The signer MAY provide the DNS team will be involved in deploying new
   selectors.

   When deploying assessor with a new selector, it needs to
   second, opaque value that MAY be phased in:

   1.  Generate used when reporting problems with
   the new public / private key pair end-to-end DKIM process and create a new
       selector record with MAY be used for additional analysis,
   such as by the public key higher-level Handling Filter.  These values are
   opaque, in it.

   2.  Add the new selector record to your DNS.

   3.  Verify that any internal semantics are known only to the new selector record can signer
   and MUST NOT be used to verify
       signatures.

   4.  Turn on signing with assumed by the new private key.

   5.  Remove Assessor, within the old private key from your servers.

   6.  After a period confines of time, remove the old selector from your DNS.
   DKIM's formal signing specification.  Assessment MUST use a value as
   a single, complete and uninterpreted string.

   The time an unused selector should be kept in the DNS system is
   dependent on the reason it's being changed.  If single, mandatory value that DKIM supplies as its output is:

      d=    This specifies the private key has
   definitely been exposed, "domain of the corresponding selector should be removed
   immediately.  Otherwise, longer periods are allowable.

   [[anchor16: interesting; should we have included signing entity."  It is a "u=" ('until') tag
   on key records allowing an advertised "good until" timestamp?]]

2.3.3.  Subdomain Considerations

   A Domain Name
         domain name and is combined with the basis for making differential quality
   assessments about Selector to form a DKIM-signed message. DNS
         query.

   The adjunct values are:

      s=    This tag specifies the Selector.  It is reasonable for a
   single organization to have a variety of very different activities,
   which warrant a variety of very different assessments.  A convenient
   way used to distinguish discriminate
         among such activities is to sign with different
   domain names.  That is, the organization should sign with sub-domain
   names keys that are can be used for different organizational activities.

2.3.4.  Delegating Signing Authority to a Third party

   Allowing third parties to sign email from your domain opens your
   system security to include the security same d= domain
         name.  As discussed in Section 4.3 of the third party's systems.
   At a minimum, you should not allow the third parties [I-D.ietf-dkim-overview]:
         "If verifiers were to use employ the same selector and private key as your main mail system.  It is recommended
   that each third party part of a name
         assessment mechanism, then there would be given its own private no remaining
         mechanism for making a transition from an old, or compromised,
         key and selector.
   This limits to a new one."  Consequently, the exposure Selector is not
         appropriate for any given private key, and minimizes use as part or all of the
   impact if any given private key were exposed.

3.  Signing

3.1.  Deployment

   Creating messages that have DKIM signatures requires a modification identifier used to only two portions of
         make assessments.

      i=    This tag is optional and provides the email service:

   o  Addition of relevant DNS information.

   o  Addition "[i]dentity of the signature by
         user or agent (e.g., a trusted module within mailing list manager) on behalf of which
         this message is signed."  The identity can be in the
      organization's syntax of
         an entire email handling service. address or only a domain name.  The signing module uses domain name
         can be the appropriate private key to create same as for d= or it can be a
   signature.  The means by which sub-name of the signing module obtains d=
         name.

         NOTE: Although the private
   key is not specified by DKIM.  Given that DKIM is intended for use
   during i= identity has the syntax of an email transit, rather than for long-term storage,
         address, it is
   expected that keys will be changed regularly.  Clearly this means not required to have that key information should semantics.  That is,
         "the identity of the user" need not be hard-coded into software.

3.1.1.  DNS Records

   A receiver attempting to verify a DKIM signature must obtain the
   public key that is associated with same as the signature for that message.
   The DKIM-Signature header in user's
         mailbox.  For example the message will specify signer might wish to use i= to encode
         user-related audit information, such as how they were accessing
         the basic
   domain name doing service at the signing and time of message posting.  Therefore it is
         not possible to conclude anything from the selector i= string's
         (dis)similarity to be used for email addresses elsewhere in the
   specific public key.  Hence, header

   So, i= can have any of these properties:

      *  Be a valid domain when it is the relevant
   <selector>._domainkey.<domain-name> DNS record needs same as d=

      *  Appear to contain be a
   DKIM-related resource record (RR) that provides the public key
   information.

   The administrator sub-domain of the zone containing the relevant domain name
   adds this information.  Initial DKIM DNS information is contained
   within TXT RRs.  DNS administrative software varies considerably in
   its abilities to add new types d= but might not even exist

      *  Look like a mailbox address but might have different semantics
         and therefore not function as a valid email address

      *  Be unique for each message, such as indicating access details
         of DNS records.

3.1.2.  Signing Module

   The module doing signing can be placed anywhere within an
   organization's trusted Administrative Management Domain (ADMD);
   common choices are expected the user for the specific posting

   This underscores why the tag needs to be department-level posting and
   delivering agents, as well treated as boundary MTAs being opaque,
   since it can represent any semantics, known only to the open Internet.
   (Note signer.

   Hence, i= serves well as a token that it is entirely acceptable usable like an Web cookie,
   for MUAs return to perform the signing ADMD -- such as for auditing and
   verification.)  Hence the choice among debugging.
   Of course in some scenarios the modules depends upon
   software development and administrative overhead tradeoffs.

   [[anchor23: See earlier note about signing by MUAs being i= string might provide a security
   concern]] One perspective that helps resolve this choice is useful
   adjunct value for additional (heuristic) processing by the
   difference between Handling
   Filter.

2.3.  Choosing the flexibility Signing Domain Name

   A DKIM signing entity can serve different roles, such as author of
   content, versus operator of use by systems at (or close to) the MUA, mail service, versus operator of a
   reputation service.  In these different roles, the centralized control basis for
   distinguishing among portions of email traffic can vary.  For an
   entity creating DKIM signatures it is likely that different portions
   of their mail will warrant different levels of trust.  For example:

      *  Mail is more easily obtained
   by implementing the mechanism "deeper" into the organization's email
   infrastructure, sent for different purposes, such as at its boundary MTA.

3.1.3.  DKIM Signing Software Development

   Signer implementations should provide a convenient means marketing vs.
         transactional, and recipients demonstrate different patterns of
   generating DNS key records corresponding to the signer configuration.
   Support for automatic insertion
         acceptance between these.

      *  For an operator of key records into the DNS is also
   highly desirable.  If supported however, such mechanism(s) must be
   properly authenticated.

   A means an email service, there often are distinct
         sub-populations of verifying that the signer configuration users warranting different levels of trust
         or privilege, such as paid vs. free users, or users engaged in
         direct correspondence vs. users sending bulk mail.

      *  Mail originating outside an operator's system, such as when it
         is compatible redistributed by a mailing list service run by the operator,
         will warrant a different reputation from mail submitted by
         users authenticated with the signature policy operator.

   It is also highly desirable.

   Disclosure therefore likely to be useful for a signer to use different d=
   sub-domain names, for different message traffic streams, so that
   receivers can make differential assessments.  However, too much
   differentiation -- that is, too fine a granularity of signing domains
   -- makes it difficult for the receiver to discern a private signature key component sufficiently
   stable pattern of traffic for developing an accurate and reliable
   assessment.  So the differentiation needs to achieve a third party
   allows balance.
   Generally in a trust system, legitimate signers have an incentive to
   pick a small stable set of identities, so that third party recipients and others
   can attribute reputations to impersonate the sender. them.  The protection set of
   private signature key data these identities a
   receiver trusts is therefore likely to be quite a critical concern.  Signers
   should support use of cryptographic hardware providing key management
   features.

3.1.3.1.  Signer Actions

   All Signers should:

   o  Include any existing Sender header field bit smaller than the set it
   views as risky.

   The challenge in using additional layers of sub-domains is whether
   the signed header
      field list, if extra granularity will be useful for the Sender header field exists.

   o  ...

   Signers wishing to avoid assessor.  In fact,
   potentially excessive levels invites ambiguity: if the use assessor does
   not take advantage of Third-Party Signatures should do
   everything listed above, and also:

   o  Include the Sender header field name in the header field list
      ("h=" tag) under all circumstances, even if the Sender header
      field does not exist in the header block.  This prevents another
      entity from adding a Sender header field.

   o  Publish Signing Practices that do not sanction added granularity, then what granularity
   will it use?  That ambiguity would move the use of Third-
      Party Signatures.

3.1.4.  Signing Policies and Practices

   Every organization (ADMD) will have its own policies and practices
   for deciding when DKIM back to sign messages and with what domain name and key
   (selector).  Examples include signing all mail, signing mail from
   particular email addresses, or signing mail from particular sub-
   domains.  Given this variability, and the likelihood that signing
   practices will change over time, it will be useful to have these
   decisions represented in some sort
   realm of configuration information, heuristics, rather than being more deeply coded into the signing software.

3.2.  Mailing Lists

   A mailing list often provides facilities to its administrator to
   manipulate parts of the mail messages deterministic processing that flow through is
   its goal.

   Hence the list. challenge is to determine a useful scheme for labeling
   different traffic streams.  The desired goal most obvious choices are among
   different types of content and/or different types of authors.
   Although stability is essential, it is likely that messages flowing through the mailing list choices will be verifiable by the recipient as being from
   change, over time, so the list, or
   failing that, as being from scheme needs to be flexible.

   For those originating message content, the individual list members.

   There are several forms most likely choice of mailing lists, sub-
   domain naming scheme will by based upon type of content, which interact with signing
   in different ways.

   o  "Verbatim" mailing lists send messages without modification
      whatsoever.  They can
   use content-oriented labels or service-oriented labels.  For example:

   transaction.example.com
   newsletter.example.com
   bugreport.example.com
   support.example.com
   sales.example.com
   marketing.example.com

   where the choices are often implemented as MTA-based aliases.
      Since best dictated by whether they do not modify provide the message, signatures are unaffected
      and will continue
   Identity Assessor with the ability to verify.  It is not necessary discriminate usefully among
   streams of mail that demonstrate significantly different degrees of
   recipient acceptance or safety.  Again, the danger in providing too
   fine a granularity is that related message streams that are labeled
   separately will not benefit from an aggregate reputation.

   For those operating messaging services on behalf of a variety of
   customers, an obvious scheme to use has a different sub-domain label
   for each customer.  For example:

                          widgetco.example.net
                          moviestudio.example.net
                          bigbank.example.net

   However it can also be appropriate to label by the
      forwarder class of service
   or class of customer, such as:

   premier.example.net
   free.example.net
   certified.example.net

   Prior to re-sign using domain names for distinguishing among sources of data,
   IP Addresses have been the message; however, some may choose basis for distinction.  Service operators
   typically have done this by dedicating specific outbound IP Addresses
   to do
      so in order specific mail streams -- typically to certify that specific customers.  For
   example, a university might want to distinguish mail from the message was sent through
   Administration, versus mail from the list.

   o  "Digesting" mailing lists collect together one or more postings
      and then retransmit them, often on student dorms.  In order to make
   adoption of a nightly basis, DKIM-based service easier, it can be reasonable to
   translate the
      subscription list.  These are essentially entirely new messages
      which must be independently authored (that is, they will have same partitioning of traffic, using domain names in
   place of the different IP Addresses.

2.4.  Recipient-based Assessments

   DKIM gives the recipient site's Identity Assessor a
      "From" header field referring verifiable
   identifier to use for analysis.  Although the list, mechanism does not make
   claims that the submitters) and
      signed by the Mailing List Manager itself, if they are signed at
      all.

   o  "Resending" mailing lists receive signer is a message, modify Good Actor or a Bad Actor, it (often does make
   it possible to
      add "unsubscribe" information or advertising), and immediately
      resend know that message to use of the subscription list.  They are
      problematic because they usually identifier is valid.  This is in
   marked contrast with schemes that do not change have authentication.
   Without verification, it is not possible to know whether the "From" header
      field of
   identifier -- whether taken from the message, but they do invalidate RFC5322.From field,
   RFC5321.MailFrom command, or the signature in like -- is being used by an
   authorized agent.  DKIM solves this problem.  Hence with DKIM, the
      process of modifying
   Assessor can know that two messages with the message.

   In most cases, the list and/or its mail host should add its own same DKIM
   signature to list mail.  This could be done d= identifier
   are, in fact, signed by the list management
   software, same person or organization.  This
   permits a far more stable and accurate assessment of mail traffic
   using that identifier.

   DKIM is distinctive, in that it provides an outgoing MSA or MTA, or both.  List management
   software often makes modifications identifier which is not
   necessarily related to messages that will break
   incoming signatures, such as adding subject tags, adding message
   headers or footers, and adding, deleting, or reordering MIME parts.
   By adding its own signature after these modifications, any other identifier in the list
   provides message.  Hence,
   the signer might be the author's ADMD, one of the operators along the
   transit path, or a verifiable, recognizable signature for list recipients. reputation service being used by one of those
   handling services.  In some cases, the modifications made fact, a message can have multiple signatures,
   possibly by different of these actors.

   As discussed above, the mailing list software
   are simple enough that signatures choice of identifiers needs to be based on incoming messages
   differences that the signer thinks will still be
   verifiable after being remailed by useful for the list.  It recipient
   Assessor.  Over time, industry practices establish norms for these
   choices.

      Absent such norms, it is still preferable best for signers to distinguish among
      streams that have significant differences, while consuming the list sign its mail so
      smallest number of identifiers possible.  This will limit the
      burden on recipient Assessors.

   A common view about a DKIM signature is that recipients can distinguish
   between mail sent through it carries a degree of
   assurance about some or all of the list message contents, and mail sent directly in
   particular that the RFC5322.From field is likely to a list
   member. be valid.  In
   fact, DKIM makes assurances only about the absence integrity of a list signature, a recipient may still be
   able to recognize and use the original signatures data and
   not about its validity.  Still, presumptions of the list
   members.

   The first two cases act in obvious ways and do not require further
   discussion.  The remainder of this session applies only From: field validity
   remain a concern.  Hence a signer using a domain name that is
   unrelated to the third
   case.

3.2.1.  Mailing List Manager Actions

   Mailing List Managers should make every effort domain name in the From: field can reasonably expect
   that the disparity will warrant some curiosity, at least until
   signing by independent operators has produced some established
   practice among recipient Assessors.

2.5.  Filtering

   After assessing the signer of a message, each receiving site creates
   and tunes its own Handling Filter according to ensure criteria specific for
   that
   messages site.  Still, there are commonalities across sites, and this
   section offers a discussion, rather than a specification, of some
   types of input to that process and how they relay can be used.

   The discussion focuses on variations in Organizational Trust versus
   Message Risk.  That is, the degree of positive assessment of a DKIM-
   signing organization, and which have Valid Signatures upon receipt
   also have Valid Signatures upon retransmission.  In particular,
   Mailing List Managers that modify the message potential danger present in ways that break
   existing signatures should:

   o  Verify any existing DKIM Signatures.  A DKIM-aware Mailing List
      Manager must NOT re-sign an improperly signed the message in such a
      way
   stream signed by that would imply organization.  While it might seem that higher
   trust automatically means lower risk, the existing signature is acceptable.

   o  Apply regular anti-spam policies.  A Mailing List Manager should
      apply message content security policy just experience with real-world
   operations provides examples of every combination of the two factors,
   as would be done shown in Table 1.  Only 3 levels of granularity are listed, in
   order to
      messages destined keep discussion manageable.  This also ensures extensive
   flexibility for an individual user's mailbox.  In fact, each site's detailed choices.

   +---+---------------------+--------------------+--------------------+
   |   | Low                 | Medium             | High               |
   |   |                     |                    |                    |
   |   |                     |                    |                    |
   |   |                     |                    |                    |
   |   |                     |                    |                    |
   | O |                     |                    |                    |
   | R |                     |                    |                    |
   | G |                     |                    |                    |
   |   |                     |                    |                    |
   | T |                     |                    |                    |
   | R |                     |                    |                    |
   | U |                     |                    |                    |
   | S |                     |                    |                    |
   | T |                     |                    |                    |
   |   |                     |                    |                    |
   | M |                     |                    |                    |
   +---+---------------------+--------------------+--------------------+
   | * | Unknown org,        | Registered org,    | Good Org,          |
   | L | Few msgs:           | New Identifier:    | Good msgs:         |
   | o | _Mild filtering_    | _Medium filtering_ | _Avoid FP(!)_      |
   | w |                     |                    |                    |
   | * | Unknown org,        | Registered org,    | Good org, Bad msg  |
   | M | New Identifier:     | Mixed msgs:        | burst:             |
   | e | _Default filtering_ | _Medium filtering_ | _Accept & Contact_ |
   | d |                     |                    |                    |
   | i |                     |                    |                    |
   | u |                     |                    |                    |
   | * | Black-Listed org,   | Registered org,    | Good org,          |
   | H | Bad msgs:           | Bad msgs:          | Compromised:       |
   | i | _Avoid FN(!)_       | _Strong filtering_ | _Fully blocked_    |
   | g |                     |                    |                    |
   | h |                     |                    |                    |
   +---+---------------------+--------------------+--------------------+

              Table 1: Organizational Trust vs. Message Risk

   The table indicates preferences for different handling of different
   combinations, such as tuning filtering to avoid False Positives (FP)
   or avoiding False Negatives (FN).  Perhaps unexpectedly, it also
   lists a
      Mailing List Manager case in which the receiving site might apply a higher standard to messages
      destined wish to a mailing list deliver
   problematic mail, rather than would normally be applied to
      individual messages.
      NON-NORMATIVE RATIONALE: Since reputation will accrue to signers,
      Mailing List Managers should verify redirecting it, but also of course
   contacting the source and content signing organization, seeking resolution of
      messages before they are willing to sign lest their reputation be
      sullied by nefarious parties.

   o  Add a Sender header field using a valid address pointing back to the Mailing List Administrator or an appropriate agent (such as an
      "owner-" or
   problem.

3.  DKIM Key Generation, Storage, and Management

   By itself, verification of a "-request" address).

   o  Sign digital signature only allows the resulting message
   verifier to conclude with a signature very high degree of certainty that is valid for the
      Sender header field address.  The Mailing List Manager should NOT
      sign messages for which they are unwilling to accept
      responsibility.

   Mailing List Managers MAY:

   o  Reject messages
   signature was created by a party with signatures access to the corresponding
   private signing key.  It follows that do not verify or are
      otherwise Suspicious.

      [[anchor29: Is "Suspicious" still a formal term in DKIM?]]

3.3.  Signature Transition Strategy

   [[anchor31: I'm not entirely clear what is meant by "algorithm"
   beyond verifier requires means to
   (1) obtain the combination public key for the purpose of key, selector, verification and signing parameters
   included in (2)
   infer useful attributes of the DKIMSignature header.  Unless I'm way off base, I
   think this section belongs either here under "Signing", or in section
   1 under "Key Generation, Storage, and Management".  Either way, we
   should be more clear about what is meant by key holder.

   In a traditional Public Key Infrastructure (PKI), the term "signature
   algorithm".]]

   Deployment functions of a new signature algorithm without a 'flag day' requires
   a transition strategy such that signers
   key distribution and verifiers can phase in
   support for key accreditation are separated.  In DKIM, these
   functions are both performed through the new algorithm independently, DNS [RFC4871] (Allman, E.,
   Callas, J., Delany, M., Libbey, M., Fenton, J., and (if necessary) phase
   out support for M. Thomas,
   "DomainKeys Identified Mail (DKIM) Signatures," May 2007.).

   In either case, the old algorithm independently.

   [Note: this section assumes that ability to infer semantics from a security policy mechanism exists.
   It digital
   signature depends on the assumption that the corresponding private
   key is subject to change.]

   [[anchor32: safe only accessible to presume ADSP?]]

   DKIM achieves these requirements through two features: First, a
   signed message may contain multiple signatures created by the same
   signer.  Second, the security policy layer allows party with a particular set of
   attributes.  In traditional PKI a Trusted Third Party (TTP) vouches
   that the signing
   algorithms in use key holder has been validated with respect to be advertised, thus preventing a downgrade
   attack.

3.3.1.  Signer transition strategy

   Let the old signing algorithm be A and the new signing algorithm be
   B. specified
   set of attributes.  The sequence range of events by which a Signer attributes that may introduce be attested in
   such a scheme is thus limited only to the new
   signing algorithm B, without disruption type of service to legacy
   verifiers, is as follows:

   1.  Signer signs with algorithm A

       A.  Signer advertises attributes that it signs with algorithm A
   2.  Signer signs messages twice, with both algorithm A a
   TTP can establish effective processes for validating.

   In DKIM, TTPs are not employed and algorithm
       B

       A.  The signer tests new signing configuration

       B.  Signer advertises the functions of key distribution
   and accreditation are combined.  Consequently there are only two
   types of inference that it signs a signer may make from a key published in a
   DKIM Key Record:

   1.  That a party with either algorithm A or
           algorithm B

   3.  Signer determines that support for Algorithm A is no longer
       necessary

   4.  Signer determines that support for algorithm A is the ability to be withdrawn

       A.  Signer removes advertisement for Algorithm A

       B.  Signer waits control DNS records within a DNS
       zone intends to claim responsibility for cached copies of earlier messages signed using
       the corresponding private signature policy key.

   2.  That use of a specific key is restricted to
           expire

       C.  Signer stops signing with Algorithm A

3.3.2.  Verifier transition strategy a particular subset
       of messages.

   The actions ability to draw any useful conclusion from verification of a
   digital signature relies on the verifier are independent of assumption that the signer's actions
   and do not need corresponding
   private key is only accessible to be performed in a party with a particular sequence.  The
   verifier may make a decision to cease accepting algorithm A without
   first deploying support for algorithm B. Similarly a verifier may be
   upgraded to support algorithm B without requiring algorithm A to be
   withdrawn.  The decisions set of
   attributes.  In the verifier must make are therefore:

   o  The verifier MAY change the degree case of confidence associated with
      any signature at any time, including determining DKIM, this means that a given
      signature algorithm provides a limited assurance of authenticity
      at a given the party that
   created the corresponding DKIM key strength.

      *  A verifier MAY evaluate signature records record in any order it
         chooses, including using the signature algorithm specific zone
   intended to choose claim responsibility for the
         order.

   o  The verifier MAY make signed message.

   Ideally we would like to draw a determination stronger conclusion, that Algorithm A does not
      offer if we
   obtain a useful level of security, or DKIM key record from the DNS zone example.com, that the cost
   legitimate holder of verifying the signature is less than DNS zone example.com claims responsibility
   for the value of doing so.

      * signed message.  In order for this case the verifier would ignore signatures created using
         algorithm A and references conclusion to algorithm A in policy records
         would be treated as if drawn it
   is necessary for the algorithm were not implemented.

   o  The verifier MAY decide to add support for additional signature
      algorithms at any time.

      *  The verifier MAY add support for algorithm B at any time.

4.  Verifying

4.1.  Verifier

   Verifiers should treat assume that the result operational security
   of the verification step as an
   input DNS zone and corresponding private key are adequate.

3.1.  Private Key Management: Deployment and Ongoing Operations

   Access to signing keys must be carefully managed to prevent use by
   unauthorized parties and to minimize the message evaluation process rather than as providing consequences should a
   final decision.  The knowledge that
   compromise occur.

   While a message DKIM signing key is authentically sent
   by a domain does not say much about the legitimacy used to sign messages on behalf of many
   mail users, the message,
   unless the characteristics signing key itself should be under direct control of
   as few key-holders as possible.  Should a key-holder leave the domain claiming responsibility
   organization, all signing keys held by that key holder should be
   withdrawn from service and if appropriate, replaced.

   If key management hardware support is available, it should be used.
   If keys are
   known.

   In particular, verifiers stored in software, sppropriate file control protections
   must be employed and any location in which the private key is stored
   in plaintext form should be excluded from regular backup processes
   and should NOT automatically assume that an
   email message that does not contain a signature, or be accessible through any form of network including
   private local area networks.  Auditing software should be used
   periodically to verify that contains the permissions on the private key files
   remain secure.

   Wherever possible a signature that does not verify, is forged.  Verifiers key should treat exist in exactly one
   location and be erased when no longer used.  Ideally a signature that fails key
   pair should be generated as close to verify the same signing point as if no signature were
   present.  NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP

   Verification possible
   and only the public key component transferred to another party.  If
   this is performed within not possible, the private key MUST be transported in an ADMD
   encrypted format that wishes to make
   assessments based upon protects the DKIM signature's domain name.  Any
   component within confidentiality of the ADMD that handles messages, whether signing
   key.  A shared directory on a local file system does not provide
   adequate security for distribution of signing keys in transit
   or being delivered, can do the verifying and subsequent assessments.
   Verification plaintext form.

   Key escrow schemes are not necessary and assessment might occur within should not be used.  In the same software
   mechanism, such as
   unlikely event of a Boundary MTA, or an MDA.  Or they signing key becomming lost, a new signature key
   pair may be
   separated, such generated as having verification performed by the Boundary MTA
   and assessment performed by the MDA.

   As with the signing process, choice of service venues for
   verification and assessment -- such easily as filtering or presentation to
   the recipient user -- depend on trade-offs recovery from a key escrow scheme.

   Responsibility for flexibility, control,
   and operational ease.  An added concern is that the linkage between
   verification and assessment entails essential trust: the assessment
   module must have security of a strong basis signing key should ultimately
   vest in a single named individual.  Where multiple parties are
   authorized to sign messages, each signer should use a different key
   to enable accountability and auditing.

   Best practices for believing that the verification
   information is correct.

4.2.  DNS Client

   The primary means management of publishing DKIM cryptographic keying material
   require keying material to be refreshed at regular intervals,
   particular where key information, initially, management is achieved through DNS TXT records.  Some DNS client software might have
   problems obtaining these records; as DNS client software improves software.  While
   this will not be a concern.

4.3.  Boundary Enforcement

   In order for an assessment module practice is highly desirable it is of considerably less
   importance than the requirement to trust maintain the information it
   receives about verification (e.g., Authentication-Results header
   fields), it must eliminate verification information originating from
   outside secrecy of the ADMD
   corresponding private key.  An operational practice in which the assessment mechanism operates.  As
   private key is stored in tamper proof hardware and changed once a
   matter of friendly practice, it
   year is equally important to make sure
   that verification information generated within the ADMD not escape
   outside of it.

   In most environments, considerably more desirable than one in which the easiest way to enforce this signature
   key is to place
   modules changed on an hourly basis but maintained in the receiving and sending Boundary MTA(s) that strip any
   existing verification information.

4.4.  Filtering software.

3.2.  Storing Public Keys: DNS Server Software

   Developers of filtering schemes designed Considerations

   In order to accept use DKIM
   authentication results as input should be aware that their
   implementations will be subject a DNS domain holder requires (1) the ability to counter-attack by email abusers.
   The efficacy
   create the necessary DKIM DNS records and (2) sufficient operational
   security controls to prevent insertion of a filtering scheme cannot therefore be determined spurious DNS records by
   reference to static test vectors alone; resistance an
   attacker.

   DNS record management is usually operated by an administrative staff
   that is different from those who operate an organization's email
   service.  In order to counter attack
   must also be considered.

   Naive learning algorithms ensure that only consider the presence or absence
   of a verified DKIM signature, without considering more information
   about the message, DNS records are vulnerable to an attack in which spammers or
   other malefactors sign all their mail, thus creating accurate, this
   imposes a large negative
   value requirement for presence of a DKIM signature in careful coordination between the hope of discouraging
   widespread use. two
   operations groups.  If heuristic algorithms the best practices for private key management
   described above are employed, they should observed, such deployment is not a one time
   event, DNS DKIM selectors will be trained on
   feature sets changed over time signing keys are
   terminated and replaced.

   At a minimum, a DNS server that sufficiently reveal handles queries for DKIM key records
   must allow the server administrators to add free-form TXT records.
   It would be better if the internal structure of the DKIM responses.  In particular records could be entered using a
   structured form, supporting the algorithm DKIM-specific fields.

   Ideally DNSSEC [] should consider be employed in a configuration that provides
   protection against record insertion attacks and zone enumeration.  In
   the
   domains purporting case that NSEC3 [RFC 5155] records are employed to claim responsibility for prevent
   insertion attack, the signature, rather
   than OPT-OUT flag must be set clear.

3.2.1.  Assignment of Selectors

   Selectors are assigned according to the existence administrative needs of the
   signing domain, such as for rolling over to a signature new key or not.

   Unless a scheme can correlate the DKIM signature with accreditation
   or reputation data, for
   delegating of the presence right to authenticate a portion of the namespace to
   a DKIM signature should be
   ignored.

5.  DKIM Deployment Considerations for Email Agents

5.1.  Email Infrastructure Agents trusted third party.  Examples include:

   jun2005.eng._domainkey.example.com

   widget.promotion._domainkey.example.com

   It is expected intended that the most common venue for a assessments of DKIM implementation
   will identities be within based on the infrastructure
   domain name, and not include the selector.  While past practice of an organization's email service, a
   signer may permit a verifier to infer additional properties of
   particular messages from the structure DKIM key selector, unannounced
   administrative changes such as a department or change of signing softeware may
   cause such heuristics to fail at any time.

3.3.  Per User Signing Key Management Issues

   While a boundary MTA.

      Outbound:   An MSA or Outbound MTA should allow signer may establish business rules, such as issue of
   individual signature keys for the automatic
         verification each end-user, DKIM makes no provision
   for communicating these to other parties.  Out of band distribution
   of the MTA configuration such that business rules is outside the MTA can
         generate an operator alert if it determines that it scope of DKIM.  Consequently
   there is (1) an
         edge MTA, and (2) configured no means by which external parties may make use of such keys
   to send email attribute messages that do not
         comply with the published DKIM sending policy.

         An outbound any greater granularity than a DNS domain.

   If per-user signing keys are assigned for internal purposes (e.g.
   authenticating messages sent to an MTA should for distribution), the
   following issues need to be aware that users may employ MUAs that
         add their own considered before using such signatures and be prepared
   as an alternative to take steps
         necessary traditional edge signing at the outbound MTA:

      External verifiers will be unable to ensure that make use of the message sent is in compliance with
         the advertised email sending policy.

         [[anchor42: MUAs being able to sign is a security
         consideration; MUAs are more prone to vulnerabilities, so an
         MUA having direct additional
      signature granularity without access to signing additional information
      passed out of band with respect to DKIM-base.

      If the number of user keys is a security concern;
         general MUA vulnerability came up during large, the IETF Security
         Directorate review efficiency of draft-kucherawy-sender-auth-header]]

      Inbound:   An inbound MTA or an MDA that does not support DKIM
         should avoid modifying messages in ways that prevent
         verification local
      caching of key records by other MTAs, or MUAs to which the message verifiers will be lower.

      A large number of end users may be
         forwarded.

         An inbound MTA or less likely to be able to
      manage private key data securely on their personal computer than
      an MDA may incorporate administrator running an indication edge MTA.

3.4.  Third Party Signer Key Management and Selector Administration

   A DKIM key record only asserts that the holder of the
         verification results into corresponding
   domain name makes a claim of responsibility for messages signed under
   the message, corresponding key.  In some applications, such as using an
         Authentication-Results header field.
         [I-D.kucherawy-sender-auth-header]

      Intermediaries:   An email intermediary bulk mail
   delivery it is both an inbound and
         outbound MTA.  Each of the requirements outlined in the
         sections relating desirable to MTAs apply.  If delegate the intermediary modifies
         a message in ability to make a way that breaks the signature, claim of
   responsibility to another party.  In this case the intermediary

         +  should deploy abuse filtering measures on trust relationship
   is established between the inbound mail, domain holder and

         +  MAY remove all signatures that will be broken

         In addition the intermediary MAY:

         +  Verify verifier but the message
   private signature prior to modification.

         +  Incorporate an indication of the verification results into
            the message, such as using an Authentication-Results header
            field.  [I-D.kucherawy-sender-auth-header]
         +  Sign the modified message including the verification results
            (e.g., the Authentication-Results header field).

5.2.  Mail User Agent

   DKIM key is designed to support deployment held by a third party.

   Signature keys used by a third party signer should be kept entirely
   separate from those used by the domain holder and use in email components other than an MUA.  However an MUA MAY also implement DKIM features
   directly.

      Outbound:   If an MUA is configured to send email directly, rather
         than relay it through an outbound MSA, third party
   signers.  As with any other private key, the MUA signature key pair
   should be
         considered as if it were an outbound MTA for generated by the purposes third party signer and the public
   component of
         DKIM.  An MUA MAY support signing even if mail is the key transmitted to be relayed
         through an outbound MSA.  In this case the signature applied by domain holder rather than
   have the MUA may be in addition domain holder generate the key pair and transmit the private
   component to any MSA signature.

      Inbound:   An MUA MAY rely on a report of the third party signer.

   Domain holders should adopt a DKIM signature
         verification that took place at some point in least privilege approach and grant
   third party signers the inbound MTA
         path (e.g., an Authentication-Results header field), or an MUA
         MAY minimum access necessary to perform DKIM signature verification directly.  A verifying
         MUA should allow for the case where mail is modified in
   desired function.  Limiting the
         inbound MTA path.

   It is common for components of an ADMD's email infrastructure to do
   violence access granted to a message, such as Third Party Signers
   serves to render a DKIM signature invalid.
   Hence, users protect the interests of MUAs that support DKIM signing and/or verifying need
   a basis for knowing that both parties.  The domain holder
   minimizes their associated email infrastructure will
   not break a signature.

6.  Migrating from DomainKeys

6.1.  Signing

      DNS Records:   DKIM is upwardly compatible with existing
         DomainKeys (DK) [RFC4870] DNS records, so that security risk and the Trusted Third Party Signer
   avoids unnecessary liability.

   In the most restrictive case a DKIM module
         does not automatically require additional DNS administration.
         However DKIM has enhanced domain holder maintains full control
   over the DomainKeys DNS creation of key record format
         by adding several additional optional parameters.

         [[anchor46: Explicit "g=" has different meaning in DomainKeys records and DKIM, employ appropriate key record
   restrictions to enforce restrictions on the messages for which has been an interoperability issue in the past
         (DomainKeys interprets that as "match any" while DKIM
         interprets it as "match none")]]
      Boundary MTA:   The principal use of DomainKeys is at Boundary
         MTAs.  Because no operational transition is ever instantaneous,
         it
   third party signer is not adviseable for existing DomainKeys signers to switch able to DKIM without continuing sign.  If such restrictions are
   impractical, the domain holder should delegate a DNS subzone for
   publishing key records to perform DomainKeys signing.  A
         signer the third party signer.  The domain holder
   should add not allow a DKIM signature third party signer unrestricted access to their
   DNS service for the purpose of publishing key records.

3.5.  Key Pair / Selector Lifecycle Management

   Deployments should establish, document and observe processes for
   managing the entire lifecycle of a message public key pair.

3.5.1.  Example Key Deployment Process

   When it is determined that also has a
         DomainKeys signature, until such time as DomainKeys receive-
         side support new key pair is sufficiently reduced.  With respect to required:

   1.  A Key Pair is generated by the signing
         policies, a reasonable, initial approach device

   2.  A proposed key selector record is generated and transmitted to use DKIM
         signatures in
       the same way as DomainKeys signatures are already
         being used.

6.2.  Verifying DNS Client: administration infrasrtructure.

   3.  The DNS queries for administration infrastructure verifies the authenticity
       of the DKIM key selector registration request.  If accepted

       1.  A key selector is assigned.

       2.  The corresponding key record use published in the same
         Domain Name naming conventions as were used DNS.

       3.  Wait for DomainKeys, and
         the same basic record format.  No changes to the DNS client
         should be required.

      Verifying module:   See updates to propagate (if necessary).

       4.  Report assigned key selector to signing device.

   4.  Signer verifies correct registration of the section on Signing above.

7.  Example Uses

   A DKIM signature tells key record.

   5.  Signer begins generating signatures using the signature verifier new key pair.

   6.  Signer terminates any private keys that the owner are no longer required
       due to issue of a
   particular domain name accepts responsibility for the message.
   Combining this information with information replacement.

3.5.2.  Example Key Termination Process

   When it is determined that allows a private signature key is no longer
   required:

   1.  Signer stops using the history private key for signature operations.

   2.  Signer deletes all records of the domain name owner to be assessed may allow processing private key, including in-
       memory copies at the
   message, based on signing device.

   3.  Signer notifies the probability DNS administration infrasrtructure that the message is likely to be
   trustworthy, or not, without the need for heuristic content analysis.

7.1.  Protection of Internal Mail

   One identity
       signing key is particularly amenable to easy withdrawn from service and accurate
   assessment: The organization's own identity.  Members of an
   organization tend to trust messages that purport to the corresponding
       key records may be withdrawn from within
   that organization.  However Internet Mail does not provide service at a
   straightforward means specified future
       date.

   4.  The DNS administration infrastructure verifies the authenticity
       of determining whether such mail is, in fact,
   from within the organization.  DKIM can be used to remedy this
   exposure. key selector termination request.  If the organization signs all of its mail, then its
   boundary MTAs can look accepted

       1.  The key selector is scheduled for mail purporting to be from the
   organization but does not contain deletion at a verifiable signature.  Such mail
   can be presumed to be spurious.

   WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN
   SIGNATURE????  Need to include some of the breakage examples from
   ADSP spec.

7.2.  Recipient-based Assessments

   Recipients of large volumes of email can internally generate
   reputation data future time
           determined by site policy.

       2.  Wait for email senders.  Recipients of smaller volumes of
   messages are likely to need deletion time to acquire reputation data from a third
   party.  In either case the use of reputation data arrive

       3.  The key selector is intrinsically
   limited to email senders deleted

4.  Signing

   Creating messages that have established a prior history of
   sending messages.

   In fact, an one or more DKIM signatures, requires
   support in only two outbound email receiving service may be in a position to establish
   bilateral agreements components:

   o  A DNS Administrative interface that can create and maintain the
      relevant DNS names -- including names with particular senders, such as business
   partners or underscores -- and
      resource records (RR).

   o  A trusted bulk sending services.  Although it module, called the Signing Module, which is not
   practical for each recipient within the
      organization's outbound email handling service and which creates
      and adds the DKIM-Signature: header field(s) to accredit every sender, the definition
   of core networks of explicit trust can message.

   If the module creates more than one signature, there needs to be quite useful.

7.2.1.  Third-party Reputation and Accreditation Services

   For scaling efficiency, the
   appropriate means of telling it is appealing which one(s) to use Trusted Third Party
   reputation and accreditation services, use.  If a large
   number of names is used for signing, it will help to allow an email sender have the
   administrative tool support a batch processing mode.

4.1.  DNS Records

   A receiver attempting to
   obtain verify a single assessment DKIM signature obtains the public
   key that is then recognized by every email
   recipient that recognizes associated with the Trusted Third Party.

7.3.  DKIM Support signature for that message.  The
   DKIM-Signature: header in the Client

   The DKIM specification is expected to be used primarily between
   Boundary MTAs, or other infrastructure components of message contains the originating d= tag with the
   basic domain name doing the signing and receiving ADMDs.  However there is nothing in DKIM that is
   specific to those venues.  In particular, it should be possible serving as output to
   support signing the
   Identity Assessor, and verifying in MUAs.

   DKIM requires that all verifiers treat messages the s= tag with signatures that
   do not verify as if they are unsigned.  If verification in the client
   is to be acceptable to users, it is also essential selector that successful
   verification of a signature not result in a less than satisfactory
   user experience compared is added to leaving
   the message unsigned.

7.4.  Per user signatures

   Although DKIM's use of domain names is optimized name, for a scope of
   organization-level signing, it is possible finding the specific public key.  Hence, the relevant
   <selector>._domainkey.<domain-name> DNS record needs to administer sub-domains
   and/or selectors in contain a way
   DKIM-related RR that supports per-user signing.

   NOTE:   As stated earlier, it is important to distinguish between provides the
      use of selectors for differential administration public key information.

   The administrator of keys, versus the use of sub-domains for differential reputations.  It's also
      probably a good idea to note that receivers are unlikely to pay
      attention to reputation at a user granularity even if it's
      technically feasible to publish it.

   As a constraint on an authorized DKIM signing agent, its associated
   key record can specify restrictions on zone containing the email addresses permitted
   to be signed with that relevant domain and key.  A typical intent of name
   adds this
   feature information.  Initial DKIM DNS information is contained
   within TXT RRs.  DNS administrative software varies considerably in
   its abilities to allow a company support DKIM names, such as with underscores, and to delegate the
   add new types of DNS information.

4.2.  Signing Module

   The module doing signing authority for
   bulk marketing communications without can be placed anywhere within an
   organization's trusted Administrative Management Domain (ADMD);
   obvious choices include department-level posting agents, as well as
   outbound boundary MTAs to the risk of effectively
   delegating open Internet.  However any other
   module, including the authority to sign messages purporting author's MUA, is potentially acceptable, as
   long as the signature survives any remaining handling within the
   ADMD.  Hence the choice among the modules depends upon software
   development, administrative overhead, security exposures and transit
   handling tradeoffs.  One perspective that helps to come resolve this
   choice is the difference between the increased flexibility, from
   placement at (or close to) the
   domain-owning organization's CEO.

   NOTE:   Any scheme MUA, versus the streamlined
   administration and operation, that involves maintenance of a significant number
      of public keys is likely to require infrastructure enhancements,
      to support that management.  For example, a system more easily obtained by
   implementing the mechanism "deeper" into the organization's email
   infrastructure, such as at its boundary MTA.

   Note the discussion in which Section 2.2, concerning use of the
      end user is required to generate a public i= tag.

   The signing module uses the appropriate private key pair and transmit it to create one or
   more signatures.  The means by which the DNS administrator out of band signing module obtains the
   private key(s) is not likely to meet
      acceptance criteria specified by DKIM.  Given that DKIM is intended
   for either usability or security.

8.  Security Considerations

   TBD

9.  IANA Considerations

   TBD

10.  Acknowledgements

   TBD

11.  Informative References

   [I-D.ietf-openpgp-rfc2440bis]
              Callas, J., "OpenPGP Message Format",
              draft-ietf-openpgp-rfc2440bis-22 (work in progress),
              April 2007.

   [I-D.kucherawy-sender-auth-header]
              Kucherawy, M., "Message Header Field use during email transit, rather than for Indicating
              Message Authentication Status",
              draft-kucherawy-sender-auth-header-17 (work in progress),
              October 2008.

   [RFC0989]  Linn, J. long-term storage, it
   is expected that keys will be changed regularly.  For administrative
   convenience, key information should not be hard-coded into software.

4.3.  Signing Policies and IAB Privacy Task Force, "Privacy enhancement
              for Internet electronic mail: Part I: Message encipherment Practices

   Every organization (ADMD) will have its own policies and authentication procedures", RFC 989, February 1987.

   [RFC1034]  Mockapetris, P., "Domain names - concepts practices
   for deciding when to sign messages (message stream) and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1848]  Crocker, S., Galvin, J., Murphy, S., with what
   domain name, selector and N. Freed, "MIME
              Object Security Services", RFC 1848, October 1995.

   [RFC1991]  Atkins, D., Stallings, W., key.  Examples of particular message
   streams include all mail sent from the ADMD, versus mail from
   particular types of user accounts, versus mail having particular
   types of content.  Given this variability, and P. Zimmermann, "PGP Message
              Exchange Formats", RFC 1991, August 1996.

   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., the likelihood that
   signing practices will change over time, it will be useful to have
   these decisions represented through run-time configuration
   information, rather than being hard-coded into the signing software.

   As noted in Section 2.3, the choice of signing name granularity
   requires balancing administrative convenience and R. Thayer,
              "OpenPGP Message Format", RFC 2440, November 1998.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3156]  Elkins, M., Del Torto, D., Levien, R., utility for
   recipients.  Too much granularity is higher administrative overhead
   and T. Roessler,
              "MIME Security with OpenPGP", RFC 3156, August 2001.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
              August 2001.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC4686]  Fenton, J., "Analysis well might attempt to impose more differential analysis on the
   recipient than they wish to support.  In such cases, they are likely
   to use only a super-name -- right-hand substring -- of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC4870]  Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised the signing
   name.  When this occurs, the signer will not know what portion is
   being used; this then moves DKIM back to the non-deterministic world
   of heuristics, rather than the mechanistic world of signer/recipient
   collaboration that DKIM seeks.

5.  Verifying

   To be added.

6.  Taxonomy of Signatures

   A DKIM signature tells the signature verifier that the owner of a
   particular domain name accepts some responsibility for the message.
   It does not, in and of itself, provide any information about the
   trustworthiness or behavior of that identity.  What it does provide
   is a verified identity to which such behavioral information can be
   associated, so that those who collect and use such information can be
   assured that it truly pertains to the identity in question.

   This section lays out a taxonomy of some of the different identities,
   or combinations of identities, that might usefully be represented by
   a DKIM signature.

6.1.  Single Domain Signature

   Perhaps the simplest case is when an organization signs its own
   outbound email using its own domain in the d= tag of the signature.
   For example, Company A would sign the outbound mail from its
   employees with d=companyA.example.

   In the most straightforward configuration, the addresses in the DNS (DomainKeys)", RFC 4870,
              May 2007.

   [RFC4871]  Allman, E., Callas, J., Delany, M.,
   5322 From would also be in the companyA.example domain, but that
   direct correlation is not required.

   A special case of the Single Domain Signature is an Author Signature
   as defined by the Author Domain Signing Practices specification.
   Author signatures are signatures from an authors organization that
   have an i= value that matches the From: address of the message.
   Under the ADSP specification, an i= value matches a RFC 5322 From
   address when the domains of the two match exactly, and if the i=
   value contains a local part it also matches the local part of the
   From: address exactly.

   Although an author signature might in some cases be proof against
   domain name spoofing the RFC 5322 From address, it is important to
   note that the DKIM and ADSP validation apply only to the exact
   address string and not to look-alike addresses nor to the human-
   friendly "display-name" or names and addresses used within the body
   of the message.  That is, it protects only against the misuse of a
   precise address string within the RFC5322 From field and nothing
   else.  For example, a message from bob@domain.example with a valid
   signature where i=d0main.example would fail an ADSP check because the
   signature domain, however similar, is distinct; however a message
   from bob@d0main.example with a valid signature where i=d0main.example
   would pass an ADSP check, even though to a human it might be obvious
   that d0main.example is likely a malicious attempt to spoof the domain
   domain.example.  This example highlights that ADSP, like DKIM, is
   only able to validate a signing identifier: it still requires some
   external process to attach a meaningful reputation to that
   identifier.

6.2.  Parent Domain Signature

   Another approach that might be taken by an organization with multiple
   active subdomains is to apply the same (single) signature to mail
   from all subdomains.  In this case, the signature chosen would
   usually be the signature of a parent domain common to all subdomains.
   For example, mail from marketing.domain.example,
   sales.domain.example, and engineering.domain.example might all use a
   signature with d=domain.example.

   This approach has the virtue of simplicity, but it is important to
   consider the implications of such a choice.  As discussed in
   Section 2.3, if the type of mail sent from the different subdomains
   is significantly different or if there is reason to believe that the
   reputation of the subdomains would differ, then it may be a good idea
   to acknowledge this and provide distinct signatures for each of the
   subdomains (d=marketing.domain.example, sales.domain.example, etc.).
   However, if the mail and reputations are likely to be similar, then
   the simpler approach of using a single common parent domain in the
   signature may work well.

   Another approach to distinguishing the streams using a single DKIM
   key would be to leverage the i= tag in the DKIM signature to
   differentiate the mail streams.  For example, marketing email would
   be signed with i=marketing.domain.example and d=domain.example.

   It's important to remember, however, that under core DKIM semantics
   the i= identifer is opaque to receivers.  That means that it will
   only be an effective differentiator if there is an out of band
   agreement about the i= semantics (e.g., the semantics specified in
   ADSP).

6.3.  Third Party Signature

   A signature whose domain does not match the domain of the RFC 5322
   From address is sometimes referred to as a third party signature.  In
   certain cases even the parent domain signature described above would
   be considered a third party signature because it would not be an
   exact match for the domain in the From: address.

   Although there is often heated debate about the value of third-party
   signatures, it is important to note that the DKIM specification
   attaches no particular significance to the identity in a DKIM
   signature.  The identity specified within the signature is the
   identity that is taking responsibility for the message, and it is
   only the interpretation of a given receiver that gives one identity
   more or less significance than another.  In particular, most
   independent reputation services assign trust based on the specific
   identifier string, not its "role": in general they make no
   distinction between, for example, an author signature and a third
   party signature.

   For some, a signature unrelated to the author (identity in the RFC
   5322 From address) is less valuable because there is an assumption
   that the presence of an author signature guarantees that the use of
   the address in the From: header is authorized.

   For others, that relevance is tied strictly to the recorded
   behavioral data assigned to the identity in question, i.e. its trust
   assessment or reputation.  The reasoning here is that an identity
   with a good reputation is unlikely to maintain that good reputation
   if it is in the habit of vouching for messages that are unwanted or
   abusive; in fact, doing so will rapidly degrade its reputation so
   that future messages will no longer benefit from it.  It is therefore
   low risk to facilitate the delivery of messages that contain a valid
   signature of a domain with a strong positive reputation, independent
   of whether or not that domain is associated with the address in the
   RFC5322 From header field of the message.

   Third party signatures encompass a wide range of identities.  Some of
   the more common are:

   Service Provider:  In cases where email is outsourced to an Email
      Service Provider (ESP), Internet Service Provider (ISP), or other
      type of service provider, that service provider may choose to DKIM
      sign outbound mail with either its own identifier -- relying on
      its own, aggregate reptutation -- or with a subdomain of the
      provider that is unique to the message author but still part of
      the provider's aggregate reputation.  Such service providers may
      also encompass delegated business functions such as benefit
      management, although these will more often be treated as trusted
      third party senders (see below).

   Parent Domain.  As discussed above, organizations choosing to sign
      for mail originating from subdomains with a parent domain
      signature may also considered to be using 3rd party signatures in
      some configurations, depending on whether or not the "t=s" tag is
      used to constrain the parent signature to apply to only its own
      specific domain.  The default is that a parent domain signature is
      considered valid for its subdomains.

   Reputation Provider:  Another possible category of third party
      signature would be the identity of a 3rd party reputation
      provider.  Such a signature would indicate to receivers that the
      message was being vouched for by that 3rd party.

6.4.  Using Trusted 3rd Party Senders

   For most of the cases described so far, there has been an assumption
   that the identity doing the signing was responsible for creating and
   maintaining their own DKIM signing infrastructure, including their
   own keys, and signing with their own identity.

   A different model arises when an organization uses a trusted third
   party sender for certain key business functions, but still wants that
   email to benefit from the organization's own identity and reputation:
   in other words, the mail would come out of the trusted 3rd party's
   mail servers, but the signature applied would be that of the
   controlling organization.

   This can be done by having the 3rd party generate a key pair that is
   designated uniquely for use by that trusted 3rd party and publishing
   the public key in the controlling organization's DNS domain, thus
   enabling the third party to sign mail using the signature of the
   controlling organization.  For example, if Company A outsources its
   employee benefits to a 3rd party, they can use a special keypair that
   enables the benefits company to sign mail as "companyA.example".
   Because the keypair is unique to that trusted 3rd party, it is easy
   for Company A to revoke the authorization if necessary by simply
   removing the public key from the companyA.example DNS.

   In this scenario, it is usually a good idea to limit the specific
   identities that can be used by even trusted third parties.  The DKIM
   g= tag enables a key record to specify one particular From: address
   local part that must be specified in the i= tag of the signature: for
   example, "g=benefits" would require a signature header tag of
   "i=benefits@companyA.example".  It is important to note that although
   this distinction will be clear to the verifier it may be invisible to
   the recipient: there is no constraint within the DKIM verification
   process that constrains that specific i= value to correspond to any
   of the other message headers.

   A more reliable way of distinguishing the third part mail stream
   would be to create a dedicated subdomain (e.g.
   benefits.companyA.example) and publish the public key there; the
   signature would then use d=benefits.companyA.example.

6.4.1.  DNS Delegation

   Another possbility for configuring trusted third party access is to
   have Company A use DNS delegation and have the designated subdomain
   managed directly by the trusted third party.  In this case, Company A
   would create a subdomain benefits.companya.example, and delegate the
   DNS management of that subdomain to the benefits company so it could
   maintain its own key records.  Should revocation become necessary,
   Company A could simply remove the DNS delegation record.

6.5.  Multiple Signatures

   A simple configuration for DKIM-signed mail is to have a single
   signature on a given message.  This works well for domains that
   manage and send all of their own email from a single source, or for
   cases where multiple email streams exist but each has its own unique
   key pair.  It also represents the case in which only one of the
   participants in an email sequence is able to sign, no matter whether
   they represent the author or one of the operators.

   The examples thus far have considered the implications of using
   different identities in DKIM signatures, but have used only one such
   identity for any given message.  In some cases, it may make sense to
   have more than one identity claiming responsiblity for the same
   message.

   One important caveat to the use of multiple signatures is that there
   is currently no clear consensus amoung receivers on how they plan to
   handle them.  The opinions range from ignoring all but one signature
   (and the specification of which of them is verified differs from
   receiver to receiver), to verifying all signatures present and
   applying a weighted blend of the trust assessments for those
   identifiers, to verifying all signatures present and simply using the
   identfier that represents the most positive trust assessment.  It is
   likely that the industry will evolve to accept multiple signatures
   using either option two or three, but it may take some time before
   that approach becomes pervasive.

   There are a number of situations where applying more than one DKIM
   signature to the same message might make sense.  A few examples are:

   Companies with multiple subdomain identities:  A company that has
      multiple subdomain sending distinct categories of mail might
      choose to sign with distinct subdomain identities to enable each
      subdomain to manage its own identity.  However, it might also want
      to provide a common identity that cuts across all of the distinct
      subdomains.  For example, Company A may sign mail for its sales
      department with a signature where d=marketing.companya.example,
      and a second signature where d=companya.example

   Service Providers:  Service providers may, as described above, choose
      to sign outbound messages with either their own identity or with
      an identity unique to each of their clients (possibly delegated).
      However, they may also do both: sign each outbound message with
      their own identity as well as the identity of each individual
      client.  For example, ESP A might sign mail for their client
      Company B with their service provider signature d=espa.example,
      and a second client-specific signature where d= either
      companyb.example, or companyb.espa.example.  The existence of the
      service provider signature could, for example, help cover a new
      client while they establish their own reputation, or help a very
      small volume client who might never reach a volume threshold
      sufficient to establish an individual reputation.

   Forwarders  Forwarded mail poses a number of challenges to email
      authentication.  DKIM is relatively robust in the presence of
      forwarders as long as the signature is designed to avoid message
      parts that are likely to be modified, although some forwarders do
      make modifications that can invalidate a DKIM signature.

      However, some forwarders such as mailing lists or forward article
      to a friend services, might choose to add their own signature to
      outbound messages to vouch for it having legitimately originated
      from the designated service.  In this case, the signature would be
      added even in the presence of a pre-existing signature, and both
      signatures would be relevant to the verifier.

      Any forwarder that modifies messages in ways that will break pre-
      existing DKIM signatures should always sign its forwarded
      messages.

   Reputation Providers:  Although third party reputation providers
      today use a variety of protocols to communicate their information
      to receivers, it is possible that they, or other organizations
      willing to put their "seal of approval" on an email stream might
      choose to use a DKIM signature to do it.  In nearly all cases,
      this "reputation" signature would be in addition to the author or
      originator signature.

7.  Example Usage Scenarios

   Signatures are created by different types of email actors, based on
   different criteria, such as where the actor operates in the sequence
   from author to recipient, whether they want different messages to be
   evaluated under the same reputation or different, and so on.  This
   section provides some examples of usage scenarios for DKIM
   deployments; the selection is not intended to be exhaustive, but to
   illustrate a set of key deployment considerations.

7.1.  Author's Organization - Simple

   The simplest DKIM configuration is to have all mail from a given
   organization (Company A) be signed with the same d= value (e.g.
   d=companya.example).  If there is a desire to associate a user
   identity or some other related information, the i= value can become
   uniqueID@companya.example, or uniqueID.companya.example.

   In this scenario, Company A need only generate a single signing key
   and publish it under their top level domain (companya.example); the
   signing module would then tailor the i= value as needed at signing
   time.

7.2.  Author's Organization - Differentiated Types of Mail

   A slight variation of the one signature case is where Company A signs
   all of its mail, but it wants to differentiate different categories
   of its outbound mail by using different identifiers.  For example, it
   might choose to distinguish marketing mail, billing or transactional
   mail, and individual corporate email into marketing.companya.example,
   billing.companya.example, and companya.example, where each category
   is assigned a unique subdomain and unique signing keys.

7.3.  Author Signature

   As discussed in Section 6.1, author signatures are a special case of
   signatures from an authors organization where at least one signature
   on the message has an i= value that matches the From: address of the
   message.

   Signers wishing to publish an ADSP record describing their signing
   practices will want to include an author signature on their outbound
   mail to avoid ADSP verification failures.  For example, if the
   address in the RFC 5322 From is bob@company.example, the d= value of
   the author signature would be company.example, and the i= value would
   be either company.example or bob@company.example.

7.4.  Author Domain Signing Practices

   To be added.

7.5.  Delegated Signing

   An organization may choose to outsource certain key services to third
   party companies.  For example, Company A might outsource its benefits
   management, or Organization B might outsource its marketing email.

   If Company A wants to ensure that all of the mail sent on its behalf
   through the benefits providers email servers shares the Company A
   reputation, as discussed in Section 6.4 it can either publish keys
   designated for the use of the benefits provider under
   companyA.example (preferably under a designated subdomain of
   companyA.example), or they can delegate a subdomain (e.g.
   benefits.companyA.example) to the provider and enable the provider to
   generate the keys and manage the DNS for the designated subdomain.

   In both of these cases, mail would be physically going out of the
   benefit provider's mail servers with a signature of e.g.
   d=benefits.companya.example.  Note that the From: address is not
   constrained: it could either be affiliated with the benefits company
   (e.g. benefits-admin@benefitprovider.example, or
   benefits-provider@benefits.companya.example).

   Note that in both of the above scenarios, security concerns dictate
   that the keys be generated by the organization that plans to do the
   signing so that there is no need to transfer the private key.  In
   other words, the benefits provider would generate keys for both of
   the above scenarios.

7.6.  Independent Third Party Service Providers

   Another way to manage the service provider configuration would be to
   have the service provider sign the outgoing mail on behalf of its
   client Company A with its own (provider) identifier.  For example, an
   Email Service Provider (ESP A) might want to share its own mailing
   reputation with its clients, and may sign all outgoing mail from its
   clients with its own d= domain (e.g. d=espa.example).

   Should the ESP want to distinguish among its clients, it has two
   options:

   Share the d= domain  and use the i= value to distinguish among the
      clients: e.g. a signature on behalf of client A would have
      d=espa.example and i=clienta.espa.example (or
      i=clienta@espa.example)

   Extend the d= domain  so there is a unique value (and subdomain) for
      each client: e.g. a signature on behalf of client A would have
      d=clienta.espa.example.

   Note that this scenario and the delegation scenario are not mutually
   exclusive: in some cases, it may be desirable to sign the same
   message with both the ESP and the ESP client identities.

7.7.  Mail Streams Based on Behavioral Assessment

   An ISP (ISP A) might want to assign signatures to outbound mail from
   their users according to the users past sending behavior
   (reputation).  Since the semantics of behavioral assessments arent
   allowed as i= values, ISP A (ispa.example) would have to configure
   subdomains corresponding the assessment categories (e.g.
   good.ispa.example, neutral.ispa.example, bad.ispa.example), and use
   these domains as the d= value of the signature.

   The signing module can also optionally set the i= value to have a
   unique user id (distinct from the users email address local part),
   for example user3456@neutral.domain.example.  Using a userid that is
   distinct from a given email alias is useful in environments where a
   single user might register multiple email aliases.

   Note that in this case the i= values are only partially stable.  They
   are stable in the sense that a given i= value will always represent
   the same identity, but they are unstable in the sense that a given
   user can migrate among the assessment subdomains depending on their
   sending behavior (i.e., the same user might have multiple i= values
   over the lifetime of their account).

   In this scenario, ISP A would have to generate as many keys as there
   are assessment subdomains (d= values), so that each assessment
   subdomain had its own key.  The signing module would then choose its
   signing key based on the assessment of the user whose mail was being
   signed, and if desired include the user id in the i= tag of the
   signature.

7.8.  Agent or Mediator Signatures

   Another scenario is that of an agent, usually a re-mailer of some
   kind, that signs on behalf of the service or organization that it
   represents.  Some examples of agents might be a mailing list manager,
   or the "forward article to a friend" service that many online
   publications offer.  In most of these cases, the signature is
   asserting that the message originated with, or was relayed by, the
   service asserting responsibility.

8.  Usage Considerations

8.1.  Non-standard Submission and Delivery Scenarios

   The robustness of DKIM's verification mechanism is based on the fact
   that only authorized signing modules have access to the designated
   private key.  This has the side effect that email submission and
   delivery scenarios that originate or relay messages from outside the
   domain of the authorized signing module will not have access to that
   protected private key, and thus will be unable to attach the expected
   domain signature to those messages.  Such scenarios include mailing
   lists, courtesy forwarders, MTAs at hotels, hotspot networks used by
   travelling users, and other paths that could add or modify headers,
   or modify the message body.

   For example, assume Joe works for Company A and has an email address
   joe@companya.example.  Joe also has a GMail account joe@gmail.com,
   and he uses GMails multiple address feature to attach his work email
   joe@companya.example to his GMail account.  When Joe sends email from
   his GMail account and uses joe@companya.example as his designated
   From: address, that email cannot have a signature with
   d=companya.example because the GMail servers have no access to
   Company A's private key.  In GMail's case it will have a GMail
   signature, but for some other mail clients offering the same multiple
   address feature there may be no signature at all on the message.

   Another example might be the use of a forward article to a friend
   service.  Most instances of these services today allow someone to
   send an article with their email address in the RFC 5322 From to
   their designated recipient.  If Joe used either of his two addresses
   (joe@companya.example or joe@gmail.com), the forwarder would be
   equally unable to sign with a corresponding domain .  As in the mail
   client case, the forwarder may either sign as its own domain, or may
   put no signature on the message.

   A third example is the use of privately configured forwarding.
   Assume that Joe has another account at Yahoo, joe@yahoo.com, but he'd
   prefer to read his Yahoo mail from his GMail account.  He sets up his
   Yahoo account to forward all incoming mail to joe@gmail.com.  Assume
   alice@companyb.example sends joe@yahoo.com an email.  Depending on
   how companyb.example configured its signature, and depending on
   whether or not Yahoo modifies messages that it forwards, it is
   possible that when Alice's message is received in Joe's gmail account
   the original signature fails verification.

8.2.  Protection of Internal Mail

   One identity is particularly amenable to easy and accurate
   assessment: the organization's own identity.  Members of an
   organization tend to trust messages that purport to be from within
   that organization.  However Internet Mail does not provide a
   straightforward means of determining whether such mail is, in fact,
   from within the organization.  DKIM can be used to remedy this
   exposure.  If the organization signs all of its mail, then its
   boundary MTAs can look for mail purporting to be from the
   organization that does not contain a verifiable signature.

   Such mail can in most cases be presumed to be spurious.  However,
   domain managers are advised to consider the ways that mail processing
   can modify messages in ways that will invalidate an existing DKIM
   signature: mailing lists, courtesy forwarders, and other paths that
   could add or modify headers or modify the message body (e.g.  MTAs at
   hotels, hotspot networks used by travelling users, and other
   scenarios described in the previous section).  Such breakage is
   particularly relevant in the presence of Author Domain Signing
   Practices.

8.3.  Signature Granularity

   Although DKIM's use of domain names is optimized for a scope of
   organization-level signing, it is possible to administer sub-domains
   or otherwise adjust signatures in a way that supports per-user
   identification.  This user level granularity can be specified in two
   ways: either by sharing the signing identity and specifying an
   extension to the i= value that has a per-user granularity, or by
   creating and signing with unique per-user keys.

   A subdomain or local part in the i= tag should be treated as an
   opaque identifier and thus need not correspond directly to a DNS sub
   domain or to a specific user address

   The primary way to sign with per-user keys require that each user
   have a distinct DNS (sub)domain, where each distinct d= value has a
   key published (it is possible, although not recommended, to publish
   the same key in more than one distinct domain).

   It is technically possible, to publish per-user keys within a single
   domain or subdomain by utilizing different selector values.  This is
   not recommended and is unlikely to be treated uniquely by Identity
   Assessors: the primary purpose of selectors is to facilitate key
   management, and the DKIM specification recommends against using them
   in determining or assessing identies.

   In most cases, it would be impractical to sign email on a per-user
   granularity.  Such an approach would be

   likely to be ignored:   In most cases today, if receivers are
      verifying DKIM signatures they are in general taking the simplest
      possible approach.  In many cases maintaining reputation
      information at a per user granularity is not interesting to them,
      in large part because the per user volume is too small to be
      useful or interesting.  So even if senders take on the complexity
      necessary to support per user signatures, receivers are unlikely
      to retain anything more than the base domain reputation.

   difficult to manage:   Any scheme that involves maintenance of a
      significant number of public keys may require infrastructure
      enhancements or extensive administrative expertise.  For domains
      of any size, maintaining a valid per-user keypair, knowing when
      keys need to be revoked or added due to user attrition or
      onboarding, and the overhead of having the signing engine
      constantly swapping keys can create significant and often
      unnecessary managment complexity.  It is also important to note
      that there is no way within the scope of the DKIM specification
      for a receiver to infer that a sender intends a per-user
      granularity.

   What may make sense, however, is to use the infrastructure that
   enables finer granularity in signatures to identify segments smaller
   than a domain but much larger than a per-user segmentation.  For
   example, a university might want to segment student, staff, and
   faculty mail into three distinct streams with differing reputations.
   This can be done by creating seperate sub-domains for the desired
   segments, and either specifying the subdomains in the i= tag of the
   DKIM Signature or by adding subdomains to the d= tag and assigning
   and signing with different keys for each subdomain.

   For those who choose to represent user level granularity in
   signatures, the performance and management considerations above
   suggest that it would be more effective to do it by specifying a
   local part or subdomain extension in the i= tag rather than by
   extending the d= domain and publishing individual keys.

8.4.  Email Infrastructure Agents

   It is expected that the most common venue for a DKIM implementation
   will be within the infrastructure of an organization's email service,
   such as a department or a boundary MTA.  What follows are some
   general recommendations for the Email Infrastructure.

      Outbound:   An MSA or an Outbound MTA used for mail submission
         SHOULD ensure that the message sent is in compliance with the
         advertised email sending policy.  It SHOULD also be able to
         generate an operator alert if it determines that the email
         messages do not comply with the published DKIM sending policy.

         An MSA SHOULD be aware that some MUAs may add their own
         signatures.  If the MSA needs to perform operations on a
         message to make it comply with its email sending policy, if at
         all possible, it SHOULD do so in a way that would not break
         those signatures.

         [[anchor38: MSK: MUAs being able to sign is a security
         consideration; MUAs are more prone to vulnerabilities, so an
         MUA having direct access to signing keys is a security concern;
         general MUA vulnerability came up during the IETF Security
         Directorate review of draft-kucherawy-sender-auth-header]]

      Inbound:   When an organization deploys DKIM, it needs to make
         sure that it email infrastructure components that do not have
         primary roles in DKIM handling do not modify message in ways
         that prevent subsequent verification.

         An inbound MTA or an MDA may incorporate an indication of the
         verification results into the message, such as using an
         Authentication-Results header field.
         [I-D.kucherawy-sender-auth-header]

      Intermediaries:   An email intermediary is both an inbound and
         outbound MTA.  Each of the requirements outlined in the
         sections relating to MTAs apply.  If the intermediary modifies
         a message in a way that breaks the signature, the intermediary

         +  SHOULD deploy abuse filtering measures on the inbound mail,
            and

         +  MAY remove all signatures that will be broken

         In addition the intermediary MAY:

         +  Verify the message signature prior to modification.

         +  Incorporate an indication of the verification results into
            the message, such as using an Authentication-Results header
            field.  [I-D.kucherawy-sender-auth-header]

         +  Sign the modified message including the verification results
            (e.g., the Authentication-Results header field).

8.5.  Mail User Agent

   The DKIM specification is expected to be used primarily between
   Boundary MTAs, or other infrastructure components of the originating
   and receiving ADMDs.  However there is nothing in DKIM that is
   specific to those venues.  In particular, MUAs MAY also support DKIM
   signing and verifying directly.

      Outbound:   An MUA MAY support signing even if mail is to be
         relayed through an outbound MSA.  In this case the signature
         applied by the MUA will be in addition to any signature added
         by the MSA.

         Some user software goes beyond simple user functionality and
         also perform MSA and MTA functions.  When this is employed for
         sending directly to a receiving ADMD, the user software SHOULD
         be considered an outbound MTA.

      Inbound:   An MUA MAY rely on a report of a DKIM signature
         verification that took place at some point in the inbound MTA/
         MDA path (e.g., an Authentication-Results header field), or an
         MUA MAY perform DKIM signature verification directly.  A
         verifying MUA SHOULD allow for the case where mail has modified
         in the inbound MTA path; if a signature fails, the message
         SHOULD NOT be treated any different than if it did not have a
         signature.

         An MUA that looks for an Authentication-Results header field
         MUST be configurable to choose which Authentication-Results are
         considered trustable.

         DKIM requires that all verifiers treat messages with signatures
         that do not verify as if they are unsigned.

         If verification in the client is to be acceptable to users, it
         is essential that successful verification of a signature not
         result in a less than satisfactory user experience compared to
         leaving the message unsigned.  The mere presence of a verified
         DKIM signature MUST NOT by itself be used by an MUA to indicate
         that a message is to be treated better than a message without a
         verified DKIM signature.  However, the fact that a DKIM
         signature was verified MAY be used as input into a reputation
         system (i.e., a whitelist of domains and users) for
         presentation of such indicators.

   It is common for components of an ADMD's email infrastructure to do
   violence to a message, such that a DKIM signature might be rendered
   invalid.  Hence, users of MUAs that support DKIM signing and/or
   verifying need a basis for knowing that their associated email
   infrastructure will not break a signature.

9.  Other Considerations

9.1.  Security Considerations

   The security considerations of the DKIM protocol are described in the
   DKIM base specification [RFC4871].

9.2.  IANA Considerations

   This document has no considerations for IANA.

10.  Acknowledgements

   TBD

11.  Informative References

   [I-D.ietf-dkim-overview]
              Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
              Identified Mail (DKIM) Service Overview",
              draft-ietf-dkim-overview-10 (work in progress), July 2008.

   [I-D.ietf-dkim-ssp]
              Local-part, a., Domain, A., error, r., Allman, E., Fenton,
              J., Delany, M., and J. Levine, "DomainKeys Identified Mail
              (DKIM) Author Domain Signing Practices (ADSP)",
              draft-ietf-dkim-ssp-09 (work in progress), February 2009.

   [I-D.ietf-openpgp-rfc2440bis]
              Callas, J., "OpenPGP Message Format",
              draft-ietf-openpgp-rfc2440bis-22 (work in progress),
              April 2007.

   [I-D.kucherawy-sender-auth-header]
              Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status",
              draft-kucherawy-sender-auth-header-20 (work in progress),
              January 2009.

   [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.

   [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.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
              August 2001.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, September 2006.

   [RFC4870]  Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              May 2007.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007. M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

Appendix A.  Migrating from DomainKeys

   As with any migration, the steps required will be determined by who
   is doing the migration and their assessment of

   o  the users of what they are generating, or

   o  the providers of what they are consuming.

A.1.  Signers

   A signer that currently signs with DomainKeys (DK) will go through
   various stages as they migrate to using DKIM, not all of which are
   required for all signers.  The real questions that a signer must ask
   are:

   1.  how many receivers or what types of receivers are *only* looking
       at the DK signatures and not the DKIM signatures,

   2.  and how much does the signer care about those receivers?

   If no one is looking at the DK signature any more, then it's no
   longer necessary to sign with DK.  Or if there are no more "large
   players" looking only at the DK signatures, a signer may choose to
   stop signing with DK.

   With respect to signing policies, a reasonable, initial approach is
   to use DKIM signatures in the same way as DomainKeys signatures are
   already being used.  In particular, the same selectors and DNS Key
   Records may be used for both, after verifying that they are
   compatible as discussed below.

   Each secondary step in all of the following scenarios is to be
   prefaced with the gating factor "test, then when comfortable with the
   previous step's results, continue".

   One migration strategy is to:

   o  ensure that the current selector DNS key record is compatible with
      both DK and DKIM

   o  sign messages with both DK and DKIM signatures
   o  when it's decided that DK signatures are no longer necessary, stop
      signing with DK

   Another migration strategy is to:

   o  add a new selector DNS key record only for DKIM signatures

   o  sign messages with both DK (using the old DNS key record) and DKIM
      signatures (using the new DNS key record)

   o  when it's decided that DK signatures are no longer necessary, stop
      signing with DK

   o  eventually remove the old DK selector DNS record

   A combined migration strategy is to:

   o  ensure that the current selector DNS key record is compatible with
      both DK and DKIM

   o  start signing messages with both DK and DKIM signatures

   o  add a new selector DNS key record for DKIM signatures

   o  switch the DKIM signatures to use the new selector

   o  when it's decided that DK signatures are no longer necessary, stop
      signing with DK

   o  eventually remove the old DK selector DNS record

   Another migration strategy is to:

   o  add a new selector DNS key record for DKIM signatures

   o  do a flash cut and replace the DK signatures with DKIM signatures

   o  eventually remove the old DK selector DNS record

   Another migration strategy is to:

   o  ensure that the current selector DNS key record is compatible with
      both DK and DKIM

   o  do a flash cut and replace the DK signatures with DKIM signatures

   Note that when you have separate key records for DK and DKIM, you can
   use the same public key for both.

A.1.1.  DNS Selector Key Records

   The first step in some of the above scenarios is ensuring that the
   selector DNS key records are compatible for both DK and DKIM.  The
   format of the DNS key record was intentionally meant to be backwardly
   compatible between the two systems, but not necessarily upwardly
   compatible.  DKIM has enhanced the DK DNS key record format by adding
   several optional parameters, which DK must ignore.  However, there is
   one critical difference between DK and DKIM DNS key records: the
   definitions of the g fields:

   g= granularity of the key  In both DK and DKIM, this is an optional
      field that is used to constrain which sending address(es) can
      legitimately use this selector.  Unfortunately, the treatment of
      an empty field ("g=;") is different.  DKIM allows wildcards where
      DK does not.  For DK, an empty field is the same as a missing
      value, and is treated as allowing any sending address.  For DKIM,
      an empty field only matches an empty local part.  In DKIM, both a
      missing value and "g=*;" mean to allow any sending address.

      If your DK DNS key record has an empty g= field in it ("g=;"),
      your best course of action is to modify the record to remove the
      empty field.  In that way, the DK semantics will remain the same,
      and the DKIM semantics will match.

   If your DNS key record does not have an empty g= field in it ("g=;"),
   it's probable that the record can be left alone.  But your best
   course of action would still be to make sure it has a v= field.  When
   the decision is made to stop supporting DomainKeys and to only
   support DKIM, you MUST verify that the "g" field is compatible with
   DKIM, and it SHOULD have "v=DKIM1;" in it.  It is highly RECOMMENDED
   that if you want to use an empty g= field in your DKIM selector, you
   also include the v= field.

A.1.2.  Removing DomainKeys Signatures

   The principal use of DomainKeys is at Boundary MTAs.  Because no
   operational transition is ever instantaneous, it is advisable to
   continue performing DomainKeys signing until it is determined that
   DomainKeys receive-side support is no longer used, or is sufficiently
   reduced.  That is, a signer SHOULD add a DKIM signature to a message
   that also has a DomainKeys signature and keep it there until you
   decide it can go away.  The signer may do its transitions in a
   straightforward manner, or more gradually.  Note that because digital
   signatures are not free, there is a cost to performing both signing
   algorithms, so you don't want to be signing with both algorithms for
   too long a period.

   The tricky part is deciding when DK signatures are no longer
   necessary.  The real questions are: how many DomainKeys verifiers are
   there that do *not* also do DKIM verification, which ones of them do
   you care about, and how can you track their usage?  Most of the early
   adopters of DK verification have added DKIM verification, but not all
   yet.  If a verifier finds a message with both DK and DKIM, it may
   choose to verify both signatures, or just one or the other.

   Many DNS services offer tracking statistics so you can find out how
   often a DNS record has been accessed.  By using separate DNS selector
   key records for your signatures, you can chart the usage of your
   records over time, and watch the trends.  An additional
   distinguishing factor to track would take into account the verifiers
   that verify both the DK and DKIM signatures, and discount those from
   your counts of DK selector usage.  When the number for DK selector
   access reaches a low-enough level, that's the time to consider
   stopping your DK signing.

   Note, this level of rigor is not required.  It is perfectly
   reasonable for a DK signer to decide to follow the "flash cut"
   scenario described above.

A.2.  Verifiers

   As a verifier, you are faced with several issues:

A.2.1.  Do you verify DK signatures?

   At the time of writing, there is still a significant number of sites
   that are only producing DK signatures.  Over time, it is expected
   that this number will go to zero, but it may take several years.  So
   it would be prudent for the foreseeable future for a verifier to look
   for and verify both DKIM and DK signatures.

A.2.2.  Do you verify both DK and DKIM signatures within a single
        message?

   For a period of time, there will be sites that sign with both DK and
   DKIM.  A verifier receiving a message that has both types of
   signatures may verify both signatures, or just one.  One disadvantage
   of verifying both signatures is that signers will have a more
   difficult time deciding how many verifiers are still using their DK
   selectors.  One transition strategy is to verify the DKIM signature,
   then only verify the DK signature if the DKIM verification fails.

A.2.3.  DNS Selector Key Records

   The format of the DNS key record was intentionally meant to be
   backwardly compatible between DK and DKIM, but not necessarily
   upwardly compatible.  DKIM has enhanced the DK DNS key record format
   by adding several optional parameters, which DK must ignore.
   However, there is one key difference between DK and DKIM DNS key
   records: the definitions of the g fields:

   g= granularity of the key  In both DK and DKIM, this is an optional
      field that is used to constrain which sending address(es) can
      legitimately use this selector.  Unfortunately, the treatment of
      an empty field ("g=;") is different.  For DK, an empty field is
      the same as a missing value, and is treated as allowing any
      sending address.  For DKIM, an empty field only matches an empty
      local part.

   v= version of the selector  It is recommended that a DKIM selector
      have v=DKIM1; at its beginning, but it is not required.

   If a DKIM verifier finds a selector record that has an empty g= field
   ("g=;") and it does not have a v= field ("v=DKIM1;") at its
   beginning, it is faced with deciding if this record was

   1.  from a DK signer that transitioned to supporting DKIM but forgot
       to remove the g= field (so that it could be used by both DK and
       DKIM verifiers), or

   2.  from a DKIM signer that truly meant to use the empty g= field but
       forgot to put in the v= field.  It is RECOMMENDED that you treat
       such records using the first interpretation, and treat such
       records as if the signer did not have a g= field in the record.

Appendix B.  General Coding Criteria for Cryptographic Applications

   NOTE: This section could possibly be changed into a reference to
   something else, such as another rfc.

   Correct implementation of a cryptographic algorithm is a necessary
   but not a sufficient condition for the coding of cryptographic
   applications.  Coding of cryptographic libraries requires close
   attention to security considerations that are unique to cryptographic
   applications.

   In addition to the usual security coding considerations, such as
   avoiding buffer or integer overflow and underflow, implementers
   should pay close attention to management of cryptographic private
   keys and session keys, ensuring that these are correctly initialized
   and disposed of.

   Operating system mechanisms that permit the confidentiality of
   private keys to be protected against other processes should be used
   when available.  In particular, great care must be taken when
   releasing memory pages to the operating system to ensure that private
   key information is not disclosed to other processes.

   Certain implementations of public key algorithms such as RSA may be
   vulnerable to a timing analysis attack.

   Support for cryptographic hardware providing key management
   capabilities is strongly encouraged.  In addition to offering
   performance benefits, many cryptographic hardware devices provide
   robust and verifiable management of private keys.

   Fortunately appropriately designed and coded cryptographic libraries
   are available for most operating system platforms under license terms
   compatible with commercial, open source and free software license
   terms.  Use of standard cryptographic libraries is strongly
   encouraged.  These have been extensively tested, reduce development
   time and support a wide range of cryptographic hardware.

Authors' Addresses

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave. South
   Middletown, NJ  07748
   USA

   Email: tony+dkimov@maillennium.att.com

   Ellen Siegel
   Constant Contact, Inc.
   1601 Trapelo Rd, Ste 329
   Waltham, MA  02451
   USA

   Email: esiegel@constantcontact.com
   Phillip Hallam-Baker
   VeriSign Inc.

   Email: pbaker@verisign.com

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   USA

   Email: dcrocker@bbiw.net

   Ellen Siegel
   Constant Contact, Inc.
   1601 Trapelo Rd, Ste 329
   Waltham, MA  02451
   USA

   Email: esiegel@constantcontact.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.