DomainKeys Identified Mail (DKIM) Signatures - Over DOSETA
draft-crocker-dkim-rfc4871bis-Doseta-00

Abstract

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to a message or its content and thus preserve the DKIM signature.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on July 18, 2011.

Copyright Notice

Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Signing Identity {rfc4871bis-02 1.1}
    1.2.  Terminology and Definitions
2.  Signing and Verifying Protocol {added}
3.  Extensions to DOSETA Template {rfc4871bis-02 - adapted for Doseta overlay}
    3.1.  Signature Data Structure {rfc4871bis-02 3.5, subset}
    3.2.  Relationship between SDID and AUID {rfc4871bis-02 3.9}
    3.3.  Stored Key Data {rfc4871bis-02 3.6.1, subset}
4.  Considerations
    4.1.  Security Considerations {rfc4871bis-02 8, subset}
    4.2.  IANA Considerations {rfc4871bis-02 7, subset}
5.  References
    5.1.  Normative References
    5.2.  Informative References
Appendix A.  MUA Considerations {rfc4871bis-02 D}
Appendix B.  End-to-End Scenario Example {rfc4871bis-02 A}
    B.1.  The User Composes an Email
    B.2.  The Email is Signed
    B.3.  The Email Signature is Verified
Appendix C.  Types of Use {rfc4871bis-02 B}
    C.1.  Alternate Submission Scenarios
    C.2.  Alternate Delivery Scenarios
Appendix D.  Acknowledgements
§  Authors' Addresses

1.  Introduction

DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] (Mockapetris, P., “DOMAIN NAMES - CONCEPTS AND FACILITIES,” November 1987.) with the message [RFC5322] (Resnick, P., “Internet Message Format,” October 2008.). This can be an author's organization, an operational relay or one of their agents. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message.

The DKIM service is described in detail in [RFC5585] (Hansen, T., Crocker, D., and P. Hallam-Baker, “DomainKeys Identified Mail (DKIM) Service Overview,” June 2009.) and [RFC5863] (Hansen, T., Siegel, H., Hallam-Baker, P., and D. Crocker, “DomainKeys Identified Mail (DKIM): Development, Deployment, and Operations,” May 2010.).

This version of DKIM is based on a split between DKIM-specific details, versus an underlying component mechanism, called DOSETA, that can be used for other services. [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.).

NOTE:

Much of the text for this draft is taken from the DKIM working group draft-ietf-DKIM-rfc4871bis-02 revision. Sections in this document cross reference their source with the notation:

{rfc4871bis-02 xx}

where "xx" indicates the section number. It might also indicate that a subset is taken, such as when a portion is applied to the DKIM-over-DOSETA draft and a portion to the DOSETA draft. In some cases the base text also has been enhanced.

The approach taken by DKIM differs from previous approaches to message signing (for example., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC1847] (Galvin, J., Murphy, S., Crocker, S., and N. Freed, “Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted,” October 1995.), OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, “OpenPGP Message Format,” November 2007.)) in that:

• the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body;
• there is no dependency on public and private key pairs being issued by well-known, trusted certificate authorities;
• there is no dependency on the deployment of any new Internet protocols or services for public key distribution or revocation;
• signature verification failure does not force rejection of the message;
• no attempt is made to include encryption as part of the mechanism;
• message archiving is not a design goal.

DKIM:

• is compatible with the existing email infrastructure and transparent to the fullest extent possible;
• requires minimal new infrastructure;
• can be implemented independently of clients in order to reduce deployment time;
• can be deployed incrementally;
• allows delegation of signing to third parties.

1.1.  Signing Identity {rfc4871bis-02 1.1}

DKIM separates the question of the identity of the signer of the message from the purported author of the message. In particular, a signature includes the identity of the signer. Verifiers can use the signing information to decide how they want to process the message. The signing identity is included as part of the signature header field.

The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs.

1.2.  Terminology and Definitions

This specification incorporates the terminology defined in [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.).

Syntax descriptions use Augmented BNF (ABNF) [RFC5234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Additional terminology: {rfc4871bis-02 #2, subset}

Signing Domain Identifier (SDID):

This augments the definition provided by DOSETA [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.). A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming responsibility for introduction of a message into the mail stream. For DKIM processing, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.1 (Signature Data Structure {rfc4871bis-02 3.5, subset}).

Agent or User Identifier (AUID):

A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional <local-part>. The domain name is the same as that used for the SDID or is a sub-domain of it. For DOSETA processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DOSETA. It is specified in Section 3.1 (Signature Data Structure {rfc4871bis-02 3.5, subset}) .

Identity Assessor:

This augments the definition of Assessor in [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.). A module that consumes DOSETA's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DOSETA (and non-DOSETA) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification.

2.  Signing and Verifying Protocol {added}

DKIM uses the DOSETA "Generic Header/Content Signing Service Template" [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.) as its base.

The DOSETA template specifies TEMPLATE information that is required to tailor the signing service:

Signature Association:

The DOSETA‑Signature data are stored in a DKIM‑Signature header field that is part of the Header of the message being signed. This contains all of the signature and key-fetching data, per [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.).

Semantics Signaling:

The presence of a DKIM‑Signature header fields signals the use of DKIM.

Semantics:

A DKIM signature means that the owner of the signing domain is taking "some" responsibility for the message. Hence, the payload, or output, of DKIM is:

• A validated domain name, specifically the d= parameter in the DKIM‑Signature header field
• An indication that its use has been validated

The nature and extent of a DKIM signer's responsibility can vary widely and is beyond the scope of this specification.

Header/Content Mapping:

DKIM maps the DOSETA Header processing to an email header and the DOSETA Content to an email body, per [RFC5322] (Resnick, P., “Internet Message Format,” October 2008.)

3.  Extensions to DOSETA Template {rfc4871bis-02 - adapted for Doseta overlay}

This section contains specifications that are added to the basic DOSETA H/C Signing Template.

3.1.  Signature Data Structure {rfc4871bis-02 3.5, subset}

These are DKIM-specific tags: (

i=

The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (DOSETA-quoted-printable; OPTIONAL, default is an empty <local-part> followed by an "@" followed by the domain from the "d=" tag).

The syntax is a standard email address where the <local-part> MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of, the value of the "d=" tag.

Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC5890] (Klensin, J., “Internationalizing Domain Names in Applications (IDNA): Definitions and Document Framework,” August 2010.) using the "ToASCII" function.

ABNF:

sig-i-tag       = %x69 [FWS] "=" [FWS]
                  [ local-part ] "@" domain-name

The AUID is specified as having the same syntax as an email address, but is not required to have the same semantics. Notably, the domain name is not required to be registered in the DNS -- so it might not resolve in a query -- and the <local-part> MAY be drawn from a namespace unrelated to any mailbox. The details of the structure and semantics for the namespace are determined by the Signer. Any knowledge or use of those details by verifiers or assessors is outside the scope of the DOSETA Signing specification. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID.

NOTE:

The <local-part> of the "i=" tag is optional because in some cases a signer might not be able to establish a verified individual identity. In such cases, the signer might wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the <local-part> of the identity.

NOTE:

Absent public standards for the semantics of an AUID, an assessment based on AUID requires a non-standardized basis.

NOTE:

This specification does not require the value of the "i=" tag to match the identity in any Header field. This is considered to be an assessment-time policy issue. Constraints between the value of the "i=" tag and other identities in other Header fields might seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the "i=" value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options needs to be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the "i=" options.

l=

Content length count (plain-text unsigned decimal integer; OPTIONAL, default is entire Content). This tag informs the verifier of the number of octets in the Content of the data after canonicalization included in the cryptographic hash, starting from 0 immediately following the CRLF preceding the Content. This value MUST NOT be larger than the actual number of octets in the canonicalized Content.

ABNF:

sig-l-tag    = %x6c [FWS] "=" [FWS]
               1*76DIGIT

NOTE:

Use of the "l=" tag might allow display of fraudulent content without appropriate warning to end users. The "l=" tag is intended for increasing signature robustness when sending to intermediaries that append data to Content, such as mailing lists that both modify their content and do not sign their messages. However, using the "l=" tag enables attacks in which an intermediary with malicious intent modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. Examples are described in Security Considerations Section 4.1 (Security Considerations {rfc4871bis-02 8, subset}). To avoid this attack, signers need be extremely wary of using this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length.

NOTE:

The value of the "l=" tag is constrained to 76 decimal digits. This constraint is not intended to predict the size of future data or to require implementations to use an integer representation large enough to represent the maximum possible value, but is intended to remind the implementer to check the length of this and all other tags during verification and to test for integer overflow when decoding the value. Implementers might need to limit the actual value expressed to a value smaller than 10^76, for example, to allow a message to fit within the available storage space.

z=

Copied Header fields (DOSETA-quoted-printable, but see description; OPTIONAL, default is null). A vertical-bar-separated list of selected Header fields present when the message was signed, including both the field name and value. It is not required to include all Header fields present at the time of signing. This field need not contain the same Header fields listed in the "h=" tag. The Header field text itself MUST encode the vertical bar ("|", %x7C) character. That is, vertical bars in the "z=" text are meta-characters, and any actual vertical bar characters in a copied header field MUST be encoded. Note that all whitespace MUST be encoded, including whitespace between the colon and the header field value. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field, and MUST be removed before decoding.

The Header fields referenced by the "h=" tag refer to the fields in the [RFC5322] (Resnick, P., “Internet Message Format,” October 2008.) Header, not to any copied fields in the "z=" tag. Copied header field values are for diagnostic use.

Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC5322] (Resnick, P., “Internet Message Format,” October 2008.) compliant) SHOULD be converted as described in MIME Part Three [RFC2047] (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Content,” November 1996.).

ABNF:

sig-z-tag      = %x7A [FWS] "=" [FWS]
                 sig-z-tag-copy
                 *( "|" [FWS] sig-z-tag-copy )
sig-z-tag-copy = hdr-name [FWS] ":"
                 qp-hdr-value

EXAMPLE of a signature header field spread across multiple continuation lines:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net;
  s=brisbane;   c=simple; q=dns/txt; i=@eng.example.net;
  t=1117574938; x=1118006938;
  h=from:to:subject:date;
  z=From:foo@eng.example.net|To:joe@example.com|
   Subject:demo=20run|
   Date:July=205,=202005=203:44:08=20PM=20-0700;
  bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

3.1.1.  Content Length Limits {rfc4871bis-02 3.4.5}

A text length count MAY be specified to limit the signature calculation to an initial prefix of an ASCII text data portion, measured in octets. If the Content length count is not specified, the entire Content is signed.

This capability is provided because it is very common for intermediate data handling services to add trailers to text (for example, instructions how to get off a mailing list). Until such data is signed by the intermediate handler, the text length count can be a useful tool for the verifier since it can, as a matter of policy, accept messages having valid signatures that do not cover the additional data.

NOTE:

Using text length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. To avoid this attack, signers need to be wary of using this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length, perhaps based on other criteria.

The text length count allows the signer of text to permit data to be appended to the end of the text of a signed message. The text length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the Content length count. Signers of MIME messages that include a Content length count SHOULD be sure that the length extends to the closing MIME boundary string.

NOTE:

A creator wishing to ensure that the only acceptable modifications are to add to a MIME postlude would use a text length count encompassing the entire final MIME boundary string, including the final "--CRLF". A signer wishing to allow additional MIME parts but not modification of existing parts would use a Content length count extending through the final MIME boundary string, omitting the final "--CRLF". Note that this only works for some MIME types, such as, multipart/mixed but not multipart/signed.

A text length count of zero means that the text is completely unsigned.

Creators wishing to ensure that no modification of any sort can occur will specify the "simple" canonicalization algorithm for all data portions and will and omit the text length counts.

3.1.2.  Recommended Signature Content {rfc4871bis-02 5.5}

In order to maximize compatibility with a variety of verifiers, it is recommended that signers follow the practices outlined in this section when signing a message. However, these are generic recommendations applying to the general case; specific senders might wish to modify these guidelines as required by their unique situations. Verifiers MUST be capable of verifying signatures even if one or more of the recommended Header fields is not signed (with the exception of From:, which MUST always be signed) or if one or more of the dis-recommended Header fields is signed. Note that verifiers do have the option of ignoring signatures that do not cover a sufficient portion of the header or Content, just as they might ignore signatures from an identity they do not trust.

The following Header fields SHOULD be included in the signature, if they are present in the message being signed:

• From (REQUIRED in all signatures)
• Sender, Reply-To
• Subject
• Date, Message-ID
• To, Cc
• MIME-Version
• Content-Type, Content-Transfer-Encoding, Content-ID, Content- Description
• Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Message-ID
• In-Reply-To, References
• List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

The following Header fields SHOULD NOT be included in the signature:

• Return-Path
• Received
• Comments, Keywords
• Bcc, Resent-Bcc
• DOSETA‑Signature

Optional Header fields (those not mentioned above) normally SHOULD NOT be included in the signature, because of the potential for additional Header fields of the same name to be legitimately added or reordered prior to verification. There are likely to be legitimate exceptions to this rule, because of the wide variety of application- specific Header fields that might be applied to a message, some of which are unlikely to be duplicated, modified, or reordered.

Signers SHOULD choose canonicalization algorithms based on the types of data they process and their aversion to risk. For example, e-commerce sites sending primarily purchase receipts, which are not expected to be processed by intermediaries such as mailing lists or other software likely to modify data, will generally prefer "simple" canonicalization. Sites sending primarily person-to-person data will likely prefer to be more resilient to modification during transport by using "relaxed" canonicalization.

Signers SHOULD NOT use "l=" unless they intend to accommodate intermediate data processors that append text to a message. For example, many mailing list processors append "unsubscribe" information to message bodies. If signers use "l=", they SHOULD include the entire Content existing at the time of signing in computing the count. In particular, signers SHOULD NOT specify a Content length of 0 since this might be interpreted as a meaningless signature by some verifiers.

3.1.3.  Signature Verification {rfc4871bis-02 6.1.3, subset}

A Content length specified in the "l=" tag of the signature limits the number of bytes of the Content passed to the verification algorithm. All data beyond that limit is not validated by DOSETA. Hence, verifiers might treat a message that contains bytes beyond the indicated Content length with suspicion, such as by truncating the message at the indicated Content length, declaring the signature invalid (for example, by returning PERMFAIL (unsigned content)), or conveying the partial verification to the policy module.

NOTE:

Verifiers that truncate the Content at the indicated Content length might pass on a malformed MIME message if the signer used the "N-4" trick (omitting the final "--CRLF") described in the informative note in Section 3.1.1 (Content Length Limits {rfc4871bis-02 3.4.5}). Such verifiers might wish to check for this case and include a trailing "--CRLF" to avoid breaking the MIME structure. A simple way to achieve this might be to append "--CRLF" to any "multipart" message with a Content length; if the MIME structure is already correctly formed, this will appear in the postlude and will not be displayed to the end user.

3.2.  Relationship between SDID and AUID {rfc4871bis-02 3.9}

DOSETA's primary task is to communicate from the Signer to a recipient-side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity. DOSETA MAY optionally provide a single responsible Agent or User Identifier (AUID).

Hence, DOSETA's mandatory output to a receive-side Identity Assessor is a single domain name. Within the scope of its use as DOSETA output, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DOSETA. That is, within its role as a DOSETA identifier, additional semantics cannot be assumed by an Identity Assessor.

Upon successfully verifying the signature, a receive-side DOSETA verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.

To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DOSETA's specification and semantics. Hence, it is relegated to a higher-level service, such as a delivery handling filter that integrates a variety of inputs and performs heuristic analysis of them.

This document does not require the value of the SDID or AUID to match an identifier in any other message header field. Such a requirement is, instead, an assessor policy issue. The purpose of such a linkage could be to authenticate the value in that other header field. This, in turn, is the basis for applying a trust assessment based on the identifier value. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the SDID or AUID and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence, reliance on the use of such bindings SHOULD be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the SDID or AUID.

3.3.  Stored Key Data {rfc4871bis-02 3.6.1, subset}

This section defines additions to the DOSETA Library, concerning stored key data.

g=

Granularity of the key (plain-text; OPTIONAL, default is "*"). This value MUST match the Local-part of the "i=" tag of the DKIM- Signature header field (or its default value of the empty string if "i=" is not specified), with a single, optional "*" character matching a sequence of zero or more arbitrary characters ("wildcarding"). An email with a signing address that does not match the value of this tag constitutes a failed verification. The intent of this tag is to constrain which signing address can legitimately use this selector, for example, when delegating a key to a third party that should only be used for special purposes. Wildcarding allows matching for addresses such as "user+*" or "*-offer". An empty "g=" value never matches any addresses.

ABNF:

key-g-tag       = %x67 [FWS] "=" [FWS] key-g-tag-lpart
                     key-g-tag-lpart = [dot-atom-text]
                                       ["*" [dot-atom-text] ]

h=

Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Signers and Verifiers MUST support the "sha256" hash algorithm. Verifiers MUST also support the "sha1" hash algorithm. Unrecognized hash algorithms MUST be ignored.

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS]
                  key-h-tag-alg
                  0*( [FWS] ":" [FWS]
                  key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" /
                  x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word
                       ; for future extension

s=

Service Type (plain-text; OPTIONAL; default is "*"). A colon-separated list of service types to which this record applies. Verifiers for a given service type MUST ignore this record if the appropriate type is not listed. Unrecognized service types MUST be ignored. Currently defined service types are as follows:

*

matches all service types

email

electronic mail (not necessarily limited to SMTP)

This tag is intended to constrain the use of keys for other purposes, if use of DOSETA is defined by other services in the future.

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS]
                   key-s-tag-type
                   0*( [FWS] ":" [FWS]
                   key-s-tag-type )
key-s-tag-type   = "email" / "*" /
                   x-key-s-tag-type
x-key-s-tag-type = hyphenated-word
                        ; for future extension

t=

Flags, represented as a colon-separated list of names (plain-text; OPTIONAL, default is no flags set). Unrecognized flags MUST be ignored. The defined flags are as follows:

y

This domain is testing DOSETA. Verifiers MUST NOT treat data from signers in testing mode differently from unsigned data, even if the signature fails to verify. Verifiers MAY wish to track testing mode results to assist the signer.

s

Any DOSETA‑Signature Header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag. That is, the "i=" domain MUST NOT be a subdomain of "d=". Use of this flag is RECOMMENDED unless subdomaining is required.

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS]
                   key-t-tag-flag
                   0*( [FWS] ":" [FWS]
                   key-t-tag-flag )
key-t-tag-flag   = "y" / "s" /
                   x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word
                        ; for future extension

4.  Considerations

4.1.  Security Considerations {rfc4871bis-02 8, subset}

4.1.1.  Misuse of Content Length Limits ("l=" Tag)

Content length limits (in the form of the "l=" tag) are subject to several potential attacks.

4.1.1.1.  Addition of New MIME Parts to Multipart/*

If the Content length limit does not cover a closing MIME multipart section (including the trailing "--CRLF" portion), then it is possible for an attacker to intercept a properly signed multipart message and add a new Content part. Depending on the details of the MIME type and the implementation of the Consumer, this could allow an attacker to change the information displayed to an end user from an apparently trusted source.

For example, if attackers can append information to a "text/html" Content part, they might be able to exploit a bug in some MUAs that continue to read after a "</html>" marker, and thus display HTML text on top of already displayed text. If a message has a "multipart/alternative" Content part, they might be able to add a new Content part that is preferred by the displaying MUA.

4.1.1.2.  Addition of new HTML content to existing content

Several receiving MUA implementations do not cease display after a ""</html>"" tag. In particular, this allows attacks involving overlaying images on top of existing text.

EXAMPLE: Appending the following text to an existing, properly closed message will in many MUAs result in inappropriate data being rendered on top of existing, correct data:

<div style="position: relative; bottom: 350px; z-index: 2;">
<img src="http://www.ietf.org/images/ietflogo2e.gif"
     width=578 height=370> </div>

4.2.  IANA Considerations {rfc4871bis-02 7, subset}

DKIM uses registries now assigned to DOSETA [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.). This section specifies additions to the registries that were in the original DKIM Signing specification. They are not part of the DOSETA specification, but are now specific to DKIM.

4.2.1.  DKIM‑Signature Tag Specifications

These values are added to the registry that is now defined in [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.):

4.2.2.  _domainkey DNS TXT Record Tag Specifications

These values are added to the registry that is now defined in [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.):

4.2.3.  DKIM Service Types Registry

The "s=" <key-s-tag> tag (specified in Section 3.3 (Stored Key Data {rfc4871bis-02 3.6.1, subset})) provides for a list of service types to which this selector might apply.

IANA has established the DKIM Service Types Registry for service types.

The initial entries in the registry comprise:

4.2.4.  DKIM Service Flags Registry

The "t=" <key-t-tag> tag (specified in Section 3.3 (Stored Key Data {rfc4871bis-02 3.6.1, subset})) provides for a list of flags to modify interpretation of the selector.

IANA has established the DKIM Selector Flags Registry for additional flags.

The initial entries in the registry comprise:

4.2.5.  DKIM‑Signature Header Field

IANA has added DKIM‑Signature to the "Permanent Message Header Fields" registry (see [RFC3864] (Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields,” September 2004.)) for the "mail" protocol, using this document as the reference.

5.  References

5.1. Normative References

5.2. Informative References

Appendix A.  MUA Considerations {rfc4871bis-02 D}

When a DKIM signature is verified, the processing system sometimes makes the result available to the recipient user's MUA. How to present this information to the user in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message. An MUA might do this with visual cues such as graphics, or it might include the address in an alternate view, or it might even rewrite the original From address using the verified information. Some MUAs might indicate which header fields were protected by the validated DKIM signature. This could be done with a positive indication on the signed header fields, with a negative indication on the unsigned header fields, by visually hiding the unsigned header fields, or some combination of these. If an MUA uses visual indications for signed header fields, the MUA probably needs to be careful not to display unsigned header fields in a way that might be construed by the end user as having been signed. If the message has an l= tag whose value does not extend to the end of the message, the MUA might also hide or mark the portion of the message body that was not signed.

The aforementioned information is not intended to be exhaustive. The MUA may choose to highlight, accentuate, hide, or otherwise display any other information that may, in the opinion of the MUA author, be deemed important to the end user.

Appendix B.  End-to-End Scenario Example {rfc4871bis-02 A}

This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together. The key used in this example is shown in [I‑D.Doseta] (Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA),” 2010.), "Creating a Public Key".

B.1.  The User Composes an Email

From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <;20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

B.2.  The Email is Signed

This email is signed by the example.com outbound email server and now looks like this:

DOSETA&nbhy;Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
     c=simple/simple; q=dns/txt; i=joe@football.example.com;
     h=Received : From : To : Subject : Date : Message-ID;
     bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
     b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
     4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
     KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
     4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
     by submitserver.example.com with SUBMISSION;
     Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

The signing email server requires access to the private key associated with the "brisbane" selector to generate this signature.

B.3.  The Email Signature is Verified

The signature is normally verified by an inbound SMTP server or possibly the final delivery agent. However, intervening MTAs can also perform this verification if they choose to do so. The verification process uses the domain "example.com" extracted from the "d=" tag and the selector "brisbane" from the "s=" tag in the DOSETA‑Signature header field to form the DNS DOSETA query for: brisbane._domainkey.example.com

Signature verification starts with the physically last Received header field, the From header field, and so forth, in the order listed in the "h=" tag. Verification follows with a single CRLF followed by the body (starting with "Hi."). The email is canonically prepared for verifying with the "simple" method. The result of the query and subsequent verification of the signature is stored (in this example) in the X-Authentication-Results header field line. After successful verification, the email looks like this:

X-Authentication-Results: shopping.example.net
  header.from=joe@football.example.com; DOSETA=pass
Received: from mout23.football.example.com (192.168.1.1)
  by shopping.example.net with SMTP;
  Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DOSETA&nbhy;Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
  c=simple/simple; q=dns/txt; i=joe@football.example.com;
  h=Received : From : To : Subject : Date : Message-ID;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
    4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
    KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
    4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
  by submitserver.example.com with SUBMISSION;
  Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

Appendix C.  Types of Use {rfc4871bis-02 B}

DOSETA signing and validating can be used in different ways, for different operational scenarios. This Appendix discusses some common examples.

NOTE:

Descriptions in this Appendix are for informational purposes only. They describe various ways that DOSETA can be used, given particular constraints and needs. In no case are these examples intended to be taken as providing explanation or guidance concerning DOSETA specification details, when creating an implementation.

C.1.  Alternate Submission Scenarios

In the most simple scenario, a user's MUA, MSA, and Internet (boundary) MTA are all within the same administrative environment, using the same domain name. Therefore, all of the components involved in submission and initial transfer are related. However, it is common for two or more of the components to be under independent administrative control. This creates challenges for choosing and administering the domain name to use for signing, and for its relationship to common email identity Header fields.

C.1.1.  Delegated Business Functions

Some organizations assign specific business functions to discrete groups, inside or outside the organization. The goal, then, is to authorize that group to sign some mail, but to constrain what signatures they can generate. DOSETA selectors (the "s=" signature tag) facilitate this kind of restricted authorization. Examples of these outsourced business functions are legitimate email marketing providers and corporate benefits providers.

Here, the delegated group needs to be able to send messages that are signed, using the email domain of the client company. At the same time, the client often is reluctant to register a key for the provider that grants the ability to send messages for arbitrary addresses in the domain.

There are multiple ways to administer these usage scenarios. In one case, the client organization provides all of the public query service (for example, DNS) administration, and in another it uses DNS delegation to enable all ongoing administration of the DOSETA key record by the delegated group.

If the client organization retains responsibility for all of the DNS administration, the outsourcing company can generate a key pair, supplying the public key to the client company, which then registers it in the query service, using a unique selector. The client company retains control over the use of the delegated key because it retains the ability to revoke the key at any time.

If the client wants the delegated group to do the DNS administration, it can have the domain name that is specified with the selector point to the provider's DNS server. The provider then creates and maintains all of the DKIM signature information for that selector. Hence, the client cannot provide constraints on the <local-part> of addresses that get signed, but it can revoke the provider's signing rights by removing the DNS delegation record.

C.1.2.  PDAs and Similar Devices

PDAs demonstrate the need for using multiple keys per domain. Suppose that John Doe wanted to be able to send messages using his corporate email address, jdoe@example.com, and his email device did not have the ability to make a Virtual Private Network (VPN) connection to the corporate network, either because the device is limited or because there are restrictions enforced by his Internet access provider. If the device was equipped with a private key registered for jdoe@example.com by the administrator of the example.com domain, and appropriate software to sign messages, John could sign the message on the device itself before transmission through the outgoing network of the access service provider.

C.1.3.  Roaming Users

Roaming users often find themselves in circumstances where it is convenient or necessary to use an SMTP server other than their home server; examples are conferences and many hotels. In such circumstances, a signature that is added by the submission service will use an identity that is different from the user's home system.

Ideally, roaming users would connect back to their home server using either a VPN or a SUBMISSION server running with SMTP AUTHentication on port 587. If the signing can be performed on the roaming user's laptop, then they can sign before submission, although the risk of further modification is high. If neither of these are possible, these roaming users will not be able to send mail signed using their own domain key.

C.1.4.  Independent (Kiosk) Message Submission

Stand-alone services, such as walk-up kiosks and web-based information services, have no enduring email service relationship with the user, but users occasionally request that mail be sent on their behalf. For example, a website providing news often allows the reader to forward a copy of the article to a friend. This is typically done using the reader's own email address, to indicate who the author is. This is sometimes referred to as the "Evite problem", named after the website of the same name that allows a user to send invitations to friends.

A common way this is handled is to continue to put the reader's email address in the From header field of the message, but put an address owned by the email posting site into the Sender header field. The posting site can then sign the message, using the domain that is in the Sender field. This provides useful information to the receiving email site, which is able to correlate the signing domain with the initial submission email role.

Receiving sites often wish to provide their end users with information about mail that is mediated in this fashion. Although the real efficacy of different approaches is a subject for human factors usability research, one technique that is used is for the verifying system to rewrite the From header field, to indicate the address that was verified. For example: From: John Doe via news@news-site.com <jdoe@example.com>. (Note that such rewriting will break a signature, unless it is done after the verification pass is complete.)

C.2.  Alternate Delivery Scenarios

Email is often received at a mailbox that has an address different from the one used during initial submission. In these cases, an intermediary mechanism operates at the address originally used and it then passes the message on to the final destination. This mediation process presents some challenges for DKIM signatures.

C.2.1.  Affinity Addresses

"Affinity addresses" allow a user to have an email address that remains stable, even as the user moves among different email providers. They are typically associated with college alumni associations, professional organizations, and recreational organizations with which they expect to have a long-term relationship. These domains usually provide forwarding of incoming email, and they often have an associated Web application that authenticates the user and allows the forwarding address to be changed. However, these services usually depend on users sending outgoing messages through their own service providers' MTAs. Hence, mail that is signed with the domain of the affinity address is not signed by an entity that is administered by the organization owning that domain.

With DOSETA, affinity domains could use the Web application to allow users to register per-user keys to be used to sign messages on behalf of their affinity address. The user would take away the secret half of the key pair for signing, and the affinity domain would publish the public half in DNS for access by verifiers.

This is another application that takes advantage of user-level keying, and domains used for affinity addresses would typically have a very large number of user-level keys. Alternatively, the affinity domain could handle outgoing mail, operating a mail submission agent that authenticates users before accepting and signing messages for them. This is of course dependent on the user's service provider not blocking the relevant TCP ports used for mail submission.

C.2.2.  Simple Address Aliasing (.forward)

In some cases a recipient is allowed to configure an email address to cause automatic redirection of email messages from the original address to another, such as through the use of a Unix .forward file. In this case, messages are typically redirected by the mail handling service of the recipient's domain, without modification, except for the addition of a Received header field to the message and a change in the envelope recipient address. In this case, the recipient at the final address' mailbox is likely to be able to verify the original signature since the signed content has not changed, and DOSETA is able to validate the message signature.

C.2.3.  Mailing Lists and Re-Posters

There is a wide range of behaviors in services that take delivery of a message and then resubmit it. A primary example is with mailing lists (collectively called "forwarders" below), ranging from those that make no modification to the message itself, other than to add a Received header field and change the envelope information, to those that add Header fields, change the Subject header field, add content to the body (typically at the end), or reformat the body in some manner. The simple ones produce messages that are quite similar to the automated alias services. More elaborate systems essentially create a new message.

A Forwarder that does not modify the body or signed Header fields of a message is likely to maintain the validity of the existing signature. It also could choose to add its own signature to the message.

Forwarders which modify a message in a way that could make an existing signature invalid are particularly good candidates for adding their own signatures (for example, mailing-list-name@example.net). Since (re-)signing is taking responsibility for the data, these signing forwarders are likely to be selective, and forward or re-sign a message only if it is received with a valid signature or if they have some other basis for knowing that the message is not spoofed.

A common practice among systems that are primarily redistributors of mail is to add a Sender header field to the message, to identify the address being used to sign the message. This practice will remove any preexisting Sender header field as required by [RFC5322] (Resnick, P., “Internet Message Format,” October 2008.). The forwarder applies a new DOSETA‑Signature header field with the signature, public key, and related information of the forwarder.

Appendix D.  Acknowledgements

The previous IETF version of DKIM [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) was edited by: Eric Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael Thomas.

That specification was the result of an extended, collaborative effort, including participation by: Russ Allbery, Edwin Aoki, Claus Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing.

The earlier DomainKeys was a primary source from which DKIM was derived. Further information about DomainKeys is at [RFC4870] (Delany, M., “Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys),” May 2007.).

Authors' Addresses