Dear all,
As I had mentioned in a previous email[*], my understanding of the
concerns raised by Dave and others is that there is insufficient clarity
(I originally used the word sternness) in the warnings about the use of
i=, with respect to its stability and presence. My greatest concern
with Dave's draft is we would be using a hammer where a fly swatter is
needed. Definition of additional terms, while perhaps providing more
precision, does not necessarily make for ease of reading. People know
what they know, and they generally do NOT like to have to learn new
terminology in order to get the job done. Getting right down to the
point in as few a sentences (and terms) as possible makes the reader's
life easier, even if the language is somewhat less precise. The gold
standard, of course, is whether the corrective text will sufficiently
avert interoperability problems.
All of this having been stated, here are the precise ;-) changes I
propose to RFC 4871, by way of errata:
On Page 20, Section Section 3.5, definition of i=,
OLD:
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
NEW:
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag. Absent additional external
information outside of the context of g=, verifiers MUST treat
the Local-part contents as opaque strings.
OLD:
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.
NEW (additional text at the bottom):
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options. Implementations should not rely on the
presence of this value or its stability.
I hope this clearly states concerns mentioned within this group in the
fewest additional words. This having been said, this is a proposal, and
I would welcome improvements.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html