Subject: Re: Non-Repudiation

From: "Aram Perez" <[email-masked]>
Date: Wed, 04 Aug 1999 14:08:48 -0700

David Kemp wrote:

>> From: "Aram Perez" <[email-masked]>
>> 
>> How can setting the NR bit ensure that there isn't a "failure in any one of
>> those areas"?
>
> It can't, obviously.  The NR bit is a tiny amount (one binary digit's worth)
> of information imbedded in a technical protocol which can be used to
> signal a person's intent, no more, no less.

That assumes the person was notified. How does the NR bit give that
assurance when no one knows what software/system the person is using.

>
> If there is NO failure in any of the listed areas, and NO failure in
> areas not listed (what the user saw is what he signed, cert is
> bound to signature, etc), then the fact that the user has chosen to use
> a keypair with the NR bit set instead of a keypair with the NR bit
> clear MAY provide some evidence of intent to the legal process.
> Or it may not, if so determined by the ABA, the courts, and the
> legislatures.

How do you provide that assurance of "NO failure"? I very much doubt that a
CA is going to give that assurance. And I doubt that my mom, as smart as she
is, is going to know when to pick the keypair with the NR bit set.

>
>
>> Steve, so many things are "implied" -- that one needs to be careful not
>> to have "implied security" as well.  What I mean is that we need clear
>> and well-defined concepts, if we want clear results.
>
> The technical concepts really aren't that controversial:
>
> 1) Symmetric cryptography involves shared secrets, and so cannot be
> used to distinguish between parties in a communication.

This is not correct. In a previous job, we built a system using DES where
party A could only sign (using ANSI X9.9) and party B could only verify.
With party A, all the keys were kept on hardware tokens and required dual
control: a Security Administrator (SA) to start the system and the Signing
Offer (SO) to enable the signature process. The signing key was the
combination of the SA and SO keys. A similar setup existed at party B. With
this system, I could prove (in a court of law) that the signature was
generated by party A and not by party B.

>
> 2) Asymmetric digital signature algorithms have applications (such as
> data integrity and entity authentication) other than providing the
> electronic analog of a handwritten signature.

But asymmetric digital signatures are not a one-to-one electronic analog of
a handwritten signature. And they certainly do not have the legal framework
that handwritten signature have.

>
> 3) Asymmetric private keys may be afforded differing levels of
> protection, and information in public certificates can communicate to a
> verifier the intended application of a specific private key.

But who controls the "intended application of a specific private key"? It is
easy to write a general purpose crypto library that enforces the
keyEncipherment bit, but how do you enforce "the user's intent"? How does
the crypto library enforce that the user only uses a keypair with the NR bit
set for signing a contract? The goal of the CA is to bind a user' identity
to a public key, not to quantify the "user's intent".

>
> What is the goal of this discussion: to argue that there is no such
> thing as "technical non-repudiation" as represented by the above three
> items, or that the name of the nonRepudiation keyUsage bit should be
> changed, or that the NR bit serves no purpose in any conceivable
> environment?

Personally I think that at minimum, the name should be changed but that
would require a change to X.509. I would prefer that IETF deprecate its use.

>
> The IETF obviously does not claim that a technical mechanism can
> "prevent a party in a communication from later denying having
> participated in the communication" - anyone can deny anything, and
> prisons are chock full of innocent bystanders.  The IETF does claim
> that the products under its control (protocol specifications) will not
> be the weak link in the chain of evidence used to refute such a
> denial.

It may "not claim" but it certainly give the impression (otherwise I don't
think there would be so much discussion on the issue). I don't see how the
NR bit makes the "link in the chain of evidence used to refute such a
denial" any weaker or stronger.

>
> There are plenty of links in a system designed to be secure - one that
> is designed exclusively to prevent an adversary from violating your
> self-defined policy, totally ignoring legal concepts such as intent and
> burden of proof.  If an IETF protocol specification is not the weak
> link in this constrained environment, then it will certainly not be the
> weak link when dozens of other legal grounds for successful
> repudiation (weaker links) are introduced.

Agreed.

Regards,
Aram Perez

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 1999 12:26:17 -0400

Aram,

>generated by party A and not by party B.

This is a misuse of the term "sign" and it not consistent with the language
of X9.9.  X9.9 specifies a MAC, and a MAC is not a signature, period! While
the banking community has long treated MACs as though they provide
technical support for NR, we all understand that a MAC is a poor technical
basis for such a service.  In your example, collaboration by the SA and SO
at the receiver could generate a MAC indistinguishable from that produced
by the sender.

Steve