>> Exactly. You are trying to have DKIM provide a range of information,...
>
> 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
since the pk computation is usually considered more expensive than the
hashing, i'm not sure what the benefit is, here, but for a very large
message, i guess saving the overhead of the hash would be nice. not a
point worth serious contortions, but as noted this ain't an expensive
enhancement.
This also can depend on what sort of hardware accelerator you have available.
I've seen some nice improvements in hash computation performance as well as RSA
computation performance (although I worry that we may have a shift to a totally
different hash function family in the future that will negate most of this) but
generally speaking it seems like it's easier to speed up RSA operations with
fancy hardware.
I was arguing against subtle semantics, not extra storage.
Yes, and there's also the potential for these subtle things to cause us to
rathole.
in any event:
> 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.)
yeah, like i'm every going to argue against your assessment of
implementation or performance issues...
anyhow, it always pisses me off to have my main line of argument become
irrelevant by virtue of a simple, direct and compelling alternate
argument. i probably won't always concede to debugging benefits, but
pretty close...
so my reaction to your posting along those lines was something like
game, set, match.
Thanks!
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org