In response to Ed and Amir, I have to agree with Carl here and stress that the issue is not that the definition is bad or whatever, but the word is simply out of place. Repudiation is an act of a human being. So is the denial of that or any other act, to take a word from Ed's 1st definition.
We can actually learn a lot more from the legal world here, in how they solve this dilemma. Apologies in advance, as what follows is my untrained understanding, derived from a legal case I was involved with in recent years . It is an attempt to show why the use of the word "repudiation" will never help us and will always hinder us. The (civil) courts resolve disputes. They do *not* make contracts right, or tell wrong-doers to do the right thing, as is commonly thought. Dispute resolution by definition starts out with a dispute, of course. That dispute, for sake of argument, is generally grounded in a denial, or a repudiation. One party - a person - repudiates a contract or a bill or a something. So, one might think that it would be in the courts' interest to reduce the number of repudiations. Quite the reverse - the courts bend over backwards, sideways, and tie themselves in knots to permit and encourage repudiations. In general, the rule is that anyone can file *anything* into a court. The notion of "non-repudiation" is thus anathema to the courts. From a legal point of view, we, the crypto community, will never make headway if we use this term . What terms we should use, I suggest below, but to see that, we need to get the whole process of the courts in focus. Courts encourage repudiations so as to encourage all the claims to get placed in front of the forum . The full process that is then used to resolve the dispute is: 1. filing of claims, a.k.a. "pleadings". 2. presentation of evidence 3. application of law to the evidence 4. a reasoned ruling on 1 is delivered based on 2,3 Now, here's where cryptographer's have made the mistake that has led us astray. In the mind of a cryptographer, a statement is useless if it cannot be proven beyond a shred of doubt. The courts don't operate that way - and neither does real life. In this, it is the cryptographers that are the outsiders . What the courts do is to encourage the presentation of all evidence, even the "bad" stuff. (That's what hearings are, the presentation of evidence.) Then, the law is applied - and this means that each piece of evidence is measured and filtered and rated. It is mulled over, tested, probed, and brought into relationship with all the other pieces of evidence. Unlike no-risk cryptography, there isn't such a thing as bad evidence. There is, instead, strong evidence and weak evidence. There is stuff that is hard to ignore, and stuff that doesn't add much. But, even the stuff that adds little is not discriminated against, at least in the early phases. And this is where the cryptography field can help: a digital signature, prima facea, is just another piece of evidence. In the initial presentation of evidence, it is neither weak nor strong. It is certainly not "non-repudiable." What it is is another input to be processed. The digsig is as good as all the others, first off. Later on, it might become stronger or weaker, depending. We, cryptographers, help by assisting in the process of determining the strength of the evidence. We can do it in, I think, three ways: Firstly, the emphasis should switch from the notion of non-repudiation to the strength of evidence. A digital signature is evidence - our job as crypto guys is to improve the strength of that evidence, with an eye to the economic cost of that strength, of course. Secondly, any piece of evidence will, we know, be scrutinised by the courts, and assessed for its strength. So, we can help the process of dispute resolution by clearly laying out the assumptions and tests that can be applied. In advance. In as accessible a form as we know how. For example, a simple test might be that a receipt is signed validly if: a. the receipt has a valid hash, b. that hash is signed by a private key, c. the signature is verified by a public key, paired with that private key Now, as cryptographers, we can see problems, which we can present as caveats, beyond the strict statement that the receipt has a valid signature from the signing key: d. the public key has been presented by the signing party (person) as valid for the purpose of receipts e. the signing party has not lost the private key f. the signature was made based on best and honest intents... That's where it gets murky. But, the proper place to deal with these murky issues is in the courts. We can't solve those issues in the code, and we shouldn't try. What we should do is instead surface all the assumptions we make, and list out the areas where further care is needed. Thirdly, we can create protocols that bear in mind the concept of evidence. That means we use various techniques such as signed receipts, logs, sharing of records and chains of signatures to create pieces of evidence. We use the careful techniques of protocol design to marshal sufficient evidence of strength to make it easy to resolve any questions; before they become disputes, and ideally, before they leave the protocol! And, when these questions do become disputes, we try and make it easy (read: cheap) to present strong evidence to those resolving any dispute. iang  It was highly instructive, and I'd almost recommend all to get in trouble with the courts at least once in your lives, if only it wasn't so darn destructive of ones life!  It's even worse than the signature. At least there is some resemblance between the process and result of a digital signature and a legal signature. With (non)-repudiation, however, cryptographers are saying that the entire meta-concept of the court is wrong.  Courts actually have a rule, that, only claims made up front can be heard - so you had better get your repudiations up there in the beginning!  This is a characteristic of the no-risk school of cryptography, but even economic cryptographers fall into this trap with regularity. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]