I agree very strongly with the 'digest the body separately' approach.

If the signature is a manifest and the message body digest value is a
part of it the receiving MTA can verify the signature before the body is
received. It is also much easier to spot issues like genuine signatures
on modified bodies.

We are not building an access control system here. We are developing an
accountability mechanism. In the control approach the doctine is
'everything that is not explicitly permitted is denied'. In the
accountability approach the doctrine is 'allow anything unless it is
considered likely to be harmful'.

So in the control approach it is an absolute no-no to accept a message
if the body is modified

In the accountability approach we can IF WE CHOOSE consider shades of
grey. What we are first and foremost interested in is authenticity.
Integrity is a serparate and less important issue.


> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir Herzberg
> Sent: Friday, October 14, 2005 8:09 AM
> To: Stephen Farrell
> Cc: [email protected]
> Subject: [ietf-dkim] Re: signature construct
> 
> Stephen Farrell wrote:
> > 
> > Folks - was Earl's idea considered before? 
> I must admit, I thought this is what we do... definitely, we 
> _should_ do....
> 
> <skip>
> > 
> > PS: Just so's I can reconstruct it for myself later, the construct 
> > might end up something like:
> >   body-hash = Hash1(nonce, body)
> I think more like:
>    body-hash = Hash(C14n(body))
> i.e.: no nonce (a nonce in input to hash ? I think may make 
> it easier to find collisions, not harder...); and explicitly 
> apply the (specified) C14n alg. to the body, don't mix it 
> with the crypto-hash operation.
> >   sig-bits  = Private-key(Hash2(nonce,header-stuff, body-hash))
>    sig-bits  = Sign_s(headers)
> Where:
>      s is the private signing key of the DKIM-signer (sender, 
> sending MTA, etc.)
>      Sign is the selected signature algorithm, including any 
> hash compuation which is part of the signing algorithm, e.g. 
> RSA_SHA1, ECDSA_256
>      headers is the list of included headers, and 
> normally/always includes body-hash (why specify it separately?)
>      nonce again removed for same reasons...
> 
> --
> Best regards,
> 
> Amir Herzberg
> 
> Associate Professor
> Department of Computer Science
> Bar Ilan University
> http://AmirHerzberg.com
> Try TrustBar - improved browser security UI: 
> http://AmirHerzberg.com/TrustBar
> Visit my Hall Of Shame of Unprotected Login pages: 
> http://AmirHerzberg.com/shame
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
> 
> 

_______________________________________________
ietf-dkim mailing list
http://dkim.org

Reply via email to