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
[EMAIL PROTECTED]
Eric Rescorla wrote:
> Michael Thomas <[EMAIL PROTECTED]> 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
