Subject: Re: Common misconceptions

From: "David P. Kemp" <[email-masked]>
Date: Mon, 2 Aug 1999 17:07:27 -0400 (EDT)

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

Ed,

I'm not aware of any S/MIME requirements for protocol interactivity.
The information flow in a PKI is all designed to be one-way: certs are
broadcast by the CA, CRLs are broadcast by the CA, and trusted time
is broadcast (over GBS) by NIST :-).

Using the term "challenge-response" to describe a policy- or legal-
driven obligation of a certificate subject to report key compromises
or other status changes to the CA (and I can't tell whether you've
used it for that purpose) would not be accurate.  The information may
flow from the subject to the CA, but it is not in response to any
perceptible challenge.

Using it to describe the interaction between a user and his
private-key-wielding machine (view document, pop up dialog, click OK)
is not completely inaccurate, but that has nothing to do with
interactions between the subject and other parties in a PKI.  Even in
the context of local operations, using the term "challenge-response" to
describe an interaction with a dialog box is mostly inaccurate: in
order to be effective, a response must depend on the challenge, not
be a simple reflexive action.

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

This statement is beyond my comprehension.  If a user is positively
identified (by eyewitnesses, DNA evidence, and his smartcard's
signature in a POS terminal) at a crime scene, he has little power to
repudiate his involvement.  Increasing strength of evidence does *not*
lead to diminishing liability.  There is no challenge-response in this
scenario, yet the liability remains.  Certain company execs might wish
to repudiate their email, but digital signatures on the messages would
not make it easier for them to do so, nor absolve them of liability for
the content of the messages.

If you are attempting to communicate an idea, your choice
of terminology is an impediment to understanding, not an aid.

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 2 Aug 1999 15:24:47 -0700

VeriSign claims to be the de-facto standard
for PKI with S/MIME. American ego aside, you 
obtain VeriSign's validity status on a certificate 
only following a user->CA challenge-response. 
Obtaining a  CRL also requires a handshake - in 
which one accepts the legal conditions of use.

These handshakes bind users/parties to
the governing policy (VeriSign's dispute
resolution rules) which control if
a proof of origin with non-repudiation
service has actually been provided to
nominated parties, or not.

Ed may not have been accurate in
terms of the standards statutes; he was
non-the-less right in today's common
commercial practice.

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Monday, August 02, 1999 2:07 PM
> To: [email-masked]
> Subject: Re: Common misconceptions
> 
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Aug 1999 18:36:00 -0400

Peter,

I agree with David on this one.   VeriSign may choose to employ an approach
to CRL distribution, not mandated by standards, but that is not fundamental
to NR in general, nor for S/MIME in particular.  If anything, this is a
good example of why one should not confuse deployed products/services with
fundamental requirements nor with standards.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 02 Aug 1999 16:48:54 -0700

> I'm not aware of any S/MIME requirements for protocol interactivity.

Me neither ;-) and that is why I said that S/MIME does not provide
adequate grounds for legal non-repudiation -- though it may provide
adequate grounds for policy non-repudiation.

> is broadcast (over GBS) by NIST :-).

Indeed, some CAs broadcast CRLs to some clients. But, CRLs are generally
obtained in a pull model, not provided by a push model as you say.  Information
flow in a PKI is both push and pull -- also when seen by any party. For example,
the subscriber provides information to the CA, that does an online challenge-response
on the subscriber's private-key and then the CA provides information to the subscriber.

In fact, if information flow in a PKI would be all one-way,  there would be no
basis for verification or assurance whatsoever.

> used it for that purpose) would not be accurate.

I used the term "challenge-response" to mean a challenge followed by a
response. Thus, correct.  What I called attention to (in linking to legal
terms) is that neither has to be cryptographic. I also noted that the time that
is allowed to elapse between challenge and response depends on operational
factors--  eg, as I am sure you aware but I just say it here in order to provide
an example, the definition of "real-time" can change from femtoseconds to
months or more, as a function of the system being considered.

> The information may

Validation procedures for the subject's public-key are suggested ( though
not mandated) for example in Section 10 of X.509v3 -- which includes a
perceptible challenge.

> interactions between the subject and other parties in a PKI.

Perhaps my use of it was not clear to you. But I did use the term to mean
what the term means -- as I tried to explain above. I used the term
"challenge-response" to mean a challenge followed by a response in a timely
manner.  I did not mean "dead" data and I especifically excluded it.

> Even in

This is exactly the point. In no way ought challenge-response  be used
as a response that does not depend on the challenge or that is provided untimely.
Which is, however, what happens when a S/MIME user receives a signed
message and "imagines" that the cert has not been revoked so that the msg is
"certainly" valid -- ie, the user refuses to challenge that cert and obtain a
response in the form of a CA's  CRL .  Every time we consult a CA in
order to verify if a cert is included in a  CRL we are performing
challenge-response on that cert's validity  -- in other words, we are verifying it
in a timely manner.

If you accept that reliance must be verifier-centric then you must also agree that
the verifier must be able to verify ;-) and, at will.

> repudiate his involvement.

Thank you for the opportunity to clarify my statement -- which is a general
statement valid in many legal systems (including common and civil law). If
a person is positively identified  by DNA evidence of his sperm on a dress
then the person has full liability to the extent of that identification (say,
1:1000,000)  and to the extent that production of the sample was (most
liked than not) voluntary and within his *power* to avoid.  Likewise, if a
fresh sample of a person's blood is present at a crime scene then this strongly
implies that the person was present and has full liability for that presence
to the extent of the time factor (fresh) and blood identification because production
of the sample at that time and place was (most likely than not) within his
*power* to avoid.

The issue is thus not on power to repudiate *a posteriori* (as you commented)
but power to avoid *a priori*.  Because, *a posteriori* all we have is a close and
shut case.  But, if the person has no power to avoid the act a priori, then there is
likewise no liability -- this is a general principle and one which may illuminate this
discussion accross the global Internet with so many jurisdictions and that is why
I venture to explain it.

Of course, the above comparison between sperm and blood samples already
dicloses a basic difference between both in terms of degree of non-repudiation
which also links to power, in that the second depends on a much lesser degree on
that person's power to prevent it -- a simple needle will do, in  a casual and even
unperceived encounter (a  brief pain).  For example, a sperm stain on a dress
can be much more devastating as evidence (as recent events showed) than a
blood stain, which may even provide no evidence at all (seen the last episode
of  "The Practice"? OJ?)

> Increasing strength of evidence does *not*
> lead to diminishing liability.

I counter-exemplify above; but not in regard to a generic "strength of evidence" but
"effectiveness of power to prevent" -- which however relates to strength of evidence
in regard to non-repudiation.  Again -- more power to prevent an act, more
liability towards non-repudiation of the act.  And, I cannot be liable for an act
which I was utterly powerless to avoid; for example, password authentication
in an open channel using my password (but which anyone could have sniffed
in a previous connection).

And, BTW, this is the reason why S/MIME signatures intuitively carry very
little (if any) weight for non-repudiation -- because the verifier cannot prove if
the message was understood before being signed, if it was the keyholder
that really did sign it, if the keyholder willfully wanted to sign it, etc. I.e., since
the S/MIME protocol denies power for the keyholder to effectively prevent
(ie, a priori) a S/MIME signed message to be sent using his key, then it cannot ask
for liability from the same.

>  There is no challenge-response in this

A large danger exists, if the executives do not have the power to avoid
the act and if every 'whiff' is cast in stone in equal depth. In fact, what
you mention is one more reason not to use such  PKI protocols.

> of terminology is an impediment to understanding, not an aid.

Maybe, but then just because I am using a terminology which is consistent
within a larger community -- not a tongue.  The present confusing use of
non-repudiation in our own circles, and even "true non-repudiation" as I
could read in a security company's press-release describing a PKI in a
US State contract, is what we should all avoid since such choice of terminology
is not only an impediment but also a false statement.  And, reading this list's
exchange, just aids confusion.

Cheers,

Ed Gerck