If you want to get huffy about priority here we implemented the nested hash construction in AuthSender which was circulated before Domain Keys was made public.
> -----Original Message----- > From: william(at)elan.net [mailto:[EMAIL PROTECTED] > Sent: Friday, October 14, 2005 7:08 PM > To: Hallam-Baker, Phillip > Cc: [EMAIL PROTECTED]; Stephen Farrell; [email protected] > 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: [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
