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: Thu, 22 Jul 1999 23:49:56 -0400

Ed Gerck <[email-masked]> on 07/22/99 02:45:21 PM

To:   Stephen Kent <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>
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))

Ed Gerck wrote:
(snip)

No, not far afield but is indeed a new legal issue introduced by certificates --
as you
asked for in your question  -- "If I use certificates to authenticate users, in
lieu of
passwords, why are there any new legal issues?"

> >So, this one is not a red herring at all but a red sign of warning. It is
> >a common misconception, though, to assume that all authentication procedures
are
> >legally equivalent -- but, they simply aren't and for several legal reasons.
>
> What you said above does not seem to support this conclusion.

As above, it is 100% supported -- certs introduce at least two new legal issues
that simply do not exist for passwords. This discussion also seems to support my
opinion that it is common to think that all authentication procedures are
legally
equivalent, albeit incorrect.

> >> Part of the problem is that people have been led to believe that a
> >> PKI must support non-repudiation, which generates a large number of valid,
> >> legal concerns.
> >
> >Part of the problem is that PKIX also has a so-called non-repudiation bit ;-)
>
> Yes, and it is used to allow a CA to distinguish between a cert issued for
> signing data for auth vs. signing data for NR.  What's wrong with that?

Nothing but the fact that it does not provide for non-repudiation, so it is IMO
a misnomer. At most, it could provide for "cooperative non-repudiation" in
which the signer declares it will not repudiate and then willfully abides by
such
declaration as long as it suits its purposes -- but which declaration, arguably,
could
be better placed and substantiated  for context in the document itself, never in
the
PKIX certificate.

[Tom Gindin]   A court could, and might well, take notice of the presence of the
non-repudiation bit in a certificate to help determine whether an attempt to
repudiate an electronically signed contract (especially one for which a
consideration was received) could succeed.  Of course, there are no real
guarantees on what a court will do with hardly any precedent or legislation.

> >>  However, use of a PKI to support SSL, IPsec, and S/MIME
> >> (at least on an intranet basis) does not raise such issues, yet promises to
> >> improve security and to make life easier for users.
> >
> >"improve security" and "make life easy for users" seem to be antinomies in
all
> >systems -- security is counter to functionality, as a general principle.
> >So, I believe that last phrase is an empty promise though it may look good in
> >marketing materials.
>
> One example comes to mind in the context of SSL client certs.  They are
> much preferable to use vs. remembering different names and passwords for
> each web site that requires a login, and the security afforded by client
> certs is much better than passwords, even if the corresponding private keys
> are stored on my disk.

Take my previous example, but with SSL client certs -- go to a hotel and try to
use it. Either you can't (the SSL client cert is in the desktop machine at your
office) or you have to take it with you... and your laptop also (since hotel
machines
cannot be relied either to be compatible or to be free from malicious software).
Thus, you now have added certificate storage liability and laptop theft
liability.
Which hassles a password (less secure) does not have.  And, no authentication
(even less secure) has even less hassle.

What I am saying is not that passwords are "better" than certificates -- such
comparison
would be even senseless. But, simply, that adding security implies decreasing
functionality
to some extent -- so that to "improve security" and to "make life easy for
users" seem to
be antinomies in all current systems.  Further, it is IMO very close to a true
antinomy
like "slavery" and "freedom".  A secure system must include some amount of
hassle to a
user-- the point is to make it bearable for what it provides, not to deny that
the hassle
exists or, even, that it is less.

[Tom Gindin]   Security and usability are not close to being an antinomy.  They
are competing goods, and they are subject to a set of trade-offs.  It is true
that for an optimally designed product one probably can't improve one of them
without worsening the other, a condition like Pareto optimality in economics.
However, not every product is on this optimal trade-off frontier, and the
frontier moves outward over time.  I hope that this WG is doing some things to
move it outward.

So, facing this issue might be a better strategy -- as I commented in another
reply,
marketing materials notwithstanding.

> >Another common misconception.
> >
> >> I disagree with your statement that a certificate in software binds a
> >> system, vs. a user.
> >
> >I fail to see how you can possibly disagree with Eric's statement.  Trust
> >is not distributive in the social sense (ie, not associative in the
mathematical
> >sense),..
> >..
> >So, you cannot affirm that a cert binds a user -- which user?  At most,
> >you can affirm that your challenge-response logs, traceroute, timestamps and
> >whatever may indeed point to a system that  you believe  has authenticated it
--
> >but only as an evidence, not as a fact.
>
> I have no idea what are you talking about? The statement I questioned was
> an assertion that a cert with a privcate key protected via software did not
> provide a suitabel basis for user, vs. system, authentication.  Your
> argument above does not seem to bear on that at all.

Your statement was correctly perceived (you replied to Eric: "I disagree with
your
statement that a certificate in software binds a system, vs. a user.").  And, I
pointed
out that, as Eric mentioned, I also have the view that a cert with a private key
protected via software does NOT provide a suitable basis for user, vs. system,
authentication.  Clearly, if the cert with a private-key is "protected via
software"
then breaking such protection only involves breaking the verifier's trust on
that
software/system without the verifier knowing it, not the verifier's trust on the
user.

And, I explained this conclusion by noting that trust on a private-key
certificate is
not distributive (ie, not associative in the mathematical sense) to trust in the
software.
So, you cannot affirm that a cert in software binds a user -- which user?  At
most,
you can produce evidence that  the system has authenticated a transaction -- but
since the software (S) is between the certificate (C) and the user (U) ,  you
have:

   (U*S)*C <> U*(S*C)

which means that the User can first trust the Software and then trust the
Certificate to
correctly either authenticate or deny authentication according to the password
transmitted
from the User by the Software, but if the User knows that the Software trusts
(ie, relies
upon for its actions) some aspect that the Software can exploit in the
Certificate (for
example, the Certificate always requires the same password) then the User may no
longer
trust the Certificate.  I hope it is clearer.

> >> Yes, smart cards are preferable, but if the choice is
> >> between a password and a certificate (and private key) with software
> >> cryptography, I see no reason not to adopt the latter,
> >
> >One reason is to deny unwanted non-repudiation.  Another is to reduce
> >cert storage liability. Etc.
>
> I was talking about certs used for auth, not NR, making the comparison to
> passwords meaningful.

I understood you were talking about choices. To be clear -- if the choice is
between
a password and a certificate (and private key) with software cryptography, then
I
see several reasons NOT to adopt the latter; unwanted NR and cert storage
liability
being just two examples.

> >> and I certainly see
> >> no reason to declare that the latter is not a user (vs. system)
> >> authentication mechanism.
> >
> >as above, trust is not distributive (socially).
>
> Again, your argument seems orthogonal to the issue I was addressing.

Perhaps, it is clearer now -- see above. Because trust is not distributive,
there are several reasons to declare that the latter is not a user (vs. system)
authentication mechanism.

> >> Finally, why do you say that an issuer cann[ot]
> >> associate a security policy with a certificate?  We have the syntactic
> >> means to do so as part of the standard.
> >
> >In which language? In which legal system? In which jurisdiction?
> >Syntax does not answer these (and other) questions at all -- and yet,
> >any of them makes the problem overly-variable in comparison to the
> >given syntax.  All security policies (eg, CPS) need to call themselves
> >"mutually exclusive" (otherwise I could just devise a security policy that
> >would render yours ineffective) and yet they can all be different since
> >security policies per se are not defined as part of the standard, just
> >referred in the standard as we all know.
>
> Hard copy contracts specify the language and jursidiction of
> interpretation, and cert policies can do the same.

But, the relying-parties are NOT privy to the contract between a CA
and a subscriber.  So, r-ps may completely disagree with the language,
the legal system and the jurisdiction for the contract's interpretation -- and
yet,
this has no bearing either on the CA or on the subscriber.

[Tom Gindin]   While the relying parties are not a party to the contract between
a CA and its subscriber (and perhaps not even privy to it), the CA's Certificate
Policy Statement is public and a relying party might some day be able to use it
in deciding whether to rely on a certificate.  Greater standardization in the
language would be a great help, of course.  The CA-subscriber contract, as
opposed to the CPS, ought to have no effect on the RP's rights.

> The fact that the policy is incorporated by use of an OID does not affect
this.
> Again, I fail to see the point of your comments.

The point is that (answering your question above, to Eric, "why do you say that
an issuer
cann[ot] associate a security policy with a certificate? "),  an issuer cannot
strongly
associate a security policy with a certificate and such association must be
overly-
variable in several aspects because such association would have to be valid
in first line to r-ps -- who are not privy to the contract between the issuer
and the
subscriber.

Of course, the issuer may associate whatever it wants -- but not in relationship
to
a party (eg, the r-p) that is NOT privy to the contract and that has other
rights from
the law regime of its jurisdiction (the right to deny an electronic contract
being
just one of them).

[Tom Gindin]   The relying party is not privy to that contract, but it has been
notified of the CPS - which gives the CPS similar legal standing to a
disclaimer, although probably less such standing because it isn't usually read
by a human.  Many jurisdictions limit the scope of disclaimers, too.

> >> Do you mean that we don't have
> >> appplications that pay attention to the policy extension?
> >
> >Policy extensions are not infused with meaning, they are simply pointers
> >to a meaning -- which meaning can be  inacessible to the application,
> >outdated, invalid in that jurisdiction, etc.
>
> But one configures an application to accept of rejects certs based on
> policy IDs, based on a human being having read the policy and made a value
> judgement.  We dopn't expect applications to make these decisions, but
> rather to enforce the decisions already made by users or system
> administrators.

Take the case of two policies (eg, two different CAs) that have been accepted
in separate based on value judgements by a sysadmin.  Suppose these two policies
require the user to check any cert with a CRL (eg, as CA policies do) at the
respective CA's site before relying on a cert.  However, the user's browser
cannot check CRLs (eg, as current browsers do not check).  Now, one of these
policies includes insurance coverage against the use of revoked certs when the
browser is barred by design to check CRLs.

Now, can you tell me where is this meaning accessible to the application?  I.e.,
accesible to the user -- after the sysadmin has acepted the policies? Or, will
the browser simply ignore this and readily accept any cert signed by either CA?

Of course, the above example can be made with other attributes.  And, that is
why I wrote that policy extensions are not infused with meaning, they are simply
pointers to a meaning -- which meaning can be  inacessible to the application.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Fri, 23 Jul 1999 13:38:29 -0700

[email-masked] wrote:

> Ed Gerck <[email-masked]> on 07/22/99 02:45:21 PM wrote:
>
> comparison would be even senseless. But, simply, that adding security implies decreasing
> functionality to some extent -- so that to "improve security" and to "make life easy for
> users" seem to be antinomies in all current systems.  Further, it is IMO very close to a true
> antinomy like "slavery" and "freedom".  A secure system must include some amount of
> hassle to a user-- the point is to make it bearable for what it provides, not to deny that
> the hassle exists or, even, that it is less.
>

Your vision is IMO sufficiently close to mine for the purposes at hand in this WG. Further,
our visions do not seem to be antinomies themselves ;-) so we can talk about a common
ground, can't we?

Perhaps, the common ground in both visions is to realize the following:

1. More security is not necessarily beneficial to the user.
2. More security will, more often than not, be a hassle for the user; or
2'. Any amount of security will tend to make life harder for users.
3. The purpose of a security protocol is to make security tolerable to users in regard to what it delivers.

What we may still disagree on (but perhaps, just as a matter of degree) is in the fourth item:

4. "Security" and "easier life for users" are simply opposites.

Now, rather than use the "Pareto model" (and its faults), when I want to be more precise I
use in this case the mathematical concept of "conjugate variables" and say that the product
(1/S) .(1/F) > = K describes the relationship between S = "security" and F = "functionality"
in relationship to a constant K>0  valid for a system (of course, in average terms), such that
any increase in S above the limit of S <= (1/F.K) *within that  system* (i.e., for a given K)
must imply a decrease in F, and vice versa .  Moreover, I have reasons to believe that K
is very large in most systems we have today -- so that any amount of S strongly decreases F.

One criteria of "best design" in this formalism is attained when S = F (i.e., when  security and
functionality jointly have their maximum values) -- and which I call a "compact design".
Working with compact designs, one can easily see that decreasing K (with a new system)
directly results in improving *both* security and functionality -- and, is the only  way to do
so above the limit of S <= (1/F.K). The "moving  frontier" you describe is simply given by
decreasing K to K' -- as the system improves to a  new system, but where, likewise, the
"law" (1/S) .(1/ F) > = K' will still hold.

In order to achieve qualitative reductions in K, the design criteria for a new system should be
one (pls. see the relevant URLs) where the concept of Internet security needs to evolve
from "confinement" to "understanding" --  i.e., where security is a mode of understanding and
confinement is but a tool to security.  Indeed, confinement can be useful -- and that is why I
call it a "tool to security" in a design.  "Chinese wall", or "Maginot line" policies are all useful
tools, but if they become the  goal of security then it becomes quite easy to circumvent them
as their historical counterparts showed.  Current fire-walls are also useful, but reliance on
them has actually brought to the front the need for intrusion detection tools -- which is much
more in line with "understanding" than with "confinement".

Because I perceive K to be very large in current systems, I perceive that security and
functionality are close antinomies in current designs -- however, if K would be reduced
then security and functionality would no longer be close antinomies. Let me exemplify.  I
have applied the same mathematical concept here and elsewhere before, for example to
describe the relationship between security (S) and privacy (P) --  which I also consider to
be conjugate  variables,  but such that (1/S) .(1/P) >= Q where Q << K, as I can perceive
in the systems we currently have.  Thus, security is (currently) much closer to be an antinomy
 to functionality than to be an antinomy to privacy, since Q << K.

That is why, today and IMO, "security" and "easier life for users" are simply opposites. Of
course, as a generalization -- but which seems to be very well reflected in actual systems. And,
perhaps this is the main (though largely unspoken by both sides) reason why users say that
"security is not for me yet" (when they reject the hassle) while providers switch into marketing
modes and talk about "non-repudiation" or even "true non-repudiation" (when they try to
overvalue the hassle).  In this regard, my suggestion was that it is better to face the problem,
straight. "Security" and "easier  life for users" are simply opposites, to a large extent. Thus, let's
design methods with this in mind -- and, yes, try to decrease K.

BTW, I found much resonance for these ideas in my talk two weeks ago at the Black Hat
Briefings in LV (slides available), including in talks by other speakers (contact the site).
Bruce Schneier was especially keen on what he described as security being "orthogonal"
to functionality, meaning that just because a security product functions properly does not
mean that it is secure (in my words, the difference between correct and effective); mentioning
also that users do not have the training to follow a "secure" procedure instead of  just choosing
a procedure that works (i.e., users tend to favor functionality over security).  Of course, from
the viewpoint of conjugate variables, security is not orthogonal to functionality and that is why
maximizing one tends to minimize the other -- but both views are just paradoxical terminologies
to describe the same thing, that security and functionality are independent though interrelated
variables.

(BTW, this is nothing out of the ordinary and there are many examples where two variables
are independent but interrelated, as first observed by Fourier in regard to frequency spread
versus time spread for a signal. And, by Heisenberg.)

Cheers,

Ed Gerck