On the face of this it looks like a third party is molesting the message after signing but before delivery. If the third party does not currently do DKIM then the signature will result in failure. If the third party is DKIM aware then it could verify the signature, make needed changes then re-sign the message and forward it to the recipient. This brings us back to 3rd party signatures that break the original signature and into policy issues. Thanks,
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Sunday, July 23, 2006 11:09 AM To: [EMAIL PROTECTED] Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] 822/2822 or just 2822 Ned, et al, [EMAIL PROTECTED] wrote: >> The "not necessarily" referred to the claim that SUBMIT is automatically before >> signing. Signing may be done by any component in the AdMD, including the MUA. > > But if it is done by the MUA, the problem is that fully comformant SUBMIT > agents or various sorts of other conforming intermediaries can and often will > wreck the signature. Yup. But, then, I view that as merely an exemplar of the question of surviving transit through intermediaries. That the SUBMIT "intermediary" typically makes significant changes merely makes this scenario more interesting to explore. > And this says nothing about non-conforming intermediaries, > which aren't exactly unheard of. They are the core issue in deciding canonicalization trade-offs and I am certainly not making light of the concerns. However I do not believe I've suggested anything that lessens or increases them as an issue for DKIM utility. Again, MUA-based signing provides a more challenging example of the issue, but this is a difference in degree, not in kind, IMO. > If you want another example, how about RFC 4141? You're a coauthor of that one. I think that content conversion *must* be viewed as a gateway function, and that surviving gateways is already a challenge for DKIM. Since you raise this example and I think it is interesting, let's explore it a bit: The only way that I can think of surviving is to have the signature evaluation be done before the conversion. This means that conversion must take place within the trusted AdMD in which the result of signature validation gets used. This can occur after content conversion, or the like, but must be within the same trust boundary, so that the mechanism for communicating the validation result -- such as with an Auth-Results header field -- can itself be trusted. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html