[ietf-dkim] Nits with section 3 Operation Overview

Douglas Otis dotis at mail-abuse.org
Fri Nov 2 06:56:15 PST 2007


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2688 bytes
Desc: not available
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20071102/b5f346e7/smime.bin


More information about the ietf-dkim mailing list