> I agree with this point. What's important to me, though, is that we
> be able to tell the difference between a failed signature (because the
> body was changed) and a bogus signature (something signed with the
> wrong key, or something made to look like a sig that's not).
This is the sort of goal that seems entirely reasonable, but might not
be. It's worth exploring exactly how much sophistication and subtlety
is needed, for the functionality DKIM is seeking to provide.
As I understand it, the goal is to determine a domain that is willing to
assert responsibility for the message.
That's a positive goal. It only applies if the signature validates. If
validation fails, for any reason, then we do not have an accountable domain.
It sounds as if the distinction you want to draw is useful for some sort
of additional goal:
> It may be a matter of the degree of risk I'm willing to take, and the
> information is useful....
> If I can rule (3) out because I can tell that the sig is a good one,
> but the message no longer matches it, then I can decide that perhaps
> mybigcustomer.com is important enough that I want it whitelisted
> anyway, and take the risk.
Exactly. You are trying to have DKIM provide a range of information, as
input to a more subtle identity-assessment process (or perhaps for an
assessment process that is intended to be more robust... but is it
really capable of succeeding?)
I don't know if this bit of trickiness is capable of succeeding, but I'm not
sure how much this matters. Carrying the hash value around in addition to the
signature has other uses. As Earl has pointed out, one thing it lets you do is
validate the public key signature first, and if it doesn't validate you don't
need to bother performing the hash operation. (The public key operation is
expensive, but not nearly as expensive as computing a hash for a large
message.) And I previously pointed out that this helps tremendously in tracking
down problems. (And if you don't think this matters, all I can say is you
haven't written or supported enough implementations of this sort of stuff.)
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org