On October 13, 2005 at 15:19, Stephen Farrell wrote: > Concrete example: if the dkim wg decided to move the DKIM-signature > field as input to hashing from after the body to being the first > input (e.g. so we could perturb hashing with some of our own > randomness), then that'd be incompatible on-the-wire, but no > problem for migration.
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
