On Oct 30, 2007, at 6:12 PM, Jeff Macdonald wrote:
On Tue, Oct 30, 2007 at 03:28:12PM -0700, Douglas Otis wrote:
The issue whether the i= identity has been validated in some
fashion can not be answered without some specific additional
assertion added to DKIM.
I'm really having trouble understanding that since i= must be part
or equal to d=, why there needs to be further validation.
Why would a signing domain add an i= that would not be responsible?
If the answer is "because you can", why would one believe that d=
would be responsible?
When to include full email-addresses within the i= parameter is not
specifically defined. The decision could be based upon how a message
might later be handled, and have little to do with identity
verification by the signer. It would be unsafe to assume inclusion
of full email-address into the i= parameter offers some specific
assurance.
The i= parameter could indicate use of a restricted key. A
restricted key might also allow a Sender header identity to sign on
behalf of any From identity. In this case, there would be less
reason to trust the validity of the message, or an identity based
upon a poorly controlled private key. Use of the i= identity depends
upon header specific highlighting before it conveys meaning to the
recipient. How this highlighting is applied is sure to dictate when
to include the full email-address into the i= parameter.
Attempting to use DKIM to assure identities is unsafe. There is no
assurance made as a result of an email-address being placed into the
i= parameter without some added specification and assertion not
currently defined in DKIM. Deprecating the use of the i= parameter
seems like a better choice.
-Doug
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html