One document matched: draft-crocker-dkim-rfc4871bis-doseta-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- draft-ietf-dkim-rfc4871bis-Doseta-00-08dc -->
<rfc
category="std"
docName="draft-crocker-dkim-rfc4871bis-Doseta-00"
ipr="trust200902"
obsoletes="4871, 5672"
submissionType="IETF">
<front>
<title
abbrev="RFC4871bis">DomainKeys Identified Mail (DKIM) Signatures -
Over DOSETA</title>
<author
fullname="D. Crocker"
initials="D."
role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
<uri>http://bbiw.net</uri>
</address>
</author>
<!-- <author
fullname="Tony Hansen"
initials="T."
role="editor"
surname="Hansen">
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave. South</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>tony+dkimov@maillennium.att.com</email>
</address>
</author> -->
<author
fullname="M. Kucherawy"
initials="M."
role="editor"
surname="Kucherawy">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>USA</country>
</postal>
<email>msk@cloudmark.com</email>
</address>
</author>
<date
year="2011"/>
<workgroup>DKIM</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name <xref
target="RFC1034"/> with the message <xref
target="RFC5322"/>. 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. </t>
<t>The DKIM service is described in detail in <xref
target="RFC5585"/> and <xref
target="RFC5863"/>.<list>
<t>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. <xref
target="I-D.Doseta"/>.<list
style="hanging">
<t
hangText="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: <figure>
<artwork><![CDATA[{rfc4871bis-02 xx}]]></artwork>
</figure>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.</t>
</list></t>
</list>
</t>
<t>The approach taken by DKIM differs from previous approaches to
message signing (for example., Secure/Multipurpose Internet Mail
Extensions (S/MIME) <xref
target="RFC1847"/>, OpenPGP <xref
target="RFC4880"/>) in that: <list
style="symbols">
<t>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;</t>
<t>there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities; </t>
<t>there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or
revocation;</t>
<t>signature verification failure does not force rejection of
the message;</t>
<t>no attempt is made to include encryption as part of the
mechanism;</t>
<t>message archiving is not a design goal.</t>
</list></t>
<t>DKIM: <list
style="symbols">
<t>is compatible with the existing email infrastructure and
transparent to the fullest extent possible;</t>
<t>requires minimal new infrastructure;</t>
<t>can be implemented independently of clients in order to
reduce deployment time;</t>
<t>can be deployed incrementally;</t>
<t>allows delegation of signing to third parties.</t>
</list></t>
<section
title="Signing Identity {rfc4871bis-02 1.1}">
<t>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. </t>
<t>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.</t>
</section>
<section
title="Terminology and Definitions">
<t>This specification incorporates the terminology defined in <xref
target="I-D.Doseta"/>.</t>
<t>Syntax descriptions use Augmented BNF (ABNF) <xref
target="RFC5234"/>. </t>
<t>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 <xref
target="RFC2119"/>.</t>
<t>Additional terminology: {rfc4871bis-02 #2, subset}<list>
<t><list
style="hanging">
<t
hangText="Signing Domain Identifier (SDID): ">
This augments the definition provided by DOSETA <xref
target="I-D.Doseta"/>. 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 <xref
target="signeddatastruct"/>.</t>
<t
hangText="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 <xref
target="signeddatastruct"/> .</t>
<t
hangText="Identity Assessor: "> This augments the
definition of Assessor in <xref
target="I-D.Doseta"/>. 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. </t>
</list></t>
</list></t>
</section>
</section>
<section
title="Signing and Verifying Protocol {added}">
<t> DKIM uses the DOSETA "Generic Header/Content Signing Service
Template" <xref
target="I-D.Doseta"/> as its base.</t>
<t>The DOSETA template specifies TEMPLATE information that is
required to tailor the signing service:<list>
<t><list
style="hanging">
<t
hangText="Signature Association: ">The
DOSETA&nbhy;Signature data are stored in a
DKIM&nbhy;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 <xref
target="I-D.Doseta"/>.</t>
<t
hangText="Semantics Signaling: ">The presence of a
DKIM&nbhy;Signature header fields signals the use of
DKIM.</t>
<t
hangText="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:<list
style="symbols">
<t>A validated domain name, specifically the d=
parameter in the DKIM&nbhy;Signature header
field</t>
<t>An indication that its use has been
validated</t>
</list> The nature and extent of a DKIM signer's
responsibility can vary widely and is beyond the scope
of this specification.</t>
<t
hangText="Header/Content Mapping: ">DKIM maps the
DOSETA Header processing to an email header and the
DOSETA Content to an email body, per <xref
target="RFC5322"/></t>
</list></t>
</list>
</t>
</section>
<section
title="Extensions to DOSETA Template {rfc4871bis-02 - adapted for Doseta overlay}">
<t>This section contains specifications that are added to the basic
DOSETA H/C Signing Template.</t>
<section
anchor="signeddatastruct"
title="Signature Data Structure {rfc4871bis-02 3.5, subset}">
<t>These are DKIM-specific tags: (<list>
<t><list
style="hanging">
<t
hangText="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).</t>
<t>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.</t>
<t>Internationalized domain names MUST be converted
using the steps listed in Section 4 of <xref
target="RFC5890"/> using the "ToASCII"
function.</t>
<t>
<list>
<t>
<figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[sig-i-tag = %x69 [FWS] "=" [FWS]
[ local-part ] "@" domain-name]]></artwork>
</figure>
</t>
</list>
</t>
<t>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. <list
style="hanging">
<t
hangText="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.</t>
<t
hangText="NOTE: ">Absent public standards
for the semantics of an AUID, an assessment
based on AUID requires a non-standardized
basis.</t>
<t
hangText="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.</t>
</list></t>
<t
hangText="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. <list>
<t><figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[sig-l-tag = %x6c [FWS] "=" [FWS]
1*76DIGIT]]></artwork>
</figure></t>
</list>
<list
style="hanging">
<t
hangText="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 <xref
target="security"/>. 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.</t>
<t
hangText="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.</t>
</list>
</t>
<t
hangText="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.</t>
<t>The Header fields referenced by the "h=" tag refer
to the fields in the <xref
target="RFC5322"/> Header, not to any copied
fields in the "z=" tag. Copied header field values
are for diagnostic use.</t>
<t>Header fields with characters requiring conversion
(perhaps from legacy MTAs that are not <xref
target="RFC5322"/> compliant) SHOULD be
converted as described in MIME Part Three <xref
target="RFC2047"/>.</t>
<t>
<list>
<t>
<cref>errata 1379</cref>
<figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[
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]]></artwork>
</figure></t>
</list></t>
</list></t>
</list>
<cref>errata 1386</cref><figure
align="left">
<preamble>EXAMPLE of a signature header field spread across
multiple continuation lines:</preamble>
<artwork><![CDATA[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]]></artwork>
</figure></t>
<section
anchor="textlength"
title="Content Length Limits {rfc4871bis-02 3.4.5}">
<t>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. </t>
<t>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.</t>
<t><list
style="hanging">
<t
hangText="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.</t>
</list></t>
<t>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. <list
style="hanging">
<t
hangText="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.</t>
</list></t>
<t>A text length count of zero means that the text is
completely unsigned.</t>
<t>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.</t>
</section>
<section
title="Recommended Signature Content {rfc4871bis-02 5.5}">
<t>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.</t>
<t>The following Header fields SHOULD be included in the
signature, if they are present in the message being signed: <list
style="symbols">
<t>From (REQUIRED in all signatures)</t>
<t>Sender, Reply-To</t>
<t>Subject</t>
<t>Date, Message-ID</t>
<t>To, Cc</t>
<t>MIME-Version</t>
<t>Content-Type, Content-Transfer-Encoding, Content-ID,
Content- Description</t>
<t>Resent-Date, Resent-From, Resent-Sender, Resent-To,
Resent-Cc, Resent-Message-ID</t>
<t>In-Reply-To, References</t>
<t>List-Id, List-Help, List-Unsubscribe, List-Subscribe,
List-Post, List-Owner, List-Archive</t>
</list></t>
<t>The following Header fields SHOULD NOT be included in the
signature: <list
style="symbols">
<t>Return-Path</t>
<t>Received</t>
<t>Comments, Keywords</t>
<t>Bcc, Resent-Bcc</t>
<t>DOSETA&nbhy;Signature</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section
title="Signature Verification {rfc4871bis-02 6.1.3, subset}">
<t>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. <list
style="hanging">
<t
hangText="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 <xref
target="textlength"/>. 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.</t>
</list></t>
</section>
</section>
<section
title="Relationship between SDID and AUID {rfc4871bis-02 3.9}">
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
</section>
<section
anchor="keydata"
title="Stored Key Data {rfc4871bis-02 3.6.1, subset}">
<t>This section defines additions to the DOSETA Library,
concerning stored key data. <list>
<t><list
style="hanging">
<t
hangText="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. <list>
<t><figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text]
["*" [dot-atom-text] ]]]></artwork>
</figure></t>
</list>
</t>
<t
hangText="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. <cref>errata 1381</cref> Unrecognized
hash algorithms MUST be ignored. </t>
<t>
<list>
<t>
<figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[
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]]></artwork>
</figure>
</t>
</list>
</t>
<t
anchor="svctypesseq"
hangText="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. <cref>errata 1381,
1382</cref> Unrecognized service types MUST be
ignored. Currently defined service types are as
follows: </t>
<t><list
style="hanging">
<t
hangText="* ">matches all service types</t>
<t
hangText="email ">electronic mail (not
necessarily limited to SMTP)</t>
</list> 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.</t>
<t>
<list>
<t>
<figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[
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]]></artwork>
</figure>
</t>
</list>
</t>
<t
anchor="svcflagteq"
hangText="t= ">Flags, represented as a
colon-separated list of names (plain-text;
OPTIONAL, default is no flags set). <cref>errata
1381</cref> Unrecognized flags MUST be ignored.
The defined flags are as follows: <list
style="hanging">
<t
hangText="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.</t>
<t
hangText="s ">Any DOSETA&nbhy;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.</t>
</list>
</t>
<t>
<list>
<t>
<figure>
<preamble>ABNF:</preamble>
<artwork type="abnf"><![CDATA[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]]></artwork>
</figure>
</t>
</list>
</t>
</list></t>
</list>
</t>
</section>
</section>
<section
title="Considerations">
<section
anchor="security"
title="Security Considerations {rfc4871bis-02 8, subset}">
<section
title="Misuse of Content Length Limits ("l=" Tag)">
<t> Content length limits (in the form of the "l=" tag) are
subject to several potential attacks.</t>
<section
title="Addition of New MIME Parts to Multipart/*">
<t>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.</t>
<t>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.</t>
</section>
<section
title="Addition of new HTML content to existing content">
<t>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. </t>
<t>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: <figure>
<artwork><![CDATA[<div style="position: relative; bottom: 350px; z-index: 2;">
<img src="http://www.ietf.org/images/ietflogo2e.gif"
width=578 height=370> </div>]]>
</artwork>
</figure></t>
</section>
</section>
</section>
<section
anchor="iana"
title="IANA Considerations {rfc4871bis-02 7, subset}">
<t>DKIM uses registries now assigned to DOSETA <xref
target="I-D.Doseta"/>. 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.</t>
<section
title="DKIM&nbhy;Signature Tag Specifications">
<t>These values are added to the registry that is now defined
in <xref
target="I-D.Doseta"/>:</t>
<texttable
anchor="sigtagreg"
title="DKIM&nbhy;Signature Tag Specification Registry Initial Values">
<ttcol
align="center">TYPE</ttcol>
<ttcol
align="left">REFERENCE</ttcol>
<c> i </c>
<c> (this document, <xref
target="signeddatastruct"/>) </c>
<c> l </c>
<c> (this document, <xref
target="signeddatastruct"/>) </c>
<c> z </c>
<c> (this document, <xref
target="signeddatastruct"/>) </c>
</texttable>
</section>
<section
anchor="dnstxt"
title="_domainkey DNS TXT Record Tag Specifications">
<t>These values are added to the registry that is now defined
in <xref
target="I-D.Doseta"/>:</t>
<texttable
title="DKIT _domainkey DNS TXT Record Tag Specification Registry
Initial Values">
<ttcol
align="center">TYPE</ttcol>
<ttcol
align="left">REFERENCE</ttcol>
<c> g </c>
<c> (this document, <xref
target="keydata"/>) </c>
<c> h </c>
<c> (this document, <xref
target="keydata"/>) </c>
<c> s </c>
<c> (this document, <xref
target="keydata"/>) </c>
<c> t </c>
<c> (this document, <xref
target="keydata"/>) </c>
</texttable>
</section>
<section
title="DKIM Service Types Registry">
<t>The "s=" <key-s-tag> tag (specified in <xref
target="keydata"/>) provides for a list of service types
to which this selector might apply.</t>
<t>IANA has established the DKIM Service Types Registry for
service types.</t>
<t>The initial entries in the registry comprise:</t>
<texttable
title="DKIM Service Types Registry Initial Values">
<ttcol
align="center">TYPE</ttcol>
<ttcol
align="left">REFERENCE</ttcol>
<c> email </c>
<c> (this document, <xref
target="keydata"/>, "s=") </c>
<c> * </c>
<c> (this document, , <xref
target="keydata"/>, "s=") </c>
</texttable>
</section>
<section
anchor="svcflags"
title="DKIM Service Flags Registry">
<t>The "t=" <key-t-tag> tag (specified in <xref
target="keydata"/>) provides for a list of flags to
modify interpretation of the selector.</t>
<t>IANA has established the DKIM Selector Flags Registry for
additional flags.</t>
<t>The initial entries in the registry comprise:</t>
<texttable
title="DKIM Service Flags Registry Initial Values">
<ttcol
align="center">TYPE</ttcol>
<ttcol
align="left">REFERENCE</ttcol>
<c> y </c>
<c> (this document, <xref
target="keydata"/>, "t=") </c>
<c> s </c>
<c> (this document, <xref
target="keydata"/>, "t=") </c>
</texttable>
</section>
<section
title="DKIM&nbhy;Signature Header Field">
<t>IANA has added DKIM&nbhy;Signature to the "Permanent Message
Header Fields" registry (see <xref
target="RFC3864"/>) for the "mail" protocol, using this
document as the reference.</t>
</section>
</section>
</section>
</middle>
<back>
<references
title="Normative References">
<reference
anchor="I-D.Doseta">
<front>
<title
abbrev="DOSETA">DomainKeys Security Tagging (DOSETA)</title>
<author
fullname="D. Crocker"
initials="D."
role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
<uri>http://bbiw.net</uri>
</address>
</author>
<author
fullname="Tony Hansen"
initials="T."
role="editor"
surname="Hansen">
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave. South</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>tony+dkimov@maillennium.att.com</email>
</address>
</author>
<author
fullname="M. Kucherawy"
initials="M."
role="editor"
surname="Kucherawy">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>USA</country>
</postal>
<email>msk@cloudmark.com</email>
</address>
</author>
<date
year="2010"/>
</front>
<seriesInfo
name="I-D"
value="draft-ietf-DKIM-DOSETA"/>
</reference>
<reference
anchor="RFC1034">
<front>
<title>DOMAIN NAMES - CONCEPTS AND FACILITIES</title>
<author
fullname="P. Mockapetris"
initials="P."
surname="Mockapetris"/>
<date
month="November"
year="1987"/>
</front>
<seriesInfo
name="RFC"
value="1034"/>
</reference>
<reference
anchor="RFC2047">
<front>
<title
abbrev="Message Header Extensions">MIME (Multipurpose
Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Content</title>
<author
fullname="Keith Moore"
initials="K."
surname="Moore">
<organization>University of Tennessee</organization>
<address>
<postal>
<street>107 Ayres Hall</street>
<street>Knoxville TN 37996-1301</street>
</postal>
<email>moore@cs.utk.edu</email>
</address>
</author>
<date
month="November"
year="1996"/>
<area>Applications</area>
<keyword>Amercian Standard Code for Information
Interchange</keyword>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<abstract>
<t> STD 11, RFC 822, defines a message representation
protocol specifying considerable detail about US-ASCII
message headers, and leaves the Content, as flat US-ASCII
text. This set of documents, collectively called the
Multipurpose Internet Mail Extensions, or MIME, redefines
the format of messages to allow for <list>
<t> (1) textual message bodies in character sets other
than US-ASCII, </t>
<t> (2) an extensible set of different formats for
non-textual message bodies, </t>
<t> (3) multi-part message bodies, and </t>
<t> (4) textual header information in character sets
other than US-ASCII. </t>
</list>
</t>
<t> These documents are based on earlier work documented in
RFC 934, STD 11, and RFC 1049, but extends and revises
them. Because RFC 822 said so little about message
bodies, these documents are largely orthogonal to (rather
than a revision of) RFC 822. </t>
<t> This particular document is the third document in the
series. It describes extensions to RFC 822 to allow
non-US-ASCII text data in Internet mail header fields.
Other documents in this series include: <list
style="symbols">
<t>RFC 2045, which specifies the various headers used
to describe the structure of MIME messages. </t>
<t>RFC 2046, which defines the general structure of
the MIME media typing system and defines an initial
set of media types, </t>
<t>RFC 2048, which specifies various IANA registration
procedures for MIME-related facilities, and </t>
<t>RFC 2049, which describes MIME conformance criteria
and provides some illustrative examples of MIME
message formats, acknowledgements, and the
bibliography. </t>
</list>
</t>
<t> These documents are revisions of RFCs 1521, 1522, and
1590, which themselves were revisions of RFCs 1341 and
1342. An appendix in RFC 2049 describes differences and
changes from previous versions. </t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="2047"/>
<format
octets="33262"
target="http://www.rfc-editor.org/rfc/rfc2047.txt"
type="TXT"/>
<format
octets="52141"
target="http://xml.resource.org/public/rfc/html/rfc2047.html"
type="HTML"/>
<format
octets="39330"
target="http://xml.resource.org/public/rfc/xml/rfc2047.xml"
type="XML"/>
</reference>
<reference
anchor="RFC2119">
<front>
<title
abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author
fullname="Scott Bradner"
initials="S."
surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date
month="March"
year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t> In many standards track documents several words are used
to signify the requirements in the specification. These
words are often capitalized. This document defines these
words as they should be interpreted in IETF documents.
Authors who follow these guidelines should incorporate
this phrase near the beginning of their document: <list>
<t> 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 RFC
2119. </t>
</list>
</t>
<t> Note that the force of these words is modified by the
requirement level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo
name="BCP"
value="14"/>
<seriesInfo
name="RFC"
value="2119"/>
<format
octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt"
type="TXT"/>
<format
octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML"/>
<format
octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML"/>
</reference>
<reference
anchor="RFC5890">
<front>
<title>Internationalizing Domain Names in Applications (IDNA):
Definitions and Document Framework</title>
<author
fullname="J. Klensin"
initials="J."
surname="Klensin">
<organization/>
</author>
<date
month="August"
year="2010"/>
<abstract>
<t>Until now, there has been no standard method for domain
names to use characters outside the ASCII repertoire.
This document defines internationalized domain names
(IDNs) and a mechanism called Internationalizing Domain
Names in Applications (IDNA) for handling them in a
standard fashion. IDNs use characters drawn from a large
repertoire (Unicode), but IDNA allows the non-ASCII
characters to be represented using only the ASCII
characters already allowed in so-called host names today.
This backward-compatible representation is required in
existing protocols like DNS, so that IDNs can be
introduced with no changes to the existing
infrastructure. IDNA is only meant for processing domain
names, not free text. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="5890"/>
<format
octets="51943"
target="http://www.rfc-editor.org/rfc/rfc5890.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC5234">
<front>
<title
abbrev="ABNF">Augmented BNF for Syntax Specifications:
ABNF</title>
<author
fullname="Dave Crocker"
initials="D."
role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author
fullname="Paul Overell"
initials="P."
surname="Overell">
<organization>THUS plc.</organization>
<address>
<postal>
<street>1/2 Berkeley Square, </street>
<street>99 Berkeley Street</street>
<city>Glasgow</city>
<code>G3 7HR</code>
<country>UK</country>
</postal>
<email>paul.overell@thus.net</email>
</address>
</author>
<date
month="January"
year="2008"/>
<keyword>ABNF</keyword>
<keyword>Augmented</keyword>
<keyword>Backus-Naur</keyword>
<keyword>Form</keyword>
<keyword>electronic</keyword>
<keyword>mail</keyword>
<abstract>
<t>Internet technical specifications often need to define a
formal syntax. Over the years, a modified version of
Backus-Naur Form (BNF), called Augmented BNF (ABNF), has
been popular among many Internet specifications. The
current specification documents ABNF. It balances
compactness and simplicity, with reasonable
representational power. The differences between standard
BNF and ABNF involve naming rules, repetition,
alternatives, order-independence, and value ranges. This
specification also supplies additional rule definitions
and encoding for a core lexical analyzer of the type
common to several Internet specifications. </t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4234"/>
<format
octets="26351"
target="http://www.rfc-editor.org/rfc/rfc4234.txt"
type="TXT"/>
<format
octets="52334"
target="http://xml.resource.org/public/rfc/html/rfc4234.html"
type="HTML"/>
<format
octets="37285"
target="http://xml.resource.org/public/rfc/xml/rfc4234.xml"
type="XML"/>
</reference>
<reference
anchor="RFC5322">
<front>
<title>Internet Message Format</title>
<author
fullname="P. Resnick"
initials="P."
surname="Resnick">
<organization/>
</author>
<date
month="October"
year="2008"/>
<abstract>
<t>This document specifies a syntax for text messages that
are sent between computer users, within the framework of
"electronic mail" messages. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="5322"/>
<format
octets="110695"
target="http://www.rfc-editor.org/rfc/rfc5322.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC5672">
<front>
<title>RFC 4871 DomainKeys Identified Mail (DKIM) Signatures:
Update</title>
<author
fullname="D. Crocker"
initials="D."
role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
<uri>http://bbiw.net</uri>
</address>
</author>
<date
month="August"
year="2009"/>
<workgroup>DKIM</workgroup>
</front>
<seriesInfo
name="RFC"
value="5672"/>
</reference>
</references>
<references
title="Informative References">
<reference
anchor="RFC1847">
<front>
<title
abbrev="Security Multiparts">Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted</title>
<author
fullname="Jim Galvin"
initials="J."
surname="Galvin">
<organization>Trusted Information Systems</organization>
<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>
<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>galvin@tis.com</email>
</address>
</author>
<author
fullname="Sandy Murphy"
initials="S."
surname="Murphy">
<organization>Trusted Information Systems</organization>
<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>
<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>sandy@tis.com</email>
</address>
</author>
<author
fullname="Steve Crocker"
initials="S."
surname="Crocker">
<organization>CyberCash, Inc.</organization>
<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>
<phone>+1 703 620 1222</phone>
<facsimile>+1 703 391 2651</facsimile>
<email>crocker@cybercash.com</email>
</address>
</author>
<author
fullname="Ned Freed"
initials="N."
surname="Freed">
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<date
month="October"
year="1995"/>
<abstract>
<t>This document defines a framework within which security
services may be applied to MIME body parts. MIME, an
acronym for "Multipurpose Internet Mail Extensions",
defines the format of the contents of Internet mail
messages and provides for multi-part textual and
non-textual message bodies. The new content types are
subtypes of multipart: signed and encrypted. Each will
contain two body parts: one for the protected data and
one for the control information necessary to remove the
protection. The type and contents of the control
information body parts are determined by the value of the
protocol parameter of the enclosing multipart/signed
or multipart/encrypted content type, which is
required to be present.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="1847"/>
<format
octets="23679"
target="http://www.rfc-editor.org/rfc/rfc1847.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC3864">
<front>
<title>Registration Procedures for Message Header
Fields</title>
<author
fullname="G. Klyne"
initials="G."
surname="Klyne">
<organization/>
</author>
<author
fullname="M. Nottingham"
initials="M."
surname="Nottingham">
<organization/>
</author>
<author
fullname="J. Mogul"
initials="J."
surname="Mogul">
<organization/>
</author>
<date
month="September"
year="2004"/>
<abstract>
<t>This specification defines registration procedures for
the message header fields used by Internet mail, HTTP,
Netnews and other applications. This document specifies
an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front>
<seriesInfo
name="BCP"
value="90"/>
<seriesInfo
name="RFC"
value="3864"/>
<format
octets="36231"
target="http://www.rfc-editor.org/rfc/rfc3864.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC4880">
<front>
<title>OpenPGP Message Format</title>
<author
fullname="Jon Callas"
initials="J."
surname="Callas">
<organization>Network Associates, Inc.</organization>
<address>
<postal>
<street>3965 Freedom Circle</street>
<street>Santa Clara</street>
<street>CA 95054</street>
<country>USA</country>
</postal>
<phone>+1 408-346-5860</phone>
<email>jon@pgp.com</email>
</address>
</author>
<author
fullname="Lutz Donnerhacke"
initials="L."
surname="Donnerhacke">
<organization>IKS GmbH</organization>
<address>
<postal>
<street>Wildenbruchstr. 15</street>
<street>07745 Jena</street>
<country>Germany</country>
</postal>
<phone>+49-3641-675642</phone>
<email>lutz@iks-jena.de</email>
</address>
</author>
<author
fullname="Hal Finney"
initials="H."
surname="Finney">
<organization>Network Associates, Inc.</organization>
<address>
<postal>
<street>3965 Freedom Circle</street>
<street>Santa Clara</street>
<street>CA 95054</street>
<country>USA</country>
</postal>
<email>hal@pgp.com</email>
</address>
</author>
<author
fullname="Rodney Thayer"
initials="R."
surname="Thayer">
<organization>EIS Corporation</organization>
<address>
<postal>
<street>Clearwater</street>
<street>FL 33767</street>
<country>USA</country>
</postal>
<email>rodney@unitran.com</email>
</address>
</author>
<date
month="November"
year="2007"/>
<area>Security</area>
<keyword>pretty good privacy</keyword>
<keyword>PGP</keyword>
<keyword>security</keyword>
<abstract>
<t> This document defines many tag values, yet it
doesn't describe a mechanism for adding new tags
(for new features). Traditionally the Internet Assigned
Numbers Authority (IANA) handles the allocation of new
values for future expansion and RFCs usually define the
procedure to be used by the IANA. However, there are
subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features
which result in a significant reduction in over all
security. Therefore, this document does not define an
extension procedure. Instead requests to define new tag
values (say for new encryption algorithms for example)
should be forwarded to the IESG Security Area Directors
for consideration or forwarding to the appropriate IETF
Working Group for consideration. </t>
<t> This document is maintained in order to publish all
necessary information needed to develop interoperable
applications based on the OpenPGP format. It is not a
step-by-step cookbook for writing an application. It
describes only the format and methods needed to read,
check, generate, and write conforming packets crossing
any network. It does not deal with storage and
implementation questions. It does, however, discuss
implementation issues necessary to avoid security flaws. </t>
<t> Open-PGP software uses a combination of strong
public-key and symmetric cryptography to provide security
services for electronic communications and data storage.
These services include confidentiality, key management,
authentication, and digital signatures. This document
specifies the message formats used in OpenPGP. </t>
</abstract>
<note
title="IESG Note">
<t> This document defines many tag values, yet it
doesn't describe a mechanism for adding new tags
(for new features). Traditionally the Internet Assigned
Numbers Authority (IANA) handles the allocation of new
values for future expansion and RFCs usually define the
procedure to be used by the IANA. However, there are
subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features
which result in a significant reduction in over all
security. Therefore, this document does not define an
extension procedure. Instead requests to define new tag
values (say for new encryption algorithms for example)
should be forwarded to the IESG Security Area Directors
for consideration or forwarding to the appropriate IETF
Working Group for consideration. </t>
</note>
</front>
<seriesInfo
name="RFC"
value="4880"/>
<format
octets="141371"
target="http://www.rfc-editor.org/rfc/rfc4880.txt"
type="TXT"/>
<format
octets="157503"
target="http://xml.resource.org/public/rfc/html/rfc4880.html"
type="HTML"/>
<format
octets="137322"
target="http://xml.resource.org/public/rfc/xml/rfc4880.xml"
type="XML"/>
</reference>
<reference
anchor="RFC4870">
<front>
<title>Domain-Based Email Authentication Using Public Keys
Advertised in the DNS (DomainKeys)</title>
<author
fullname="M. Delany"
initials="M."
surname="Delany">
<organization/>
</author>
<date
month="May"
year="2007"/>
<abstract>
<t>"DomainKeys" creates a domain-level authentication
framework for email by using public key technology and
the DNS to prove the provenance and contents of an
email.</t><t> This document defines a framework for
digitally signing email on a per-domain basis. The
ultimate goal of this framework is to unequivocally prove
and protect identity while retaining the semantics of
Internet email as it is known today.</t><t> Proof
and protection of email identity may assist in the global
control of "spam" and "phishing". This memo defines a
Historic Document for the Internet community.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4870"/>
<format
octets="87378"
target="http://www.rfc-editor.org/rfc/rfc4870.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC4871">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author
fullname="E. Allman"
initials="E."
surname="Allman">
<organization/>
</author>
<author
fullname="J. Callas"
initials="J."
surname="Callas">
<organization/>
</author>
<author
fullname="M. Delany"
initials="M."
surname="Delany">
<organization/>
</author>
<author
fullname="M. Libbey"
initials="M."
surname="Libbey">
<organization/>
</author>
<author
fullname="J. Fenton"
initials="J."
surname="Fenton">
<organization/>
</author>
<author
fullname="M. Thomas"
initials="M."
surname="Thomas">
<organization/>
</author>
<date
month="May"
year="2007"/>
<abstract>
<t>DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key
cryptography and key server technology to permit
verification of the source and contents of messages by
either Mail Transfer Agents (MTAs) or Mail User Agents
(MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message,
thus protecting message signer identity and the integrity
of the messages they convey while retaining the
functionality of Internet email as it is known today.
Protection of email identity may assist in the global
control of "spam" and "phishing". [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4871"/>
<format
octets="166054"
target="http://www.rfc-editor.org/rfc/rfc4871.txt"
type="TXT"/>
</reference>
<reference
anchor="RFC5585">
<front>
<title>DomainKeys Identified Mail (DKIM) Service
Overview</title>
<author
fullname="T. Hansen"
initials="T."
surname="Hansen"/>
<author
fullname="D. Crocker"
initials="D."
surname="Crocker"/>
<author
fullname="P. Hallam-Baker"
initials="P."
surname="Hallam-Baker"/>
<date
month="June"
year="2009"/>
</front>
</reference>
<reference
anchor="RFC5863">
<front>
<title>DomainKeys Identified Mail (DKIM): Development,
Deployment, and Operations</title>
<author
fullname="T. Hansen"
initials="T."
surname="Hansen"/>
<author
fullname="E. Siegel"
initials="H."
surname="Siegel"/>
<author
fullname="P. Hallam-Baker"
initials="P."
surname="Hallam-Baker"/>
<author
fullname="D. Crocker"
initials="D."
surname="Crocker"/>
<date
month="May"
year="2010"/>
</front>
</reference>
</references>
<section
title="MUA Considerations {rfc4871bis-02 D}">
<t>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.</t>
<t>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.</t>
</section>
<section
title="End-to-End Scenario Example {rfc4871bis-02 A}">
<t>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 <xref
target="I-D.Doseta"/>, "Creating a Public Key".</t>
<section
title="The User Composes an Email">
<t>
<figure
anchor="usercompose"
title="The User Composes an Email">
<artwork><![CDATA[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.]]></artwork>
</figure>
</t>
</section>
<section
title="The Email is Signed">
<t>
<figure
align="left"
title="The Email is Signed">
<preamble>This email is signed by the example.com outbound
email server and now looks like this:</preamble>
<artwork><![CDATA[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.]]></artwork>
</figure>
</t>
<t>The signing email server requires access to the private key
associated with the "brisbane" selector to generate this
signature.</t>
</section>
<section
title="The Email Signature is Verified">
<t>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&nbhy;Signature header field to form the DNS
DOSETA query for: brisbane._domainkey.example.com</t>
<t>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: <figure
align="left"
title="Successful verification">
<artwork><![CDATA[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.]]></artwork>
</figure></t>
</section>
</section>
<section
title="Types of Use {rfc4871bis-02 B}">
<t> DOSETA signing and validating can be used in different ways, for
different operational scenarios. This Appendix discusses some
common examples. <list
style="hanging">
<t
hangText="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.</t>
</list></t>
<section
title="Alternate Submission Scenarios">
<t>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.</t>
<section
title="Delegated Business Functions">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section
title="PDAs and Similar Devices">
<t>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.</t>
</section>
<section
title="Roaming Users">
<t>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.</t>
<t>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.</t>
</section>
<section
title="Independent (Kiosk) Message Submission">
<t>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.</t>
<t>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.</t>
<t>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.)</t>
</section>
</section>
<section
title="Alternate Delivery Scenarios">
<t>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.</t>
<section
title="Affinity Addresses">
<t>"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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section
title="Simple Address Aliasing (.forward)">
<t>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.</t>
</section>
<section
title="Mailing Lists and Re-Posters">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="RFC5322"/>. The forwarder applies a new
DOSETA&nbhy;Signature header field with the signature,
public key, and related information of the forwarder.</t>
</section>
</section>
</section>
<section
title="Acknowledgements">
<t>The previous IETF version of DKIM <xref
target="RFC4871"/> was edited by: Eric Allman, Jon Callas, Mark
Delany, Miles Libbey, Jim Fenton and Michael Thomas.</t>
<t>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.</t>
<t> The earlier DomainKeys was a primary source from which DKIM was
derived. Further information about DomainKeys is at <xref
target="RFC4870"/>.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:57:12 |