Re: Re: What the verifier can do

At 11:22 AM -0700 4/30/06, Eric Rescorla wrote:
> Yes, but it's a bad idea to design systems assuming that's going
> to be the only algorithm you ever use.

We are explicitly *not* designing this system to use heuristics that 
would cause multiple rounds. My assertion is that if an 
implementation wants to do it, it can. Along with that assertion is 
the fact that, with all the algorithms defined in the document and 
the assumption that we are unlikely to change them except in a 
cryptographic emergency, the expensive operations (asymmetric signing 
and verifying) only need to happen once.

> Sure, but what happens when you want to use ECDSA because you're
> worried about key size constraints?

Then you decide if your actions that go beyond the spec are worth it 
for you in terms of effort.


At 12:22 PM -0700 4/30/06, Michael Thomas wrote:
> Tony Hansen wrote:
>
> > Paul Hoffman wrote:
> >
> >
> >
> > Paul, which hash where? There is no hash in the dkim signature for the
> > headers, only a hash for the body and the resulting signature.
> ...snip...
> > If you're going to apply heuristics to the headers, you can't get away
> > from recalculating the RSA signature after each application of the
> > heuristics.
>
> I think you're both saying the same thing.

We are not, I believe.

> The RSA verify operation yields
> a hash that you compare against the hash of the headers (and body from bh).
> I think that's what Paul is referring to.

It is. At that point, you know what hash was signed. You then compare 
the hashes you get with your heuristics (if you are using them...) 
against that one hash.