[15082] in cryptography@c2.net mail archive
Re: Non-repudiation (was RE: The PAIN mnemonic)
daemon@ATHENA.MIT.EDU (Ben Laurie)
Mon Dec 29 14:16:03 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 29 Dec 2003 16:02:55 +0000
From: Ben Laurie <ben@algroup.co.uk>
To: Amir Herzberg <amir@herzberg.name>
Cc: Carl Ellison <cme@acm.org>, cryptography@metzdowd.com
In-Reply-To: <6.0.0.22.0.20031225122816.025cb730@getmail.amir.herzberg.name>
Amir Herzberg wrote:
> 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.
What you have here is evidence of origin, not non-repudiation.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
