<html>
At 11:42 07/01/2004 -0800, Ed Gerck wrote:<br><br>
<blockquote type=cite class=cite cite>Jerrold Leichter wrote:<br><br>
> Now that we've trashed non-repudiation ...<br><br>
Huh? Processes that can be conclusive are useful and do exist, I read
here,<br>
in the legal domain. It may not be so clear how such processes can exist
in<br>
the technical domain and that's why I'm posting ;-)<br><br>
> just how is it different from authentication?<br><br>
Using an information theory model, it's clear that authentication needs
one<br>
channel of information (e.g., the CA's public key, the password list) in
addition<br>
to the signal (e.g., a signed message, a username/password entry).
Authentication<br>
rests on the information channel being trusted (i.e., independently
verifiable). In<br>
this model, non-repudiation is different because it needs at least one
additional<br>
out-of-band signal (where authenticated absence of the signal is also
effective).<br>
BTW, that's why digital signatures per se are repudiable -- there's no
second,<br>
out-of-band signal.<br><br>
An additional technical difference is that authentication promotes
"strength of<br>
evidence" while non-repudiation promotes "lack of repudiation
of evidence".<br>
The latter is intuitively recognized to be stronger because a
single, effective<br>
denial of an act can rebuke any number of strong affirmations.<br><br>
This also means, intuitively, that another difference exists.
Non-repudiation<br>
should be harder to accomplish than authentication (you want more, you
need<br>
to pay more). However, to the extent that the process *can be*
conclusive,<br>
non-repudiation may be worth it. Imagine the added costs, time and
hassle<br>
(going back to a real-world comparison) if your bank would have to call
you<br>
to confirm payment for every check you sign? This would be the case
if<br>
paying a check could not be cast as a conclusive process for the bank
(i.e.,<br>
without the possibility of an irrebuttable presumption of
payability).</blockquote><br>
In the UK, but not in other countries, there is a statutory rule which
prevents a bank from debiting a customer's account with a forged cheque
(if you will forgive the British spelling), with only very limited
exceptions. If the customer repudiates a signature, it is for the
bank to prove the genuineness of the signature, or suffer the
loss.<br><br>
My bank has once or twice telephoned to check the genuineness of an
unusual transaction, though this over a period of many years.<br><br>
This is not to disagree with your comments, but to observe that existing
paper systems can work satisfactorily without non-repudiation
rules. There are obvious advantages to some parties in such systems
if it adopts a non-repudiation rule, probably matched with corresponding
disadvantages for others. The change from paper to electronic
systems of course also alters the balance of risks and the approach of
banks to non-repudiation rules.<br><br>
I and colleagues have written about this at:<br><br>
<font color="#0000FF"><u><a href="http://elj.warwick.ac.uk/jilt/00-3/bohm.html" eudora="autourl">http://elj.warwick.ac.uk/jilt/00-3/bohm.html<br><br>
</a></u></font>Regards<br><br>
Nicholas Bohm<br><br>
Salkyns, Great Canfield,<br>
Takeley, Bishop’s Stortford CM22 6SX, UK<br><br>
Phone<x-tab> </x-tab>01279
871272<x-tab> </x-tab>(+44 1279 871272)<br>
Fax<x-tab> </x-tab>020 7788
2198<x-tab> </x-tab>(+44 20 7788 2198) - please note new
fax number<br>
Mobile<x-tab> </x-tab>07715 419728 (+44 7715 419728)<br><br>
PGP RSA 1024 bit public key ID: 0x08340015. Fingerprint:<br>
9E 15 FB 2A 54 96 24 37 98 A2 E0 D1 34 13 48 07<br>
PGP DSS/DH 1024/3072 public key ID: 0x899DD7FF. Fingerprint:<br>
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF </html>