Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt ))

From: [email-masked]
Date: Fri, 30 Jul 1999 10:48:46 -0400

I believe a prompt (challenge) for a password to enable use of the private
key for signing purposes is necessary in some instances. Automatic signing
of a message by software always creates the potential for a repudiation
claim by the sender, either because the software was accessed by an
unauthorized party to effect an unauthorized transaction or because the
authorized party is attempting to defraud by claiming the transaction was
not authorized. In either case, the burden is on the recipient to prove
otherwise.

The need for the challenge depends on how strongly the receiving party
wants to preclude repudiation claims based on the significance of the
transmitted message. A bank receiving a message to transfer funds could
require the challenge for every message. Of course, it could reduce the
risk by requiring verification of the instructions by a second party, but
is unlikely to do this for consumer accounts. A merchant processing a sales
order might not care, since it will process the payment first.

regards,
eric

Challenge-response protocols are not needed for non-repudiation.  Such a
protocol might be used, but it is not required.  For example, a digitally
signed S/MIME message might provide non-repudiation and no
challenge-response protocol is involved.

Russ

At 10:54 AM 7/23/99 -0700, Ed Gerck wrote:

>Jan Nielsen wrote:
>
> > Hi Ed,
> >
> > > which may explain your off-the-point remark.
> >
> > No...I simply skimmed the thread instead of r-e-a-d-i-n-g it.  Sorry
> about that.
>
>;-) short postings cannot reflect content, long postings tend to be unread
>and thus also
>not reflect content -- but, at least, content is there.
>
> > My comments were actually addressing the non-repudiation of a user's
> actions, not digital
> > signatures, in systems which rely on SSL client authentication for user
> authentication as opposed to
> > password authentication.  My point is simply that because of poor key
> management facilities on the
> > client and poor physical security of the device that repudiation of the
> user authentication is more
> > likely with SSL client authentication than with a password system.
>
>Perhaps you still skimmed the thread too much. A password system such as
>what is called
>"weak authentication" in X.509 is not able to provide NR at all, as I
>wrote before:
>
>} ...basically, the reason is that  passwords have no challenge-response
>mechanism.
>} Since a password can be replayed at will, the authenticating party (ie,
>the verifier)
>} is barred from presenting an argument of non-repudiation when passwords
>are used
>} because the verifier could have generated any message all by itself --
>the data is
>} intrinsically corrupted.
>
>So, any client authentication SSL system can provide more *evidences* (and
>I can't
>overstress the importance of this word here) of NR than any weak
>authentication
>(ie, password) system is ever capable of -- in other words, any NR
>evidence is more
>than zilch ;-)
>
>Cheers,
>
>Ed Gerck