draft-ietf-dkim-rfc4871bis-00.txt   draft-ietf-dkim-rfc4871bis-01.txt 
DKIM D. Crocker DKIM D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871 (if approved) T. Hansen Obsoletes: 4871 (if approved) T. Hansen, Ed.
Intended status: Standards Track AT&T Laboratories Intended status: Standards Track AT&T Laboratories
Expires: February 16, 2011 M. Kucherawy Expires: March 31, 2011 M. Kucherawy, Ed.
Cloudmark Cloudmark
August 15, 2010 September 27, 2010
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-00 draft-ietf-dkim-rfc4871bis-01
Abstract Abstract
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the responsibility for a message by associating the domain with the
message. This can be an author's organization, an operational relay message. This can be an author's organization, an operational relay
or one of their agents. DKIM separates the question of the identity or one of their agents. DKIM separates the question of the identity
of the signer of the message from the purported author of the of the signer of the message from the purported author of the
message. Assertion of responsibility is validated through a message. Assertion of responsibility is validated through a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 16, 2011. This Internet-Draft will expire on March 31, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7
2.7. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8
2.8. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 10 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8
2.10. Agent or User Identifier (AUID) . . . . . . . . . . . . . 10 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9
2.11. Identity Assessor . . . . . . . . . . . . . . . . . . . . 10 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19
3.6. Key Management and Representation . . . . . . . . . . . . 28 3.6. Key Management and Representation . . . . . . . . . . . . 28
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35 3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35
skipping to change at page 7, line 27 skipping to change at page 7, line 27
leaves the administrative domain of the signer. leaves the administrative domain of the signer.
2.2. Verifiers 2.2. Verifiers
Elements in the mail system that verify signatures are referred to as Elements in the mail system that verify signatures are referred to as
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.
In most cases it is expected that verifiers will be close to an end In most cases it is expected that verifiers will be close to an end
user (reader) of the message or some consuming agent such as a user (reader) of the message or some consuming agent such as a
mailing list exploder. mailing list exploder.
2.3. Whitespace 2.3. Identity
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.
2.4. Identifier
A label that refers to an identity.
2.5. Signing Domain Identifier (SDID)
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.5.
2.6. 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 DKIM processing, the domain name portion of the AUID has
only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM. It is specified in
Section 3.5 .
2.7. Identity Assessor
A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier. Other DKIM
(and non-DKIM) 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.8. Whitespace
There are three forms of whitespace: There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]). (formal definition in [RFC4234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]). definition in [RFC4234]).
o FWS is folding whitespace. It allows multiple lines separated by o FWS is folding whitespace. It allows multiple lines separated by
skipping to change at page 7, line 49 skipping to change at page 8, line 41
The formal ABNF for these are (WSP and LWSP are given for information The formal ABNF for these are (WSP and LWSP are given for information
only): only):
WSP = SP / HTAB WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP) LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC2822] except for The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS. the exclusion of obs-FWS.
2.4. Common ABNF Tokens 2.9. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document: The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ] [ [FWS] "=" [ [FWS] "=" ] ]
2.5. Imported ABNF Tokens 2.10. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive. RFCs should be considered definitive.
The following tokens are imported from [RFC2821]: The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted strings) o "Local-part" (implementation warning: this permits quoted strings)
o "sub-domain" o "sub-domain"
skipping to change at page 8, line 41 skipping to change at page 9, line 36
o "hex-octet" (a quoted-printable encoded octet) o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not
obey the rules of [RFC4234] and must be interpreted accordingly, obey the rules of [RFC4234] and must be interpreted accordingly,
particularly as regards case folding. particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc. etc.
2.6. DKIM-Quoted-Printable 2.11. DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing "0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values > characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including (";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
skipping to change at page 9, line 38 skipping to change at page 10, line 35
the case here. the case here.
3. The "soft line break" syntax ("=" as the last non-whitespace 3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply. character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be 4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded requirements depending on the context in which the encoded
text is being used). text is being used).
2.7. Identity
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.
2.8. Identifier
A label that refers to an identity.
2.9. Signing Domain Identifier (SDID)
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.5.
2.10. 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 DKIM processing, the domain name portion of the AUID has
only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM. It is specified in
Section 3.5 .
2.11. Identity Assessor
A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier. Other DKIM
(and non-DKIM) 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.
3. Protocol Elements 3. Protocol Elements
Protocol Elements are conceptual parts of the protocol that are not Protocol Elements are conceptual parts of the protocol that are not
specific to either signers or verifiers. The protocol descriptions specific to either signers or verifiers. The protocol descriptions
for signers and verifiers are described in later sections (Signer for signers and verifiers are described in later sections (Signer
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This
section must be read in the context of those sections. section must be read in the context of those sections.
3.1. Selectors 3.1. Selectors
To support multiple concurrent public keys per signing domain, the To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using "selectors". For example, key namespace is subdivided using "selectors". For example,
selectors might indicate the names of office locations (e.g., selectors might indicate the names of office locations (e.g.,
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date
(e.g., "january2005", "february2005", etc.), or even the individual (e.g., "january2005", "february2005", etc.), or even an individual
user. user.
Selectors are needed to support some important use cases. For Selectors are needed to support some important use cases. For
example: example:
o Domains that want to delegate signing capability for a specific o Domains that want to delegate signing capability for a specific
address for a given duration to a partner, such as an advertising address for a given duration to a partner, such as an advertising
provider or other outsourced function. provider or other outsourced function.
o Domains that want to allow frequent travelers to send messages o Domains that want to allow frequent travelers to send messages
skipping to change at page 12, line 15 skipping to change at page 12, line 19
the transition period. However, a signing domain could elect to the transition period. However, a signing domain could elect to
revoke the key (but maintain the key record) for a further period. revoke the key (but maintain the key record) for a further period.
There is no defined semantic difference between a revoked key and There is no defined semantic difference between a revoked key and
a removed key. a removed key.
While some domains may wish to make selector values well known, While some domains may wish to make selector values well known,
others will want to take care not to allocate selector names in a way others will want to take care not to allocate selector names in a way
that allows harvesting of data by outside parties. For example, if that allows harvesting of data by outside parties. For example, if
per-user keys are issued, the domain owner will need to make the per-user keys are issued, the domain owner will need to make the
decision as to whether to associate this selector directly with the decision as to whether to associate this selector directly with the
user name, or make it some unassociated random value, such as a name of a registered end-user, or make it some unassociated random
fingerprint of the public key. value, such as a fingerprint of the public key.
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key
(for example, changing the key associated with a user's name) (for example, changing the key associated with a user's name)
makes it impossible to tell the difference between a message that makes it impossible to tell the difference between a message that
didn't verify because the key is no longer valid versus a message didn't verify because the key is no longer valid versus a message
that is actually forged. For this reason, signers are ill-advised that is actually forged. For this reason, signers are ill-advised
to reuse selectors for new keys. A better strategy is to assign to reuse selectors for new keys. A better strategy is to assign
new keys to new selectors. new keys to new selectors.
3.2. Tag=Value Lists 3.2. Tag=Value Lists
skipping to change at page 20, line 22 skipping to change at page 20, line 22
string. Unknown tags in the DKIM-Signature header field MUST be string. Unknown tags in the DKIM-Signature header field MUST be
included in the signature calculation but MUST be otherwise ignored included in the signature calculation but MUST be otherwise ignored
by verifiers. Other DKIM-Signature header fields that are included by verifiers. Other DKIM-Signature header fields that are included
in the signature should be treated as normal header fields; in in the signature should be treated as normal header fields; in
particular, the "b=" tag is not treated specially. particular, the "b=" tag is not treated specially.
The encodings for each field type are listed below. Tags described The encodings for each field type are listed below. Tags described
as qp-section are encoded as described in Section 6.7 of MIME Part as qp-section are encoded as described in Section 6.7 of MIME Part
One [RFC2045], with the additional conversion of semicolon characters One [RFC2045], with the additional conversion of semicolon characters
to "=3B"; intuitively, this is one line of quoted-printable encoded to "=3B"; intuitively, this is one line of quoted-printable encoded
text. The dkim-quoted-printable syntax is defined in Section 2.6. text. The dkim-quoted-printable syntax is defined in Section 2.11.
Tags on the DKIM-Signature header field along with their type and Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Unrecognized tags MUST be requirement status are shown below. Unrecognized tags MUST be
ignored. ignored.
v= Version (MUST be included). This tag defines the version of this v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison on the value "1". Note that verifiers must do a string comparison on
this value; for example, "1" is not the same as "1.0". this value; for example, "1" is not the same as "1.0".
skipping to change at page 22, line 30 skipping to change at page 22, line 30
the DKIM Signing specification, as is any use of those conventions the DKIM Signing specification, as is any use of those conventions
and semantics. When presented with a signature that does not meet and semantics. When presented with a signature that does not meet
these requirements, verifiers MUST consider the signature invalid. these requirements, verifiers MUST consider the signature invalid.
Internationalized domain names MUST be encoded as described in Internationalized domain names MUST be encoded as described in
[RFC3490]. [RFC3490].
ABNF: ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain) ; from domain-name = sub-domain 1*("." sub-domain) ; from
RFC 5321 Domain, but excluding address-literal RFC 5321 Domain, but excluding address-literall
h= Signed header fields (plain-text, but see description; REQUIRED). h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields do fields that do not exist when signed; nonexistent header fields do
not contribute to the signature computation (that is, they are not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF separating colon, the header field value, and any CRLF
skipping to change at page 23, line 43 skipping to change at page 23, line 43
Internationalized domain names MUST be converted using the steps Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function. listed in Section 4 of [RFC3490] using the "ToASCII" function.
ABNF: ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
"@" domain-name "@" domain-name
The AUID is specified as having the same syntax as an email The AUID is specified as having the same syntax as an email
address, but is not required to have the same semantics. Notably, address, but is not required to have the same semantics. Notably,
the domain name is not required to be registered in the DNS -- so 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 it might not resolve in a query -- and the Local-part MAY be drawn
drawn from a namespace that does not contain the user's mailbox. from a namespace unrelated to any mailbox. The details of the
The details of the structure and semantics for the namespace are structure and semantics for the namespace are determined by the
determined by the Signer. Any knowledge or use of those details Signer. Any knowledge or use of those details by verifiers or
by verifiers or assessors is outside the scope of the DKIM Signing assessors is outside the scope of the DKIM Signing specification.
specification. The Signer MAY choose to use the same namespace The Signer MAY choose to use the same namespace for its AUIDs as
for its AUIDs as its users' email addresses or MAY choose other its users' email addresses or MAY choose other means of
means of representing its users. However, the signer SHOULD use representing its users. However, the signer SHOULD use the same
the same AUID for each message intended to be evaluated as being AUID for each message intended to be evaluated as being within the
within the same sphere of responsibility, if it wishes to offer same sphere of responsibility, if it wishes to offer receivers the
receivers the option of using the AUID as a stable identifier that option of using the AUID as a stable identifier that is finer
is finer grained than the SDID. grained than the SDID.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because, in some cases, a signer may not be able to establish a because, in some cases, a signer may not be able to establish a
verified individual identity. In such cases, the signer might verified individual identity. In such cases, the signer might
wish to assert that although it is willing to go as far as 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 signing for the domain, it is unable or unwilling to commit to
an individual user name within their domain. It can do so by an individual user name within their domain. It can do so by
including the domain part but not the Local-part of the including the domain part but not the Local-part of the
identity. identity.
skipping to change at page 27, line 31 skipping to change at page 27, line 31
1*12DIGIT 1*12DIGIT
z= Copied header fields (dkim-quoted-printable, but see description; z= Copied header fields (dkim-quoted-printable, but see description;
OPTIONAL, default is null). A vertical-bar-separated list of OPTIONAL, default is null). A vertical-bar-separated list of
selected header fields present when the message was signed, selected header fields present when the message was signed,
including both the field name and value. It is not required to including both the field name and value. It is not required to
include all header fields present at the time of signing. This include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h=" field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are ("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a copied meta-characters, and any actual vertical bar characters in a
header field must be encoded). Note that all whitespace must be copied header field must be encoded). Note that all whitespace
encoded, including whitespace between the colon and the header must be encoded, including whitespace between the colon and the
field value. After encoding, FWS MAY be added at arbitrary header field value. After encoding, FWS MAY be added at arbitrary
locations in order to avoid excessively long lines; such locations in order to avoid excessively long lines; such
whitespace is NOT part of the value of the header field, and MUST whitespace is NOT part of the value of the header field, and MUST
be removed before decoding. be removed before decoding.
The header fields referenced by the "h=" tag refer to the fields The header fields referenced by the "h=" tag refer to the fields
in the [RFC2822] header of the message, not to any copied fields in the [RFC2822] header of the message, not to any copied fields
in the "z=" tag. Copied header field values are for diagnostic in the "z=" tag. Copied header field values are for diagnostic
use. use.
Header fields with characters requiring conversion (perhaps from Header fields with characters requiring conversion (perhaps from
skipping to change at page 35, line 38 skipping to change at page 35, line 38
3.9. Relationship between SDID and AUID 3.9. Relationship between SDID and AUID
DKIM's primary task is to communicate from the Signer to a recipient- DKIM's primary task is to communicate from the Signer to a recipient-
side Identity Assessor a single Signing Domain Identifier (SDID) that side Identity Assessor a single Signing Domain Identifier (SDID) that
refers to a responsible identity. DKIM MAY optionally provide a refers to a responsible identity. DKIM MAY optionally provide a
single responsible Agent or User Identifier (AUID). single responsible Agent or User Identifier (AUID).
Hence, DKIM's mandatory output to a receive-side Identity Assessor is Hence, DKIM's mandatory output to a receive-side Identity Assessor is
a single domain name. Within the scope of its use as DKIM output, a single domain name. Within the scope of its use as DKIM output,
the name has only basic domain name semantics; any possible owner- the name hnamas only basic domain name semantics; any possible owner-
specific semantics are outside the scope of DKIM. That is, within specific semantics are outside the scope of DKIM. That is, within
its role as a DKIM identifier, additional semantics cannot be assumed its role as a DKIM identifier, additional semantics cannot be assumed
by an Identity Assessor. by an Identity Assessor.
A receive-side DKIM verifier MUST communicate the Signing Domain A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the Agent or User Identifier (i=) if present. communicate the Agent or User Identifier (i=) if present.
To the extent that a receiver attempts to intuit any structured To the extent that a receiver attempts to intuit any structured
semantics for either of the identifiers, this is a heuristic function semantics for either of the identifiers, this is a heuristic function
that is outside the scope of DKIM's specification and semantics. that is outside the scope of DKIM's specification and semantics.
Hence, it is relegated to a higher-level service, such as a delivery Hence, it is relegated to a higher-level service, such as a delivery
handling filter that integrates a variety of inputs and performs handling filter that integrates a variety of inputs and performs
heuristic analysis of them. heuristic analysis of them.
INFORMATIVE DISCUSSION: This document does not require the value INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match the identifier in any other message of the SDID or AUID to match an identifier in any other message
header field. This requirement is, instead, an assessor policy header field. This requirement is, instead, an assessor policy
issue. The purpose of such a linkage would be to authenticate the issue. The purpose of such a linkage would be to authenticate the
value in that other header field. This, in turn, is the basis for value in that other header field. This, in turn, is the basis for
applying a trust assessment based on the identifier value. Trust applying a trust assessment based on the identifier value. Trust
is a broad and complex topic and trust mechanisms are subject to is a broad and complex topic and trust mechanisms are subject to
highly creative attacks. The real-world efficacy of any but the highly creative attacks. The real-world efficacy of any but the
most basic bindings between the SDID or AUID and other identities most basic bindings between the SDID or AUID and other identities
is not well established, nor is its vulnerability to subversion by is not well established, nor is its vulnerability to subversion by
an attacker. Hence, reliance on the use of such bindings should an attacker. Hence, reliance on the use of such bindings should
be strictly limited. In particular, it is not at all clear to be strictly limited. In particular, it is not at all clear to
skipping to change at page 42, line 28 skipping to change at page 42, line 28
5.5. Recommended Signature Content 5.5. Recommended Signature Content
In order to maximize compatibility with a variety of verifiers, it is In order to maximize compatibility with a variety of verifiers, it is
recommended that signers follow the practices outlined in this recommended that signers follow the practices outlined in this
section when signing a message. However, these are generic section when signing a message. However, these are generic
recommendations applying to the general case; specific senders may recommendations applying to the general case; specific senders may
wish to modify these guidelines as required by their unique wish to modify these guidelines as required by their unique
situations. Verifiers MUST be capable of verifying signatures even situations. Verifiers MUST be capable of verifying signatures even
if one or more of the recommended header fields is not signed (with 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 the exception of From, which must always be signed) or if one or more
of the disrecommended header fields is signed. Note that verifiers of the dis-recommended header fields is signed. Note that verifiers
do have the option of ignoring signatures that do not cover a do have the option of ignoring signatures that do not cover a
sufficient portion of the header or body, just as they may ignore sufficient portion of the header or body, just as they may ignore
signatures from an identity they do not trust. signatures from an identity they do not trust.
The following header fields SHOULD be included in the signature, if The following header fields SHOULD be included in the signature, if
they are present in the message being signed: they are present in the message being signed:
o From (REQUIRED in all signatures) o From (REQUIRED in all signatures)
o Sender, Reply-To o Sender, Reply-To
skipping to change at page 52, line 33 skipping to change at page 52, line 33
transit? If the signature line is missing, is that because it was transit? If the signature line is missing, is that because it was
never there, or was it removed by an overzealous filter? For never there, or was it removed by an overzealous filter? For
diagnostic purposes, the exact reason why the verification fails diagnostic purposes, the exact reason why the verification fails
SHOULD be made available to the policy module and possibly recorded SHOULD be made available to the policy module and possibly recorded
in the system logs. If the email cannot be verified, then it SHOULD in the system logs. If the email cannot be verified, then it SHOULD
be rendered the same as all unverified email regardless of whether or be rendered the same as all unverified email regardless of whether or
not it looks like it was signed. not it looks like it was signed.
7. IANA Considerations 7. IANA Considerations
DKIM introduces some new namespaces that have been registered with DKIM has registered new namespaces with IANA. In all cases, new
IANA. In all cases, new values are assigned only for values that values are assigned only for values that have been documented in a
have been documented in a published RFC that has IETF Consensus published RFC that has IETF Consensus [RFC2434].
[RFC2434].
7.1. DKIM-Signature Tag Specifications 7.1. DKIM-Signature Tag Specifications
A DKIM-Signature provides for a list of tag specifications. IANA has A DKIM-Signature provides for a list of tag specifications. IANA has
established the DKIM-Signature Tag Specification Registry for tag established the DKIM-Signature Tag Specification Registry for tag
specifications that can be used in DKIM-Signature fields. specifications that can be used in DKIM-Signature fields.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+------+-----------------+ +------+-----------------+
 End of changes. 22 change blocks. 
88 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/