Eliot Lear wrote:
Here, the consumer of this information, the verifier, is warned against
making use of i=. However, what we are now saying is that practical
deployment experience requires a stronger warning; that absent
additional information from the signer that is not exposed by this
specification, verifiers SHOULD NOT rely on i= as any sort of identity,
because the value may not be present or stable.
My two questions:
1. Why not just say that in the erratum? It has the
advantage of being very concise, requiring no additional terminology,
and even better, no additional FLAs. It also clearly meets the
parameters for an erratum.
I agree with the general spirit behind clarifying the use of i= in this
way. I'm not sure I'd word it quite that way, but we can cross that
bridge later.
2. Is the
above statement actually true? Do we have practical
experience that shows that i= is either unstable or unused? Can
someone talk to that point?
I had expected that i= would receive little use. While it's true that
Cisco happens to set i= to the From address, it doesn't really need to
do that. I'm running dkim-milter at home and it doesn't (at least as I
have it configured) include an i= tag. From a DKIM protocol
standpoint, there's only one situation where one MUST include i=, and
that's when the g= tag in the signature is more specific than '*'.
While ADSP does match against i= if it's there, the intent is primarily
to prevent a user of a (g=) restricted key from asserting an Author
Signature for addresses they're not authorized. For that reason, Doug
Otis had suggested that we match the local-part of From against the g=
of the key rather than the i= of the signature, but there was no
consensus for that.
One remaining point of discussion:
While the confusion arises between d= and i=, what verifiers do with a
valid signed message is still up to them. They could take input from
various header fields if they wish (and some assuredly do and will).
Comments?
I also think that the output of DKIM may be more than i= and/or d=. We
made sure that DKIM was extensible; there could very easily be other
tag/value pairs that are invented in the future and that communicating
a "single Responsible Identifier" is a false premise. There have been
lots of suggestions for additional tags: at one point someone
suggested a tag indicating a transactional message, and the stable
opaque identifier thing could easily be another tag. I'm not saying
that these are necessarily good ideas, but that there could easily be
other information in the signature that's useful to an assessor, if
it's present.
-Jim
|
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html