Amir, I am glad to see that you are treating this seriously.
It is always possible to use the term "non-repudiation" for some legitimately defined thing - but I personally would prefer not to use the term because it has been tarred by over a decade of misuse (implying some presumption of liability on the part of a human being as a result of the behavior of a cryptographic key). I wish you luck with your protocols and look forward to seeing them. - Carl +------------------------------------------------------------------+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | | PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ > -----Original Message----- > From: Amir Herzberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 25, 2003 2:47 AM > To: Carl Ellison; [EMAIL PROTECTED] > Subject: RE: Non-repudiation (was RE: The PAIN mnemonic) > > At 04:20 25/12/2003, Carl Ellison wrote: > ... > > If you want to use cryptography for e-commerce, > then IMHO you need a > >contract signed on paper, enforced by normal contract law, > in which one > >party lists the hash of his public key (or the whole public > key) and says > >that s/he accepts liability for any digitally signed > statement that can be > >verified with that public key. > > Of course! I fully agree; in fact the first phase in the > `trusted delivery > layer` protocols I'm working on is exactly that - ensuring > that the parties > (using some external method) agreed on the keys and the resulting > liability. But when I define the specifications, I use > `non-repudiation` > terms for some of the requirements. For example, the > intuitive phrasing of > the Non-Repudiation of Origin (NRO) requirement is: if any > party outputs an > evidence evid s.t. valid(agreement, evid, sender, dest, message, > time-interval, NRO), then either the sender is corrupted or sender > originated message to the destination dest during the indicated > time-interval. Notice of course that sender here is an entity in the > protocol, not the human being `behind` it. Also notice this is only > intuitive description, not the formal specifications. > > > > Best regards, > > > > > > Amir Herzberg > > > Computer Science Department, Bar Ilan University > > > Lectures: http://www.cs.biu.ac.il/~herzbea/book.html > > > Homepage: http://amir.herzberg.name > > > > > > > --------------------------------------------------------------------- > > > The Cryptography Mailing List > > > Unsubscribe by sending "unsubscribe cryptography" to > > > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]