At 10:48 AM 6/25/2001 -0400, James M Galvin wrote:
>My clue is just fine, but thanks for your concern. Last time I checked
>my favorite desktop dictionary to repudiate meant to reject as
>unauthorized, you know, not a party to the contract. Non-repudiation
>would mean I can't reject it as unauthorized, you know, that I can not
>say I am not party to the contract.
"Unauthorized" does not mean "not a party to the contract".
Also, you seem to be confusing shifting evidentiary burdens with prevailing
on an issue at trial. Or does "non-repudiation" now mean we won't bother
with trials any more?
One of the basic problems with "non-repudiation" is that its proponents
can't even which general body of law it exists within - e.g., is it an
aspect of contract law? an evidentiary rule? a rule of civil or criminal
procedure? Does it satisfy an existing burden of production, or persuasion
.. or create a new one? Does it establish a rebuttable or a non-rebuttable
presumption, or merely a permissible inference?
It's not at all clear to me that it's had the benefit of any real attention
from anyone with a legal education, much less a careful explanation of how
it'd fit into existing legal frameworks, and whether it rests upon existing
statutes or caselaw or if it requires new legislation to take effect.
If you are aware of this scholarship, I would certainly appreciate a
reference to it.
> Would you please explain to me how
>whether or not I am in fact an actual party to the contract has nothing
>to do with US contract law?
Oh, that's a question that's very important to US contract law, which is
why courts aren't about to abandon that question - or the admissibility or
evaluation of evidence relevant to that question - to the result of some
Even if it were to do so, how would the finder of fact learn of the result
of the computations? By oral testimony? In court?
>Non-repudiation is not a legal concept in and of itself (and I never
>said it was), but it is important to any lawyer who has to deal with any
>dispute involving electronic information (which is what I meant although
>perhaps not as well stated before).
No, it's not. It's a silly distraction that raises at least as many
questions as it purports to answer, and it doesn't even answer the hard
questions about contract formation. As Jon Callas pointed out, the attack
discussed here is really a semantic attack on the meaning of a message, not
its construction or delivery. Disputes about contracts are not likely to be
about which words are included in a contract (not if it's a fully
integrated contract, anyway - and if it's not, non-repudiation and digital
signatures are worse than worthless) - they're likely to be about what
those words mean, and whether or not the parties' behavior was consistent
with the meanings of the words . . . or what the appropriate relief is, if
one or more parties breached.
Cryptography will never fix that problem. You will need humans to read the
words and listen to arguments and arrive at a reasonable understanding of
their meaning - and to hear testimony and look at evidence and decide who's
right and who's wrong. There's no way to short-circuit all of that with a
little extra math.
"Not a legal concept" is a critically important distinction -
non-repudiation is a feature or service which has no corresponding demand
or application in the real world. Yes, it is possible to imagine parallel
universes where something like that would be neat. But this isn't one of them.
> It is a security service that is
>important if not essential to electronic transactions that are
>vulnerable to legal disputes (perhaps more so in the US than anywhere
>else, but hey I'm not a lawyer so don't ask me).
I am a lawyer who's worked on a product for electronic transactions which
used digital signatures - and I can tell you that there's very little
customer interest and no real-world courtroom/litigator interest or relevance.
Non-repudiation might work in a lower-stakes or less-due-process
environment like an in-house dispute resolution system, where there's no a
priori expectation of fairness or reasonableness, and where one actor can
mandate use of the system - e.g., if you have a signature from your manager
on your vacation request, you get to take time off, even if it's later
shown that the IT guy stole the keys off of a backup tape and signed a lot
of vacation requests, because the finality of the decision/result is more
important to the company than the expense of internal dispute resolution.
On the other hand, I really can't identify a single application where I
think that'd make sense - implementing a PKI system robust enough to
support non-ludicrous non-repudiation is very expensive, and I don't think
there'd be a lot of institutional resolve behind the "non-repudiation" rule
of law if in fact the PKI system were misused - e.g., the IT guy gives
everyone 3 months of vacation .. are they really going to pay everyone to
stay home for 3 months? Are they really going to promote the IT guy to CIO
and give him a corner office and a big raise, just because he got ahold of
the Board of Directors' keyrings? Of course not.
So when, exactly, is it useful? As far as I can tell, it's a tradeoff of
certainty for accuracy in decision-making - e.g., we'll have the legal
system enforce judgements based on evidence which we all agree is (in some
cases) false, but we think that's a better result than we'd get if we dug
deeper into the facts, because we like speed and certainty over a slow,
confusing litigation process.
> It would also be fair
>to say it is more important today than it was 12 years ago, when PEM was
>first getting popular (for as popular as it got). For that reason, Don
>can call it a "flaw" if he wants to, but I prefer to think of it as the
>"next bite" of the secure email problem which we could reasonably do
>something about; it's certainly not a hard problem technically or a huge
>oversight that got no attention at the time.
It sounds like the real problem is the marketing hype that's accompanied,
and continues to accompany, PKI products - e.g., "buy this and you'll win
all your court cases!" "nobody will be able to escape a contract with you!"
"if people sign something, they'll have to perform!" "you can be sure of
who you're talking to" - etc.
The flaw discussed here is an example of a case where a cryptographic
product fails to live up to the expectations of its users, because they
expected some sort of cryptographic magic to make sure that their
communications aren't used in an unexpected fashion - and that flaw looks
especially dangerous if we assume that there's also some sort of legal
magic which means that people who have digital signatures win (or lose) in
We can cure the mismatch between expectation and delivery by changing the
expectation, or changing what's delivered, or both.
Immediately, we can and should change user and developer expectations - we
should distingiush between means (like cryptography) and ends (like
security, or reduced risk), and remember that good techniques reduce risk
and increase security, but don't create a state of perfection.
We also need to pay attention to the use of terminology when crossing
domains of expertise - e.g., computer science and computer security people
make messes when they make assumptions about law (like the
"non-repudiation" distraction, and, generally, confusion about the
difference between evidence and legal arguments), and legal people make
messes when they make assumptions about technology (like the ambiguity
regarding ephemeral copies and copy ownership for computer software, as
discussed in 17 USC 117(a)).
Eventually, maybe we will build a system of legal rules and technological
artifacts and processes that interoperate to create, preserve, and
represent evidence of facts which may be of importance - but we haven't
done that yet, at least not in the US. I gather that the UK may have
adopted some of the wilder "non-repudiation" ideas which have been
suggested and I think it's a grave mistake - both for the technologists who
proposed that sort of thing, and for the lawmakers who were foolish enough
to accept the gambit.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]