On Fri, 14 Oct 2005, Hallam-Baker, Phillip wrote:
If you want to get huffy about priority
I was not doing it. I was just trying to point out that no serious technical
review or comparison was even conducted at MASS on proposals presented
there before you moved on with one particular one. And so I would not be
surprised if future evolution of DKIM will be towards design of META anyway.
here we implemented the nested
hash construction in AuthSender which was circulated before Domain Keys
was made public.
And I already told you once before that you should not make such statements
unless you can back it up with pointers to documents publicly released at
that time.
-----Original Message-----
From: william(at)elan.net [mailto:william(_at_)elan(_dot_)net]
Sent: Friday, October 14, 2005 7:08 PM
To: Hallam-Baker, Phillip
Cc: herzbea(_at_)macs(_dot_)biu(_dot_)ac(_dot_)il; Stephen Farrell;
ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Re: signature construct
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