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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Sunday, July 23, 2006 11:09 AM
To: ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] 822/2822 or just 2822
Ned, et al,
ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com 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