draft-ietf-dkim-rfc4871-errata-02.txt | draft-ietf-dkim-rfc4871-errata-03.txt | |||
---|---|---|---|---|
DKIM D. Crocker, Ed. | DKIM D. Crocker, Ed. | |||
Internet-Draft Brandenburg InternetWorking | Internet-Draft Brandenburg InternetWorking | |||
Intended status: Standards Track February 5, 2009 | Updates: RFC4871 April 3, 2009 | |||
Expires: August 9, 2009 | (if approved) | |||
Intended status: Standards Track | ||||
Expires: October 5, 2009 | ||||
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Errata | RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update | |||
draft-ietf-dkim-rfc4871-errata-02 | draft-ietf-dkim-rfc4871-errata-03 | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. This document may contain material | |||
from IETF Documents or IETF Contributions published or made publicly | ||||
available before November 10, 2008. The person(s) controlling the | ||||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 9, 2009. | This Internet-Draft will expire on October 5, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 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 in effect on the date of | |||
(http://trustee.ietf.org/license-info) in effect on the date of | publication of this document (http://trustee.ietf.org/license-info). | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. | |||
to this document. | ||||
Abstract | Abstract | |||
This documents and resolves errata for RFC 4871, DomainKeys | This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures. | |||
Identified Mail (DKIM) Signatures. Specifically the document | Specifically the document clarifies the nature, roles and | |||
clarifies the nature, roles and relationship of the two DKIM | relationship of the two DKIM identifier tag values that are | |||
identifier tag values that are candidates for payload delivery to a | candidates for payload delivery to a receiving processing module. | |||
receiving processing module. This Errata entry has been developed | The Update is in the style of an Errata entry, albeit a rather long | |||
and approved by the IETF's DKIM working group. | one. | |||
Errata Contact Fields | ||||
Name: Dave Crocker | ||||
Email: dcrocker@bbiw.net | ||||
Type | ||||
Technical | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 3 | 2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . 4 | 3. RFC4871 Section 1. Introduction . . . . . . . . . . . . . . . 4 | |||
4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4 | 4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . . 4 | |||
5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4 | 5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . . 4 | |||
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4 | 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . . 4 | |||
7. RFC4871 Section 2.10 User Agent Identifier (UAID) . . . . . . 5 | 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) . . . . . 5 | |||
8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5 | 8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . . 5 | |||
9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 5 | 9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 5 | |||
10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 6 | 10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 6 | |||
11. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . 8 | 11. RFC4871 Section 3.8. Signing by Parent Domains . . . . . . . 9 | |||
12. RFC4871 Section 3.9 Relationship Between SDID and UAID . . . . 9 | 12. RFC4871 Section 3.9 Relationship Between SDID and AUID . . . . 9 | |||
13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 10 | 13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 10 | |||
14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 11 | 14. RFC4871 Section 6.3. Interpret Results/Apply Local Policy . . 11 | |||
15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 11 | 15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 11 | |||
16. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 16. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
17. Normative References . . . . . . . . . . . . . . . . . . . . . 11 | 17. Normative References . . . . . . . . . . . . . . . . . . . . . 12 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1. Introduction | 1. Introduction | |||
About the purpose for DKIM, [RFC4871] states: | About the purpose for DKIM, [RFC4871] states: | |||
The ultimate goal of this framework is to permit a signing domain | The ultimate goal of this framework is to permit a signing domain | |||
to assert responsibility for a message, thus protecting message | to assert responsibility for a message, thus protecting message | |||
signer identity... | signer identity... | |||
skipping to change at page 3, line 34 | skipping to change at page 3, line 34 | |||
and i=. Either might be delivered to a receiving processing module | and i=. Either might be delivered to a receiving processing module | |||
that consumes validated payload. The DKIM specification fails to | that consumes validated payload. The DKIM specification fails to | |||
clearly define what is "payload" to be delivered to a consuming | clearly define what is "payload" to be delivered to a consuming | |||
module, versus what is internal and merely in support of achieving | module, versus what is internal and merely in support of achieving | |||
payload delivery. | payload delivery. | |||
This currently leaves signers and assessors with the potential for | This currently leaves signers and assessors with the potential for | |||
having differing -- and therefore non-interoperable -- | having differing -- and therefore non-interoperable -- | |||
interpretations of how DKIM operates. | interpretations of how DKIM operates. | |||
This erratum resolves this confusion. It defines new labels for the | This update resolves this confusion. It defines new labels for the | |||
two values, clarifies their nature, and specifies and their | two values, clarifies their nature, and specifies and their | |||
relationship. | relationship. | |||
NOTE: This Errata document 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>. | ||||
2. RFC 4871 Abstract | 2. RFC 4871 Abstract | |||
Original Text: | Original Text: | |||
The ultimate goal of this framework is to permit a signing domain | The ultimate goal of this framework is to permit a signing domain | |||
to assert responsibility for a message, | to assert responsibility for a message, | |||
Corrected Text: | Corrected Text: | |||
The ultimate goal of this framework is to permit a person, role or | The ultimate goal of this framework is to permit a person, role or | |||
organization that owns the signing domain to assert responsibility | organization that owns the signing domain to assert responsibility | |||
for a message, | for a message, | |||
3. RFC4871 Section 1. Introduction | 3. RFC4871 Section 1. Introduction | |||
Original Text: | Original Text: | |||
skipping to change at page 5, line 4 | skipping to change at page 4, line 40 | |||
Original Text: | Original Text: | |||
(None. Additional text.) | (None. Additional text.) | |||
Corrected Text: | Corrected Text: | |||
A label that refers to an identity. | A label that refers to an identity. | |||
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) | 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) | |||
Original Text: | Original Text: | |||
(None. Additional text.) | (None. Additional text.) | |||
Corrected Text: | Corrected Text: | |||
A single, opaque value that is the mandatory payload output of | A single domain name that is the mandatory payload output of DKIM | |||
DKIM and which refers to the identity claiming responsibility for | and that refers to the identity claiming responsibility for | |||
the introduction of a message into the mail stream. It is | introduction of a message into the mail stream. For DKIM | |||
specified in section 3.5. | processing, the name has only basic domain name semantics; any | |||
possible owner-specific semantics is outside the scope of DKIM. | ||||
It is specified in section 3.5. | ||||
7. RFC4871 Section 2.10 User Agent Identifier (UAID) | 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) | |||
Original Text: | Original Text: | |||
(None. Additional text.) | (None. Additional text.) | |||
Corrected Text: | Corrected Text: | |||
A single, opaque value that identifies the user or agent on behalf | A single domain name that identifies the agent or user on behalf | |||
of whom the SDID has taken responsibility. It is specified in | of whom the SDID has taken responsibility. For DKIM processing, | |||
section 3.5. | the domain name portion of the AUID has only basic domain name | |||
semantics; any possible owner-specific semantics is outside the | ||||
scope of DKIM. It is specified in section 3.5. | ||||
8. RFC4871 Section 2.11 Identity Assessor | 8. RFC4871 Section 2.11 Identity Assessor | |||
Original Text: | Original Text: | |||
(None. Additional text.) | (None. Additional text.) | |||
Corrected Text: | Corrected Text: | |||
The name of the module that consumes DKIM's primary payload, the | The name of the module that consumes DKIM's mandatory payload, the | |||
responsible Signing Domain Identifier (SDID). It can optionally | responsible Signing Domain Identifier (SDID). The module is | |||
consume the User Agent Identifier (UAID) value, if provided to the | dedicated to the assessment of the delivered identifier. Other | |||
module. | 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. | ||||
9. RFC4871 Section 3.5 The DKIM-Signature Header Field | 9. RFC4871 Section 3.5 The DKIM-Signature Header Field | |||
Original Text: | Original Text: | |||
d= The domain of the signing entity (plain-text; REQUIRED). This is | d= The domain of the signing entity (plain-text; REQUIRED). This is | |||
the domain that will be queried for the public key. This domain | the domain that will be queried for the public key. This domain | |||
MUST be the same as or a parent domain of the "i=" tag (the | MUST be the same as or a parent domain of the "i=" tag (the | |||
signing identity, as described below), or it MUST meet the | signing identity, as described below), or it MUST meet the | |||
requirements for parent domain signing described in Section 3.8. | requirements for parent domain signing described in Section 3.8. | |||
skipping to change at page 6, line 44 | skipping to change at page 6, line 44 | |||
that does not meet these requirements, verifiers MUST consider | that does not meet these requirements, verifiers MUST consider | |||
the signature invalid. | 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) | domain-name = sub-domain 1*("." sub-domain) | |||
; from RFC 2821 Domain, but excluding address-literal | ; from RFC 2821 Domain, but excluding | |||
address-literal | ||||
10. RFC4871 Section 3.5 The DKIM-Signature Header Field | 10. RFC4871 Section 3.5 The DKIM-Signature Header Field | |||
Original Text: | Original Text: | |||
i= Identity of the user or agent (e.g., a mailing list manager) on | i= Identity of the user or agent (e.g., a mailing list manager) on | |||
behalf of which this message is signed (dkim-quoted-printable; | behalf of which this message is signed (dkim-quoted-printable; | |||
OPTIONAL, default is an empty Local-part followed by an "@" | OPTIONAL, default is an empty Local-part followed by an "@" | |||
followed by the domain from the "d=" tag). The syntax is a | followed by the domain from the "d=" tag). The syntax is a | |||
standard email address where the Local-part MAY be omitted. The | standard email address where the Local-part MAY be omitted. The | |||
skipping to change at page 7, line 50 | skipping to change at page 8, line 4 | |||
well established, nor is its vulnerability to subversion by | well established, nor is its vulnerability to subversion by | |||
an attacker. Hence reliance on the use of these options | an attacker. Hence reliance on the use of these options | |||
should be strictly limited. In particular, it is not at all | should be strictly limited. In particular, it is not at all | |||
clear to what extent a typical end-user recipient can rely on | clear to what extent a typical end-user recipient can rely on | |||
any assurances that might be made by successful use of the | any assurances that might be made by successful use of the | |||
"i=" options. | "i=" options. | |||
Corrected Text: | Corrected Text: | |||
i= | i= | |||
The Agent or User Identifier (AUID) on behalf of which the SDID | ||||
The User Agent Identifier (UAID) on behalf of which the SDID is | is taking responsibility (dkim-quoted-printable; OPTIONAL, | |||
taking responsibility (dkim-quoted-printable; OPTIONAL, default | default is an empty Local-part followed by an "@" followed by | |||
is an empty Local-part followed by an "@" followed by the | the domain from the "d=" tag). | |||
domain from the "d=" tag). | ||||
The syntax is a standard email address where the Local-part MAY | The syntax is a standard email address where the Local-part MAY | |||
be omitted. The domain part of the address MUST be the same | be omitted. The domain part of the address MUST be the same | |||
as, or a subdomain of the value of, the "d=" tag. | as, or a subdomain of the value of, the "d=" tag. | |||
Internationalized domain names MUST be converted using the | Internationalized domain names MUST be converted using the | |||
steps listed in Section 4 of [RFC3490] using the "ToASCII" | steps listed in Section 4 of [RFC3490] using the "ToASCII" | |||
function. | function. | |||
ABNF: | ABNF: | |||
sig-i-tag = %x69 [FWS] "=" [FWS] | sig-i-tag = %x69 [FWS] "=" [FWS] | |||
[ Local-part ] "@" domain-name | [ Local-part ] "@" domain-name | |||
The UAID 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. | address, but is not required to have the same semantics. | |||
Notably, the domain name is not required to be registered in | Notably, the domain name is not required to be registered in | |||
the DNS -- so it might not resolve in a query -- and the Local- | 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 | part MAY be drawn from a namespace that does not contain the | |||
user's mailbox. The details of the structure and semantics for | user's mailbox. The details of the structure and semantics for | |||
the namespace are determined by the Signer. Any knowledge or | the namespace are determined by the Signer. Any knowledge or | |||
use of those details by verifiers or assessors is outside the | use of those details by verifiers or assessors is outside the | |||
scope of the DKIM Signing specification. The Signer MAY choose | scope of the DKIM Signing specification. The Signer MAY choose | |||
to use the same namespace for its UAIDs as its users' email | to use the same namespace for its AUIDs as its users' email | |||
addresses, or MAY choose other means of representing its users. | addresses, or MAY choose other means of representing its users. | |||
However, the signer SHOULD use the same UAID for each message | However, the signer SHOULD use the same AUID for each message | |||
intended to be evaluated as being within the same sphere of | intended to be evaluated as being within the same sphere of | |||
responsibility, if it wishes to offer receivers the option of | responsibility, if it wishes to offer receivers the option of | |||
using the UAID as a finer grained, stable identifier than the | using the AUID as a finer grained, stable identifier than the | |||
SDID. | 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 9, line 20 | skipping to change at page 9, line 24 | |||
validity of the record to exactly the domain of the signing identity. | validity of the record to exactly the domain of the signing identity. | |||
If the referenced key record contains the "s" flag as part of the | If the referenced key record contains the "s" flag as part of the | |||
"t=" tag, the domain of the signing identity ("i=" flag) MUST be the | "t=" tag, the domain of the signing identity ("i=" flag) MUST be the | |||
same as that of the d= domain. If this flag is absent, the domain of | same as that of the d= domain. If this flag is absent, the domain of | |||
the signing identity MUST be the same as, or a subdomain of, the d= | the signing identity MUST be the same as, or a subdomain of, the d= | |||
domain. | domain. | |||
Corrected Text: | Corrected Text: | |||
...for example, a key record for the domain example.com can be | ...for example, a key record for the domain example.com can be | |||
used to verify messages where the UAID ("i=" tag of the signature) | 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 | 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 | 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 | "s" flag MAY be set in the "t=" tag of the key record, to | |||
constrain the validity of the domain of the UAID. If the | constrain the validity of the domain of the AUID. If the | |||
referenced key record contains the "s" flag as part of the "t=" | referenced key record contains the "s" flag as part of the "t=" | |||
tag, the domain of the UAID ("i=" flag) MUST be the same as that | 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 | of the SDID (d=) domain. If this flag is absent, the domain of | |||
the UAID MUST be the same as, or a subdomain of, the SDID. | the AUID MUST be the same as, or a subdomain of, the SDID. | |||
12. RFC4871 Section 3.9 Relationship Between SDID and UAID | 12. RFC4871 Section 3.9 Relationship Between SDID and AUID | |||
Original Text: (None. This is an addition.) | Original Text: (None. This is an addition.) | |||
Corrected Text: | Corrected Text: | |||
DKIM's primary task is to communicate from the Signer to a | DKIM's primary task is to communicate from the Signer to a | |||
recipient-side Identity Assessor a single, Signing Domain | recipient-side Identity Assessor a single, Signing Domain | |||
Identifier (SDID) that refers to a responsible identity. DKIM MAY | Identifier (SDID) that refers to a responsible identity. DKIM MAY | |||
optionally provide a single responsible User Agent Identifier | optionally provide a single responsible Agent or User Identifier | |||
(UAID). | (AUID). | |||
Hence, DKIM delivers to receive-side Identity Assessors | Hence, DKIM's mandatory delivery to a receive-side Identity | |||
responsible Identifiers that are opaque to the assessor. Their | Assessor is a single domain name. Within the scope of its use as | |||
sub-structures and particular semantics are not publicly defined | DKIM output, the name has only basic domain name semantics; any | |||
and, therefore, cannot be assumed by an Identity Assessor. | possible owner-specific semantics is outside the scope of DKIM. | |||
That is, within its role as a DKIM identifier, additional | ||||
semantics cannot be assumed 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 User Agent Identifier (i=) if present. | communicate the User Agent 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 | semantics for either of the identifiers, this is a heuristic | |||
function that is outside the scope of DKIM's specification and | function that is outside the scope of DKIM's specification and | |||
semantics. Hence it is relegated to a higher-level service, such | semantics. Hence it is relegated to a higher-level service, such | |||
as a delivery handling filter that integrates a variety of inputs | as a delivery handling filter that integrates a variety of inputs | |||
and performs heuristic analysis of them. | and performs 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 UAID to match the identity in any message header | of the SDID or AUID to match the identity in any message header | |||
fields. This is considered to be an assessor policy issue. | fields. This is considered to be an assessor policy issue. | |||
Constraints between the value of the SDID or UAID and other | Constraints between the value of the SDID or AUID and other | |||
identities in other header fields seek to apply basic | identities in other header fields seek to apply basic | |||
authentication into the semantics of trust associated with a role | authentication into the semantics of trust associated with a role | |||
such as content author. Trust is a broad and complex topic and | such as content author. Trust is a broad and complex topic and | |||
trust mechanisms are subject to highly creative attacks. The | trust mechanisms are subject to highly creative attacks. The | |||
real-world efficacy of any but the most basic bindings between the | real-world efficacy of any but the most basic bindings between the | |||
SDID or UAID and other identities is not well established, nor is | SDID or AUID and other identities is not well established, nor is | |||
its vulnerability to subversion by an attacker. Hence reliance on | its vulnerability to subversion by an attacker. Hence reliance on | |||
the use of these options should be strictly limited. In | the use of these options should be strictly limited. In | |||
particular, it is not at all clear to what extent a typical end- | 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 | user recipient can rely on any assurances that might be made by | |||
successful use of the SDID or UAID. | successful use of the SDID or AUID. | |||
13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy | 13. RFC4871 Section 6.3. Interpret Results/Apply Local Policy | |||
Original Text: | Original Text: | |||
It is beyond the scope of this specification to describe what actions | It is beyond the scope of this specification to describe what actions | |||
a verifier system should make, but an authenticated email presents an | a verifier system should make, but an authenticated email presents an | |||
opportunity to a receiving system that unauthenticated email cannot. | opportunity to a receiving system that unauthenticated email cannot. | |||
Specifically, an authenticated email creates a predictable identifier | Specifically, an authenticated email creates a predictable identifier | |||
by which other decisions can reliably be managed, such as trust and | by which other decisions can reliably be managed, such as trust and | |||
skipping to change at page 11, line 37 | skipping to change at page 11, line 41 | |||
Original Text: The tendency is to have the MUA highlight the | Original Text: The tendency is to have the MUA highlight the | |||
address associated with this signing identity in some way, in an | address associated with this signing identity in some way, in an | |||
attempt to show the user the address from which the mail was sent. | attempt to show the user the address from which the mail was sent. | |||
Corrected Text: The tendency is to have the MUA highlight the SDID, | Corrected Text: The tendency is to have the MUA highlight the SDID, | |||
in an attempt to show the user the identity that is claiming | in an attempt to show the user the identity that is claiming | |||
responsibility for the message. | responsibility for the message. | |||
16. Security Considerations | 16. Security Considerations | |||
This Errata document clarifies core details about DKIM's payload. As | This Update clarifies core details about DKIM's payload. As such it | |||
such it affects interoperability, semantic characterization, and the | affects interoperability, semantic characterization, and the | |||
expectations for the identifiers carried with a DKIM signature. | expectations for the identifiers carried with a DKIM signature. | |||
Clarification of these details is likely to limit misinterpretation | Clarification of these details is likely to limit misinterpretation | |||
of DKIM's semantics. Since DKIM is fundamentally a security | of DKIM's semantics. Since DKIM is fundamentally a security | |||
protocol, this should improve its security characteristics. | protocol, this should improve its security characteristics. | |||
17. Normative References | 17. Normative References | |||
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | |||
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | |||
Signatures", RFC 4871, May 2007. | Signatures", RFC 4871, May 2007. | |||
Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
This document was initially formulated by an ad hoc design team, | This document was initially formulated by an ad hoc design team, | |||
comprising: Jon Callas, J D Falk, Jim Fenton, Tony Hansen, Murray | comprising: Jon Callas, J D Falk, Tony Hansen, Murray Kucherawy, John | |||
Kucherawy, John Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel, | Levine, Michael Hammer, Jeff Macdonald, Ellen Siegel, Wietse Venema. | |||
Wietse Venema. It was then submitted to the DKIM working group for | It was then submitted to the DKIM working group for revision and | |||
revision and approval. | approval. | |||
Author's Address | Author's Address | |||
D. Crocker (editor) | D. Crocker (editor) | |||
Brandenburg InternetWorking | Brandenburg InternetWorking | |||
Phone: +1.408.246.8253 | Phone: +1.408.246.8253 | |||
Email: dcrocker@bbiw.net | Email: dcrocker@bbiw.net | |||
End of changes. 36 change blocks. | ||||
79 lines changed or deleted | 87 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |