ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: signature construct

2005-10-14 16:17:28

Interesting how this is being commented on now and not when the proposal
for such system (i.e. META Signatures) actually came in over 9 months ago.
Remember that separation of body digest from header signature is the core part of that design; additional non-syntax core approaches taken are that its designed to be bound to particular specified email identity (like Sender header field) rather then vague new one as done at DKIM and that it designed to work with multiple authorization algorithms and not only public key in dns.

On Fri, 14 Oct 2005, Hallam-Baker, Phillip wrote:

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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Amir Herzberg
Sent: Friday, October 14, 2005 8:09 AM
To: Stephen Farrell
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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

<Prev in Thread] Current Thread [Next in Thread>