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/ |