At 00:58 22-02-2009, Murray S. Kucherawy wrote:
(d) included a "with the following changes" provision. What changes
are you suggesting (or supporting)?
I'm reusing text from Eliot's and Jim's proposal. From Section 5 of RFC 4871:
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 the "g=" tag, verifiers MUST treat the
Local-part contents as an opaque string. The Local-part and any
"subdomain" of the "d=" value that appears in the "i=" tag are
significant only to the signer.
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
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.
Although its syntax might suggest otherwise, the "i="
value need not be in the namespace that contains the mailbox
of the user or agent. 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.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html