Or bite the bullet now and introduce hh (header hash)? It would act
exactly like bh (body hash), but be a hash of all headers except
dkim-signature. The signing algorithm would then be done over just the
dkim-signature header. This would make the header hash explicitly
present, simple to access, and easier to check against. If you wanted to
do additional heuristics, this is as opposed to getting the hash back as
a side effect of doing the signature verification and having to know
something about how rsa works on the inside.
Which is more confusing? :-) (If we were to hum right now, I'd hum for
making the header hash be explicit.)
Tony Hansen
tony(_at_)att(_dot_)com
Eric Rescorla wrote:
Michael Thomas <mike(_at_)mtcc(_dot_)com> writes:
If we ever move to a new signing algorithm that doesn't encrypt
like RSA does, it seems like that might be a worthwhile thing to
do. As it stands now, we don't have the need so it would probably
not do much more than add confusion.
That's fine, but if we believe that in order to have an operational
system you're going to need to be able to do signature message
recovery in some way, I think that needs to be explicitly stated
somewhere, not just left silent.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html