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