RE: Non-repudiation (was RE: The PAIN mnemonic)

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         cme@xxxxxxx      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:amir@xxxxxxxxxxxxx] 
> Sent: Thursday, December 25, 2003 2:47 AM
> To: Carl Ellison; cryptography@xxxxxxxxxxxx
> 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
> > > majordomo@xxxxxxxxxxxx
> > >
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@xxxxxxxxxxxx