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 [1]. 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 [2]. 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
[3]. 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 [4].
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
