[ietf-dkim] Re: signature construct

[Ned Freed]

> >> 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