Non-repudiation (was RE: The PAIN mnemonic)
Carl Ellison
cme at acm.org
Thu Dec 25 12:40:00 EST 2003
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 at acm.org 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 at herzberg.name]
> Sent: Thursday, December 25, 2003 2:47 AM
> To: Carl Ellison; cryptography at metzdowd.com
> 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 at metzdowd.com
> > >
>
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list