Yes. I know Earl and I touched base with it in going over the possible error states, including possible Authentication-Result reporting structure.
http://mipassoc.org/pipermail/ietf-dkim/2005q3/000285.html I personally saw it as a way to possibly separate what was broken or failed: - The DKIM signature policy, and/or - The body integrity. This will certainly help in the area of multiple signings with downlinks, middle ware systems tampering with mail distribution, if only from one standpoint: providing a different (less severe?) warning: So instead of having a generic statement: [RED] WARNING: This Message failed DKIM signing it might help provide a more detail reason [YELLOW] WARNING: DKIM Policy ok, but BODY has changed. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Earl Hood" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Friday, October 14, 2005 7:08 AM Subject: signature construct (was: Re: [ietf-dkim] DKIM BOF -- draft charterand agenda) > > Folks - was Earl's idea considered before? I think there's > the basis for a good thing there - something that allows > an intermediary to check the math of the signature but > without processing the entire (potentially huge) message. > > However, this is something to think about later since I guess > its really an optimisation (albeit perhaps a v. nice one) > though it does also help when mangling happened, even if at > the expense of a little more complexity in terms of the > data structures we require. > > Stephen. > > PS: Just so's I can reconstruct it for myself later, the construct > might end up something like: > body-hash = Hash1(nonce, body) > sig-bits = Private-key(Hash2(nonce,header-stuff, body-hash)) > The headers would then have to contain the nonce, sig-bits and body > hash (as well as our other stuff). I guess in principle hash1 and > hash2 could differ, e.g. in terms of c14n, but that might start > getting over complex. > > Earl Hood wrote: > > Another example: The data "protected" is represented as a hash value > > parameter. The signature is only of the DKIM-Signature field, nothing > > else. This allows quicker failures on cryptographic signature check > > since the whole mail message is no longer required. Only if the > > cryptographic signature check passes does the complete message need > > to be processed to check the data hash value. > > > > Also, a DKIM-Signature field can still be partially validated even > > if the message data is mutated to invalidate the data hash. DKIM, > > as it is defined now, cannot do this. This clearly allows us to know > > when a domain puts in a valid signature during the transmission life > > of a message, even if message mutation causes full validation to fail > > for the signature (i.e. the data hash comparision fails). > > > > There are also logging and audit advantages of isolating the > > cryptographic signature to just the DKIM-Signature field. > > > > --ewh > > > > > > _______________________________________________ > ietf-dkim mailing list > http://dkim.org > _______________________________________________ ietf-dkim mailing list http://dkim.org
