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" <tony(_at_)att(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
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
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html