Hi Tony, The only reason I see for having a hh (header hash tag) is to confirm a recalculation and offer the difference as a possible failure reason in reporting, logging, rejection and/or presentation to users (if the verifier domain wishes to risk to push the failure to end-users).
But why would I want this if the recalculation is suppose to work? - Missing h= headers - Modified h= headers The only time anyone should expect modified headers is once a MDA is concept and the message is being redistributed as in a mailing list. Missing headers is less of a problem in practice but it is possible also with a mailing list. But this is where the signing domain needs to be prudent and understand not to use headers that are susceptible to change (e.g., Reply-To:, Subject:). So the question becomes, suppose we had an hh= header, how does this change the end result? What if the recalculated header hash did not match the signer's hh= exposed hash? What do you want the verifier to do? Is it still considered "Invalid" but now we have a REASON? If so, that is good enough for me, but can't we come to this same reason and conclusion if the body hash (bh=) is satisfied, but the final signature hash is not? signature = rsa(bh + hh) if we have the bh= available and it recalculates successfully, and the rsa fails, then the only logical reason is a failure in the headers. Anyway, for me, I don't have a problem with extra "information" to work with, but what is more important to me is what do with the end-result. It is really the same issue that we had with the expiration. What if the expiration is a true state? We now watered it down to a MAY be considered invalid. Is this the same administrator dominated defined relaxed heuristic we want for this bh= and possible this new hh= tag errors? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Tony Hansen" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, May 01, 2006 9:28 AM Subject: Re: [ietf-dkim] Re: What the verifier can do > 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 > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
