RFC 4871 DomainKeys Identified Mail (DKIM)
Signatures -- ErrataBrandenburg InternetWorking+1.408.246.8253dcrocker@bbiw.net
Security
DKIMThis documents and resolves errata for RFC 4871, DomainKeys
Identified Mail (DKIM) Signatures. Specifically the document clarifies
the nature, roles and relationship of the two DKIM identifier tag
values that are candidates for payload delivery to a receiving
processing module. This Errata entry has been developed and approved
by the IETF's DKIM working group.Dave Crockerdcrocker@bbiw.netTechnical
About the purpose for DKIM, states: The ultimate goal of this framework is to permit a signing
domain to assert responsibility for a message, thus protecting
message signer identity... Hence, DKIM has a signer that produces a signed message, a
verifier that confirms the signature and an assessor that consumes the
validated signing domain. So the simple purpose of DKIM is to
communicate an identifier to a receive-side assessor module. The
identifier is in the form of a domain name that refers to a
responsible identity. For DKIM to be interoperable and useful, signer
and assessor must share the same understanding of the details about
the identifier.However the RFC5871 specification defines two, potentially different
identifiers that are carried in the DKIM-Signature: header field, d=
and i=. Either might be delivered to a receiving processing module
that consumes validated payload. The DKIM specification fails to
clearly define what is "payload" to be delivered to a consuming
module, versus what is internal and merely in support of achieving
payload delivery. This currently leaves signers and assessors with the potential for
having differing -- and therefore non-interoperable -- interpretations
of how DKIM operates.This erratum resolves this confusion. It defines new labels for the
two values, clarifies their nature, and specifies and their
relationship. This Errata Entry has been developed and
approved by the IETF's DKIM working group. For more information
about DKIM and its IETF working group, see:
<http://dkim.org>.The ultimate goal of this framework is to permit a signing domain
to assert responsibility for a message,The ultimate goal of this framework is to permit a person, role
or organization that owns the signing domain to assert
responsibility for a message,...permitting a signing domain to claim responsibility permitting a person, role or organization that owns the signing
domain to claim responsibility(None. Additional text.)A person, role or organization. In the context of DKIM, examples
include author, author's organization, an ISP along the handling
path, an independent trust assessment service, and a mailing list
operator.(None. Additional text.)A label that refers to an identity.(None. Additional text.)A single, opaque value that is the mandatory payload output of
DKIM and which refers to the identity claiming responsibility for
the introduction of a message into the mail stream. It is
specified in section 3.5. (None. Additional text.)A single, opaque value that identifies the agent or user on
behalf of whom the SDID has taken responsibility. It is specified
in section 3.5.(None. Additional text.)The name of the module that consumes DKIM's primary payload, the
responsible Signing Domain Identifier (SDID). It can optionally
consume the Agent or User Identifier (AUID) value, if provided to the
module.Original Text: Corrected Text: d= Specifies the SDID claiming responsibility for an
introduction of a message into the mail stream (plain-text;
REQUIRED). This is the domain that will be queried for the
public key. The SDID MUST correspond to a valid DNS name under
which the DKIM key record is published. The conventions and
semantics used by a signer to create and use a specific SDID
are outside the scope of the DKIM Signing specification, as is
any use of those conventions and semantics. When presented
with a signature that does not meet these requirements,
verifiers MUST consider the signature invalid.Internationalized domain names MUST be encoded as described
in [RFC3490].ABNF:
Original Text: Corrected Text: i= The Agent or User Identifier (AUID) on behalf of which the SDID
is taking responsibility (dkim-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 [RFC3490] using the "ToASCII"
function.ABNF: 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 that does not contain
the user's 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 DKIM 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 finer grained, stable identifier
than the SDID. INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may 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.Original Text: Corrected Text: ...for example, a key record for the domain example.com can be
used to verify messages where the AUID ("i=" tag of the signature)
is sub.example.com, or even sub1.sub2.example.com. In order to
limit the capability of such keys when this is not intended, the
"s" flag MAY be set in the "t=" tag of the key record, to
constrain the validity of the domain of the AUID. If the
referenced key record contains the "s" flag as part of the "t="
tag, the domain of the AUID ("i=" flag) MUST be the same as that
of the SDID (d=) domain. If this flag is absent, the domain of the
AUID MUST be the same as, or a subdomain of, the SDID. (None. This is an addition.)DKIM'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. DKIM MAY
optionally provide a single responsible Agent or User Identifier
(AUID). Hence, DKIM delivers to receive-side Identity Assessors
responsible Identifiers that are opaque to the assessor. Their
sub-structures and particular semantics are not publicly defined
and, therefore, cannot be assumed by an Identity Assessor. A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the User Agent 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 DKIM'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. INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match the identity in any message header
fields. This is considered to be an assessor policy issue.
Constraints between the value of the SDID or AUID and other
identities in other header fields 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
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 these options 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.Original Text: Corrected Text:It is beyond the scope of this specification to describe what
actions an Identity Assessor can make, but mail carrying a
validated SDID presents an opportunity to an Identity Assessor
that unauthenticated email does not. Specifically, an
authenticated email creates a predictable identifier by which
other decisions can reliably be managed, such as trust and
reputation.Original Text: Corrected Text: Once the signature has been verified, that information MUST be
conveyed to the Identity Assessor (such as an explicit
allow/whitelist and reputation system) and/or to the end user. If
the SDID is not the same as the address in the From: header field,
the mail system SHOULD take pains to ensure that the actual SDID
is clear to the reader. The tendency is to have the MUA
highlight the address associated with this signing identity in
some way, in an attempt to show the user the address from which
the mail was sent. 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.This Errata document clarifies core details about DKIM's payload. As
such it affects interoperability, semantic characterization, and the
expectations for the identifiers carried with a DKIM signature.
Clarification of these details is likely to limit misinterpretation of
DKIM's semantics. Since DKIM is fundamentally a security protocol,
this should improve its security characteristics.DomainKeys Identified Mail (DKIM) SignaturesSendmail, Inc.PGP CorporationYahoo! IncYahoo! Inc Cisco Systems, Inc. Cisco Systems, Inc.This document was initially formulated by an ad hoc design team,
comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray
Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel,
Wietse Venema. It was then submitted to the DKIM working group for
revision and approval.