On Tue, 2006-08-29 at 08:20 +0200, Frank Ellermann wrote: > Wietse Venema wrote: > > > The problem that you refer to is due to the mistaken belief > > that DKIM signatures imply anything about rfc2822.from > > addresses. We can eliminate the problem by simply taking DKIM > > signatures for what they actually are: proof about the > > identity of the signing party, not proof about the identity > > of the author. =============
Signature verification is always silent on the nature of content. Nevertheless, when the author's address associated with the signing party is trusted, then assertions of the signing party are also trustworthy by extension. > Okay, that's the "crypto timestamp" model, and apparently some > big players want precisely this and no additional nonsense. This scheme would be coupled with a call-back to verify whether the message is still considered valid, eliminating public crypto and providing a pay per verification model. > It would be consequent to take the timestamp line instead of > the 2822-From as "MUST" in base (5.4). The EAI / IMA folks > just discuss a situation where the 2822-From is removed or > empty after some UTF8SMTP magic hitting a legacy mailbox. Perhaps a header copy saves the day in this case. > If the whole point is a better timestamp line, why not include > it in the signature ? An MSA could _also_ sign the 2822-From > if it knows that it makes sense (From = Mail From ) and is ok. The MSA can also qualify the From based upon the account and prior receipt verification. > And a MUA could sign the (Resent-) Message-ID instead of the > timestamp line. But actually I don't think that MUAs trying > to sign mail are relevant at the moment. MUAs can sign with DKIM. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
