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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html