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]
So I still think our decision to stay away from the whole thing was
correct. Either it's the same message and the signature verifies, or
it's not. I suppose we could tell people that it's OK to use z= as
part of the process of deciding what to do with a message whose
signature didn't verify, but that process is outside the scope of the
spec.
My solution would be for the modifier to sign the message after
modification.
Yes indeed. Any time someone proposes something more complicated than
this, they really need to explain why.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html