ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] summarizing my understanding of the errata discussion & a proposal

2009-02-05 20:31:06
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
<Prev in Thread] Current Thread [Next in Thread>