On Tue, 2 Jan 2007, John Levine wrote:
I would support some gentler language that permits use of z= in
verification, with particular attention paid to ensuring that a new
security vulnerability is not introduced.
My recollection is that we had no idea what the security
vulnerabilities would be, nor did we have any proposals for a metric
of deciding when a modified header is "close enough". An obvious
example is how algorithmically one might purport to tell a subject
addition of [ietf-dkim] from an addition of [v1agra-at-www.sleazy.biz]
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the modification was as an option.
For most cases original value would be just fine as additional/mods
you worry about are mainly those by mail lists, but the issues there
are that some have user-side scripts to sort out email based on these
subject '[..]' subject tags.
My solution would be for the modifier to sign the message after
modification.
Signing after is completely separate issue. Every server (every
'administrative domain') in the path is supposed to be able to
sign if it can. However you should not force users to only use
latest signature (otherwise what you have is just crypto-based
replacement for path validation which could be done with a lot
less effort with server/domain ip validation mechanisms), what
you care about is who sent the original which signature matched
listed administrative domain of the sender.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html