On Tue, 21 Mar 2006, Stephen Farrell wrote:
Jim Fenton wrote:
Just in the interest of accuracy...
Barry Leiba wrote:
Third, as was pointed out, a sender could hash a large body once and
send it multiple times, possibly saving a lot of time/effort.
This doesn't depend on the new hashing proposal. A signer could do this
under the current proposal.
Really? I thought the structure of allman-01 was to hash the
catenation of some-header-stuff, then the body then the
DKIM-signature stuff. In that case, the body hash is not useful,
at least with any standard hashing API.
You're correct. So the right way to do body hash separately is to
include body hash as separate item (i.e. digest header field) and
sign that within full signature.
Its nice to see you finally come around and adapting further META
signing structure (and you have already adapted canonicalization
method from my draft by now...) of course you will probably never
admit where this is all coming from ...
But to the point, regarding why this signing system is better:
1. It allows to know which part of message has been changed (*)
2. It decreases resources necessary to sign multiple emails
from the same place with with largely same email body
(BTW - this includes mail list processing and is probably
where it would become most useful).
3. It slightly decreases resources for those adding additional
signatures in transit i.e. 3rd party signers (another advantage
for mail list servers I guess...).
4. It allows to do cryptographic verification at the time when
email header has been received even if entire email body
has not been received. So:
a. For system where email header is sent first ahead of
email body (Hector is working on this and many others
proposed it and written drafts on it before too).
b. Similar to above optimization where mail server would start
cryptographic verification immediately when header data is
received while its still continuing to process additional
data during DATA command. For large email on slow connection
(wireless clients, satellite) this could be noticeable
improvement.
There are some other possibilities that are also open for example
its possible to verify signing server's public key even if email body
has been changed. This allows to verify at least certain information
about email which could be useful for a filtering (this can also
be abused by bad guys of course).
Going further META design allows to actually have multiple digests created
in different ways (I never explained about it, but its in my original
design notes) as well as digests with different hash algorithms (this I
decided to move directly to content-digest draft and as you will see in
upcoming version 1).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html