Paul Hoffman <phoffman(_at_)proper(_dot_)com> writes:
At 10:58 AM -0700 4/30/06, Eric Rescorla wrote:
I know it's pedantic, but it's important: digital signature algorithms
*sign* the hash. They do not, in general, encrypt it. It's true that
signature and encryption are similar in RSA, but they're not the same
in (e.g., DSA). Also, while the performance reason is important,
it's not the only reason. Because signature algorithms can only
process small chunks of data, a digest lets you sign large blocks
without having to worry about gluing together the signatures somehow.
Pendantry accepted. But, in this case, the only signature algorithm we
have defined is RSA.
Yes, but it's a bad idea to design systems assuming that's going
to be the only algorithm you ever use.
This procedure only works if either:
(1) You place a copy of the message digest in the DKIM headers.
Based on my reading of draft-allman-*, this is not the case
in DKIM. It's not the case in S/MIME either, AFAIK.
(2) You have a signature algorithm with message recovery
(meaning that you can extract the hash from the signature).
Again, this is only true of RSA.
Otherwise you need to do a full signa ture verification for each
trial manipulation.
Correct. #2 applies here because we have only defined RSA.
Sure, but what happens when you want to use ECDSA because you're
worried about key size constraints? Digital signature algorithms
really should be treated as black boxes, rather than modelled as
RSA.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html