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

[tgindin@xxxxxxxxxx]

Ed Gerck <egerck@nma.com> on 07/22/99 02:45:21 PM

To:   Stephen Kent <kent@po1.bbn.com>
cc:   "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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