draft-ietf-dkim-rfc4871-errata-06.txt   draft-ietf-dkim-rfc4871-errata-07.txt 
DKIM D. Crocker, Ed. DKIM D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Updates: RFC4871 June 10, 2009 Updates: RFC4871 June 26, 2009
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2009 Expires: December 28, 2009
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
draft-ietf-dkim-rfc4871-errata-06 draft-ietf-dkim-rfc4871-errata-07
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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 12, 2009. This Internet-Draft will expire on December 28, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures. This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures.
Specifically the document clarifies the nature, roles and Specifically the document clarifies the nature, roles and
relationship of the two DKIM identifier tag values that are relationship of the two DKIM identifier tag values that are
candidates for payload delivery to a receiving processing module. candidates for payload delivery to a receiving processing module.
The Update is in the style of an Errata entry, albeit a rather long The Update is in the style of an Errata entry, albeit a rather long
one. one.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 3 2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 4
3. RFC4871 Section 1 Introduction . . . . . . . . . . . . . . . 4 3. RFC4871 Section 1 Introduction . . . . . . . . . . . . . . . 5
4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . 4 4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . 5
5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . 4 5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . 5
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . 5 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . 5
7. RFC4871 Section 2.10 Agent or User Identifier (AUID) . . . . 5 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) . . . . 6
8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . 5 8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . 6
9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 6 9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 7
10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 7 10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 8
11. RFC4871 Section 3.8 Signing by Parent Domains . . . . . . . . 9 11. RFC4871 Section 3.8 Signing by Parent Domains . . . . . . . . 10
12. RFC4871 Section 3.9 Relationship Between SDID and AUID . . . 10 12. RFC4871 Section 3.9 Relationship Between SDID and AUID . . . 10
13. RFC4871 Section 6.3 Interpret Results/Apply Local Policy . . 11 13. RFC4871 Section 6.3 Interpret Results/Apply Local Policy . . 11
14. RFC4871 Section 6.3 Interpret Results/Apply Local Policy . . 12 14. RFC4871 Section 6.3 Interpret Results/Apply Local Policy . . 12
15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 12 15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 12
16. Security Considerations . . . . . . . . . . . . . . . . . . . 12 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
18. Normative References . . . . . . . . . . . . . . . . . . . . . 13 18. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
communicate an identifier to a receive-side assessor module. The communicate an identifier to a receive-side assessor module. The
identifier is in the form of a domain name that refers to a identifier is in the form of a domain name that refers to a
responsible identity. For DKIM to be interoperable and useful, responsible identity. For DKIM to be interoperable and useful,
signer and assessor must share the same understanding of the details signer and assessor must share the same understanding of the details
about the identifier. about the identifier.
However the RFC4871 specification defines two, potentially different However the RFC4871 specification defines two, potentially different
identifiers that are carried in the DKIM-Signature: header field, d= identifiers that are carried in the DKIM-Signature: header field, d=
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 which is the "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 -- making different interpretations between the two identifiers and may
interpretations of how DKIM operates. lead to interoperability problems. A signer could intend one to be
used for assessment, and have a different intent in setting the value
in the other. However the verifier might choose the wrong value to
deliver to the assessor, thereby producing an unintended (and
inaccurate) assessment.
This update resolves this confusion. It defines new labels for the This update resolves that confusion. It defines additional, semantic
two values, clarifies their nature, and specifies their relationship. labels for the two values, clarifies their nature and specifies their
relationship. More specifically, it clarifies that the identifier
intended for delivery to the assessor -- such as one that consults a
white list -- is the value of the "d=" tag. However, this does not
prohibit message filtering engines from using the "i=" tag, or any
other information in the message's header, for filtering decisions.
For signers and verifiers that have been using the i= tag as the
primary value that is delivered to the assessor, a software change to
using the d= tag is intended.
So, this Update clarifies the formal interface to DKIM, after
signature verification has been performed. It distinguishes DKIM's
internal signing and verification activity, from its standardized
delivery of data to that interface.
The focus of the Update is on the portion of DKIM that is much like
an API definition. If DKIM is implemented as a software library for
use by others, it needs to define what outputs are provided, that is,
what data that an application developer who uses the library can
expect to obtain as a result of invoking DKIM on a message.
This Update draft defines the output of that library to include the
yes/no result of the verification and the "d=" value. In other
words, it says what (one) identifier was formally specified for use
by the signer and whether the use of that identifier has been
validated. For a particular library, other information can be
provided at the discretion of the library developer, since developers
of assessors -- these are the consumers of the DKIM library -- well
might want more information than the standardized two pieces of
information. However that standardized set is the minimum that is
required to be provided to a consuming module, in order to be able to
claim that the library is DKIM compliant.
This does not state what the implicit value of "i=" is, relative to
"d=". In this context, that fact is irrelevant.
Another example is the difference between the socket interface to TCP
versus the TCP protocol itself. There is the activity within the
protocol stack, and then there is the activity within in the software
libraries that are actually used.
NOTE: The text provided here updates [RFC4871]. All references and NOTE: The text provided here updates [RFC4871]. All references and
all appearances of RFC-2119 keywords are replacing text in RFC all appearances of RFC-2119 keywords are replacing text in RFC
4871. Hence those references are in that document and are not 4871. Hence those references are in that document and are not
needed here. needed here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
 End of changes. 10 change blocks. 
19 lines changed or deleted 63 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/