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: Daniel Finkelstein <[email-masked]>
Date: Mon, 02 Aug 1999 08:57:22 -0400

Russ Housley wrote:

> 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.

Yes, you're right. I had to think of a few scenarios and paths before I
believed it, but after consideration I see that you could extend your idea
further to include secure protocols/transmissions in general.

Legally speaking (and I hate to do it) this reduces the computing power
required for non-repudiation actions significantly. Much of the path can be
clear, if not all.

--
Daniel Alex Finkelstein
New Technologies
phone   212-383-2951
pager   917-427-1630
fax     212-383-3289
Securities Industry Automation Corporation

---

From: Ed Gerck <[email-masked]>
Date: Mon, 02 Aug 1999 12:00:27 -0700

Daniel Finkelstein wrote:

> Yes, you're right. I had to think of a few scenarios and paths before I believed it, but after consideration I see that you could extend your idea further to include secure protocols/transmissions in general.
>
>
> Legally speaking (and I hate to do it) this reduces the computing
>  power required for non-repudiation actions significantly. Much of
>  the path can be clear, if not all.
>

Yes, and following such notion that challenge-response protocols are not needed for
"non-repudiation" in secure protocols/transmissions  in general you will arrive at the
concusion that one would not need to do even a challenge-response query on the CRL
before you rely on the authentication --  though such is demanded by S/MIME.

In fact, you seem happy to just  assume that  everything is correct, one-shot wise as given
by math.   However, math does not provide non-repudiation by itself and that is why I
call this a  common misconception, and an unfortunate one because it confuses not
only the public but protocol implementers as well.

As I mentioned before (now in summary form):

1. legal non-repudiation is a matter of evidences and respective trusted contexts
as defined by law (eg, cerimony, self-willingness to sign, understanding of what
was signed, etc.) -- not just a matter of one "fact" such as a cryptographic signature;

2. the absence of a legal challenge-response mechanism will always indicate absence
of legal non-repudiation because power is the counterpart of liability in law -- if the
user has no power to deny authentication then the user has no liability derived from
it;

3. such challenge-response mechanism does not have to be cryptographic in order
to attain legal non-repudiation properties  -- eg., can be provided by a witness, by a
log with a mutually contracted third-party (notary, time-stamping agent, etc.), etc.;

4. the freshness of such challenge-response may vary but there is a time limit beyond
which the probability of error becomes unaceptable as a function of other operational
parameters (eg, a signature muster in a bank can be "fresh" for one year or more as
a function of warranty policies and insurance coverage, a CRL can be "fresh" within
the hour, etc.);

5. other types of non-repudiation exist -- eg, policy non-repudiation.  This applies
well when non-repudiation is applied without any implied liability or deniable rights,
which (of course) carries not into legal non-repudiation. For example, an ISP that
asks a user to change the password because it has detected double use (which may
indicate a password compromise by a hacker) is applying its security policy and
is neither causing any harm to the user's rights nor implying user liability.  Thus, it is
legal to do so, even though the ISP considers the password collision non-repudiable
by the user ("I did not give out my password") -- since the ISP relies on its own logs,
which it uses in internal challenge-response.

6. even though non-legal non-repudiation does not need legal challenge-response you
will find that "X non-repudiation" in general depends on "X challenge-response": "legal
non-repudiation" depends on "legal challenge-response"; "policy non-repudiation
depends on "policy challenge-response"; etc.

BTW, list discussions also show that non-repudiation is a matter of challenge-response ;-)

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Aug 1999 17:01:27 -0400

Ed,

Sorry to be so late in responding, but I've been on vacation for a week.

Aside: Could you be related to Bob Jueneman?  In the anals of IETF WG
mailing lists, only he has tended to send such long, detailed messages, as
well as being so involved in the legal aspects of PKI :-}.

This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
Signatures. The technical definition of NR that we use comes from ISO
7498-2.  Paraphrasing (since I don't have the spec in front of me on this
plane flight), NR is defined as a security service employed to prevent a
party in a communication from later denying having participated in the
communication.   Time is not mentioned explicitly, but because the
communication took place at some time, it is an implied component of NR.
Semantic context also is not mentioned explicitly, but because NR is of
concern only when people interact, these issues arise as well.  However,
these latter issues are generally outside the scope of (technical) NR
security services, and thus outside the scope of this WG.  in contrast,
time is amenable to technical NR enforcement measures and is the subject of
this WG, e.g., the TSA document. Note that there is not mention of
liability in this service spec, and it is not a technical NR issue either.

Consider the case in which I receive a signed message, and I want to
prevent the sender of the e-mail fro later claiming that he did not send
the message. I validate the signature, collect the originator's
certificate, his CA's cert, etc. and the relevant CRLs, and go to a time
stamp authority to create a record that all of this data (message, certs,
and CRLs) existed at the time in question.  This NR evidence, in a
technical sense, enables me to prevent the originator from later
repudiating his communication.  There is no reqirement here for any form of
challange-response interaction with the message originator, and in fact a
requirement for such interaction would be antithetical to the way e-mail is
designed to work.

I agree that when push comes to shove, a court will have to decide whether
there is sufficient evidence that a user did, in fact, participate in a
specific communication, or whether there is reasonable doubt that the
communication took place unbeknownst to the user.  While the various state
laws regarding digital signatures will play a role here, they are not the
last word, and not all of them are well written.  (That's a technical
observation of mine, shared by a number of attorneys with whom I have
spoken.)

finally, I appreciate the pointer to you web site, but I have way too much
material to read already.  When it's refereed and published, then I'll look
at your theory of certification.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Aug 1999 15:06:38 -0400

Ed,
	<snip>

>before you rely on the authentication --  though such is demanded by S/MIME.

Wrong, to use a technical term.

	<snip>

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 03 Aug 1999 22:20:15 -0700

> well as being so involved in the legal aspects of PKI :-}.

I have noticed another similarity between myself and Bob Jueneman. We both tend
to reply to all relevant items in an email, even if it tends to disprove a former msg or
shed a different light upon it.

> communication took place at some time, it is an implied component of NR.

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. If NR is "to prevent a party in a communication
from later denying having participated in the communication" as you say above
then we must immediatley agree that NR does not exist and never will.

Further, if I also mention that NR depends on trust and all I hear from you is that
Tina Turner would have said it differently then I must assume that trust is also "implied"
in that definition you use.

Thus, all I am saying is that the definition of NR being used in this WG is wrong
and I don't care who defined it and where you based it -- while I also point out
that ISO is a private organization, which definitions can be used or not and that
none of them is some sort of "international treaty" or even "standard" or "fact".

> at your theory of certification.

I did not point to any web site.  Regarding being "refereed and published"
I guess that is for you to verify.

Cheers,

Ed Gerck

---

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

Ed,

>shed a different light upon it.

An admirable trait!

>then we must immediatley agree that NR does not exist and never will.

We do not agree.  Admittedly, the phrasing above is incorrect in that
anyone can deny anything.  A more accurate statement would be that an
attempt by a party to deny participation in a communication should be
rejected based on evidence provided by NR mechanism.

>in that definition you use.

Trust is not implied in the definition of the service.  The service
definition does not specify a mechanism by which the service is provided
and thus what trust might be required, based on the mechanism, is not a
part of the definition.

>none of them is some sort of "international treaty" or even "standard" or

Sorry that you disagree, but we will continue to use this technical
defintion of NR in this WG.

<snip>

Steve