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