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.
It is common for Errata to provide precise corrections. That means supplying
the exact text that needs to be changed. While a generic "warning" is
comforting, it is not precise. For example, it requires an implementor to take
the general warning and try to guess what aspects of the original specification
have been changed. Guess = non-interoperable.
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).
Anyone can do anything. That's always true, and so it's not an observation
helps a protocol specification be understood.
Stated differently: Within a protocol specification, participants may NOT do
whatever they want. Once they choose to participate, they must follow the spec.
Verification is a very precise and mechanical process. Supplying a verified
identifier, as the output of verification, is the stated purpose of DKIM.
too, is a mundane and mechanical task, as long as the spec is clear about what
identifier to supply.
How the identifier is then used is entirely outside the spec and, indeed it is
here that folks do all sorts of things.
Jim Fenton wrote:
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.
1. Anything is possible in the future. The assertion is about the present.
do not appear to be saying that DKIM has other output now.
2. Single Responsible Identifier is not a premise, it's the explicitly stated
purpose of DKIM, as quoted carefully in the Errata draft. If you believe DKIM
has other other goals and/or functions, where are they documented?
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.
I'm not understanding how this is relevant to the current effort at resolving
ambiguities about d=/i=?
NOTE WELL: This list operates according to