signature construct (was: Re: [ietf-dkim] DKIM BOF -- draft charter and agenda)

[Stephen Farrell]

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
> 
>