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

From: [email-masked]
Date: Wed, 14 Jul 1999 14:24:30 -0400

>>Hello Mike,
>>
>>   You are on the right track (and so, I think, is Steve).  Before PKI
>>technologies (and other IETF *core* security protocol suites) can be
*main
>>streamed,* they must be made very easy to use across the board--from
>>implementers to developers to end (human) entities.  Some might object to
>>this as being *dumbed down,* but lack of interoperability due to overly
>>complex and convoluted multi-protocols (not to mention competing
protocols)
>>is a real problem.  So is the resulting complexity of use experienced by
EEs
>>(I could write volumes here!).  Unless we aim for the *lowest common
>>denominator,* CIOs will never be able to show ROIs to justify PKI (and
>>especially the PKIX favor of PKI) purchases.  We have probably all read
>>recent reports that Fortune 1,000 CEOs see IT, in general, and PKI, in
>>particular, as simply drains on profits; and in the UK, companies don't
seem
>>to be interested in PKI (and especially the PKIX flavor of PKI) at all.
As
>>usual, KISS is the key (no pun intended).  I fear that we do not have the
>>luxury of tossing things over the fence to *let the market decide.*  The
>>market may decide to pass.
>>
>>Bill
>>

I couldn't agree with you more. However, regarding acceptance of PKI
technologies by large organizations, I believe there are many reasons
organizations are not adopting PKI readily besides ease-of-use issues. Nor
does it have anything to do with ASN.1 vs XML. This issue can't be resolved
with technology solutions because their lack of acceptance is not due
solely to technical problems.

The problems with PKI are numerous, from a corporate perspective, and many
large organizations have not moved initial PKI efforts beyond the
pilot/evaluation stage. Problems include outstanding legal liability
issues, the lack of fraud protection laws, the need to address cessation of
activites of a CA and/or a registry, the inability to bind a certificate
distinctly to a user (software certificates identify systems, not users),
the inability of an issuer to associate a security policy with the
certificate (issuers need to be able to dictate when to allow caching of
passwords,as well as things like session timeout and password construction
rules), undefined procedures and products to support records management and
archiving, as well as that non-repudiation claims for current PKI products
may have no legal basis. Then there are all the technical problems.

There are interoperability issues, mostly because there are no products
that provide an infrastructure to support the PKI. There are point
solutions (certificate servers, directory servers, mail programs, browsers,
etc.) from multiple vendors that have to be woven together to create an
infrastructure. Consider that any organization that is using Lotus Notes
(ten years now ?) has been using certificates and public/private keys all
along and most did not even know they were. That is because Notes provides
an infrastructure to support its PKI, and hid most of the details from the
user. Any organization that treads into the latest PKI solutions for
anything other than SSL encryption quickly realizes something is missing.

Perhaps PKI will come of age when it is embedded in a smartcard. Just the
two-cents of someone who has looked at PKI for a large organization.
eric

//* opinions expressed are my own and not necessarily those of my employer
//*

---

From: "Todd S. Glassey" <[email-masked]>
Date: Thu, 15 Jul 1999 07:44:03 -0700

Actually made KISS is not quite the right issue. Before PKI technologines
can go mainstream, they need to be fully integrated as end user solutions.
Nothing less.

What this says is that anyone that intends to float a commercial product
around PKI needs to get it into enduser systems.

My feeling is that the win for PKI is in documents like the Roadmap and the
framework, that have end use figured into them.

Todd

----- Original Message -----
From: <[email-masked]>
To: Flanigan, Bill <[email-masked]>
Cc: 'Michael Myers' <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 14, 1999 11:24 AM
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Jul 1999 03:04:48 -0400

Eric,

>may have no legal basis. Then there are all the technical problems.

I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings.  If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues?  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.  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.

I disagree with your statement that a certificate in software binds a
system, vs. a user.  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, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism.  Finally, why do you say that an issuer cann
associate a security policy with a certificate?  We have the syntactic
means to do so as part of the standard.  Do you mean that we don't have
appplications that pay attention to the policy extension?

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 16 Jul 1999 01:50:21 -0700

Stephen Kent wrote:

> issues?

This is often a source of confusion. But, 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. OTOH,
if certificates are used then non-repudiation data may be built by the verifier
*notwithstanding* the desire of the authenticated party to refuse it.  Which data
can then be used in administrative (eg, within company boundaries) or legal
or extra-legal (blackmail) procedures *against* the authenticated party and
*against* its expressed will (since the decision to apply, accept or reject
administrative, legal or extra-legal procedures will lie above the party, in general).
But, there are other legal issues and cert storage liability is certainly one that also
comes to mind -- a user cannot so easily take his private cert with him when he
travels (just try it in NS browsers at some hotels for example) unless he takes his
laptop...  which can then be stolen or searched.

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.

> Part of the problem is that people have been led to believe that a
> legal concerns.

Part of the problem is that PKIX also has a so-called non-repudiation bit ;-)

>  However, use of a PKI to support SSL, IPsec, and S/MIME

"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.
Another common misconception.

> 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),
which alone opens the problem that (here, * is the trust operator):

 (A*B)*K <> A*(B*K)

and thus, for example, Alice may trust that Bob's certificate binds to Bob (ie, A*B)
before Alice knows that Bob trusts Khadaffi (ie, B*K), but not afterwards (ie, A*(B*K)).
Or, as another example, I may trust my lawyer before I know  that he trusts my competitor
but not afterwards. Or, Bill may trust Monica before Bill knows that Monica trusts
Linda, but not afterwards. In summary, this is the "unfaithful proxy " problem as I call it
-- you can never tell is there is an unfaithful proxy. However, to think otherwise and to
believe that (A*B)*K = A*(B*K) is a common misconception that leads one to believe
that Bob's certificate binds to Bob irrespective of Bob's trust on Khadaffi -- in fact, Bob
may not even exist.

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.

> Yes, smart cards are preferable, but if the choice is
> 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.

> and I certainly see
> authentication mechanism.

as above, trust is not distributive (socially).

> Finally, why do you say that an issuer cann[ot]
> 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.

> Do you mean that we don't have

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.

Cheers,

Ed Gerck

---

From: David Slattery <[email-masked]>
Date: Fri, 16 Jul 1999 10:28:39 -0400

> Another common misconception.

If PKIX  and certs do not "improve security" and "make life easy for users" what is the point
of this WG and why would anyone want to use it ????
I believe you are dead wrong when you call them antinomies. I believe that line of thinking is
why
we have such a lack of security in the industry. Security and users go hand in hand. Security
and
functionality have to be meshed for the survival of each. If security does not allow for
functionality,
no one will use security. If functionality does not allow security then that functionality can
be denied or
destroyed resulting in partial or no functionality of the system.
I believe security is a form of understanding. Thus confinement can be a tool of security but
it is not the goal.

just some idealistic thoughts
-Dave

  *************************************************************************
  This e-mail expresses my personal views and not those of State State.
  STATE STREET BANK                             Information Technology
  Telephone: (617) 985-0546                     Client Server Technology
  *************************************************************************

---

From: Ed Gerck <[email-masked]>
Date: Fri, 16 Jul 1999 10:14:09 -0700

David Slattery wrote:

> Ed Gerck wrote:

Any amount of security will always make life harder for users. Ignoring this instead of
recognizing it and then try to cope with it is one of the unseen problems of today. Why do
you think only 5% of the emails (on average) are encrypted? Because security is a hassle
and users will rather default to insecure methods than miss a deal. So, promising both
is empty because they will never be delivered -- and, trying to make security "automatic"
will just be another example of SKIP; perhaps useful in a closely watched network where
you control all nodes. But, on the Internet, no one controls both ends of a connection,
much less all nodes your packets may go through.

So, what I am saying is that it is better to face the problem, straight. Security and "easier
life for users" are simply opposites. Thus, let's design methods with this in mind -- users
do not have the training to be trusted to follow the "secure" procedure instead of
just choosing a simpler procedure.

The purpose of this WG is then to make security tolerable to users in regard to what it
delievers.

> I believe security is a form of understanding. Thus confinement can be a tool of security but

Yes, this phrase is mine. I am glad you read the email or the paper -- but, next time, pls
cite the (c) and source ;-)

One point of the phrase is that confining users to procedures does not necessarily increase
their security level -- also because the fraudsters are usually unconfined ;-)  and because
users will then be lead to trust "the system" instead of  trusting their use of the system.

Cheers,

Ed Gerck

---

From: David Slattery <[email-masked]>
Date: Fri, 16 Jul 1999 16:08:08 -0400

> The purpose of this WG is then to make security tolerable to users in regard to what it

    I believe that only 5% of e-mail are encrypted because most of the e-mail people send
are not sensitive. The rest maybe sensitive but encrypted e-mail does not give them allot.
Yes they have encrypted mail. But is it secure?  Do they store their key properly?
Does the CA storage their key properly? Can I get my key back if I loose it?
Can my employer or gov. get my key? etc....etc... That is allot for a user to deal
with. Never mind that they have to create and mange keys maybe install e-mail
clients work with certs and then no one else is able to read there message. Why is
none of the e-mail sent to this group is encrypted or at least signed ? Is it because
"users do not have the training to be trusted to follow the "secure" procedure instead of
just choosing a simpler procedure."

I think the bottom line is it just is not worth all the effort for the rewards for 95%
of e-mail users.

I do agree with your statement: "The purpose of this WG is then to make security
tolerable to users in regard to what it delievers."
Well said.

> cite the (c) and source ;-)

    Sorry, I always liked that quote but I had forgotten where I read it. I guess if I am to be
corrected you are the best one to do it. I will be sure to quote your name.

> users will then be lead to trust "the system" instead of  trusting their use of the system.

agreed.

> Ed Gerck

Thanks
-Dave

--
  *************************************************************************
  This e-mail expresses my personal views and not those of State State.
  STATE STREET BANK                             Information Technology
  Telephone: (617) 985-0546                     Client-Server Technology
  *************************************************************************

---

From: Stephen Kent <[email-masked]>
Date: Sat, 17 Jul 1999 14:18:02 -0400

Ed,

>laptop...  which can then be stolen or searched.

Huh? Your characterization of why passwords don't provide NR is a bit over
simplified, as challenge-response technologies also don't provide a basis
for NR in most instances either.  Moreover, many of the ways in which we
use certificates for authentication do not confer non-repudaition, hence my
point. I do have some certs polyinstantiated on my laptop, desktop, and
home machines, in Netscape.  It's doable.  Although the observation about
the opportunity for theft is accurate, it seems a bit far afield of this
discission.

>equivalent -- but, they simply aren't and for several legal reasons.

What you said above does not seem to support this conclusion.

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

>that last phrase is an empty promise though it may look good in marketing

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.

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

>cert storage liability. Etc.

I was talking about certs used for auth, not NR, making the comparison to
passwords meaningful.

>as above, trust is not distributive (socially).

Again, your argument seems orthogonal to the issue I was addressing.

>in the standard as we all know.

Hard copy contracts specify the language and jursidiction of
interpretation, and cert policies can do the same. 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.

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

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Jul 1999 20:01:02 -0400

Ed,

>much less all nodes your packets may go through.

In another message I cited the instance of using client certs with SSL, vs.
remembering a name and password for each web site.  Most folks who have had
the opportunity to try client certs in this environment find that it does
make life easier, while improving security.

Steve

---

From: Andrew Probert <[email-masked]>
Date: Sun, 18 Jul 1999 09:31:10 -0700

I agree with this stance.  EDI would not have got off the ground if they
didn't rely on Trading Partner Agreements, which explicitly stated the
relationships.

The real contractural complexity arises when the CA is not one of the
trading partners i.e. three party agreements are required

CA <-> Supplier
CA <-> Customer
Customer <-> Supplier

Also that the issues of integration of certifiate-based authentication
to host systems require construction e.g. mapping of security domains
such that certficate dnX == RACF UseridY, or is implicitly trusted as it
comes from a trusted gateway.

---

From: Ed Gerck <[email-masked]>
Date: Thu, 22 Jul 1999 11:45:21 -0700

Stephen Kent wrote:

> Ed Gerck wrote:
> >This is often a source of confusion. But, 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. OTOH, if certificates are used then non-repudiation data may be built
> >by the verifier *notwithstanding* the desire of the authenticated party to refuse it.
> >...
> for NR in most instances either.

Steve:

Why would my "characterization of  why passwords don't provide NR" be
"a bit over simplified" as you say? -- what have I left out, regarding passwords?

And, why would this have anything to do with your assertion that
"challenge-response technologies also don't provide a basis for NR in most
instances either"?  -- I fail to see why my observation that passwords
deny NR  (which passwords do strongly deny ) would be made more difficult by
challenge-response technologies also denying it in most instances.  I see no
connection -- and certainly none that would make passwords provide NR.

To rephrase, my point was very simple -- passwords strongly deny NR; certificates
do no necessarily deny NR and thus certificate authentication can be misused by the
verifier in order to provide grounds for NR even when the certificate holder denies it.

>>> authenticate users, in lieu of passwords, why are there any new legal

as yes, indeed, there are new legal issues. One of them is not strongly denying NR.
Another is certificate storage liability.

> Moreover, many of the ways in which we
> point.

This has nothing to with the possibility of confering NR -- which exists for certificates
(even unwillingly to the cert holder) but does NOT exist at all for passwords. Hence,
paswords do NOT have this legal issue... by construction.

> I do have some certs polyinstantiated on my laptop, desktop, and
> home machines, in Netscape.  It's doable.

Never said otherwise, on the contrary.

>  Although the observation about the opportunity for theft is accurate, it seems a bit
> far afield of this discission.

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

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.

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

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

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.

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

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

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.

> I was talking about certs used for auth, not NR, making the comparison to

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.

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

> >security policies per se are not defined as part of the standard, just
> >referred in the standard as we all know.
>
> 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.

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

> >to a meaning -- which meaning can be  inacessible to the application,
> >outdated, invalid in that jurisdiction, etc.
>

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: "Jan Nielsen" <[email-masked]>
Date: Thu, 22 Jul 1999 19:15:55 -0600

Hi Stephen and Ed, et. al.

I believe a discussion the non-repudiation characteristics of secret key versus private/public
key systems requires more than a discussion of key type.  The authentication protocol, the
specific implementation of that protocol, the characteristics of the core cryptographic
service, and the characteristics of the key management are all more important technical
characteristics w.r.t. non-repudiation than the actual key type.

> verifier in order to provide grounds for NR even when the certificate holder denies it.

This is generally incorrect.  Secure authentication protocols implemented by trusted clients
generally have better key management characteristics than today "PKI systems", e.g., browsers,
and therefore have better non-repudiation characteristics.  Until the key management aspect of
NR is resolved technically (and to the satisfaction of a particular legal system), the NR
characteristics of a system will not be quantifiable; rather, it will be in the eye of the
beholder.

Regards,

jsn

--
Jan Nielsen
Campus Pipeline, Inc.
--------------------------------------
[email-masked]
801.485.6000 x155 (voice)
801.485.6606      (facimile)
http://www.campuspipeline.com
--------------------------------------

---

From: Ed Gerck <[email-masked]>
Date: Thu, 22 Jul 1999 20:35:18 -0700

Jan Nielsen wrote:

> key systems requires more than a discussion of key type.

Secret key systems are in discussion here -- though they may be ;-)
The discussion was between passwords and private-key certificates.

> This is generally incorrect.

;-) no.

> Secure authentication protocols implemented by trusted clients
> and therefore have better non-repudiation characteristics.

This has nothing to do with what I discussed -- what you seem to believe to be "generally
incorrect" is actually common wisdom and has nothing to do with what you mention,
which may explain your off-the-point remark.

>  Until the key management aspect of

See it this way -- for private/public key certs, the NR characteristics may vary. However,
for passwords NR simply does not exist (as I commented before).  That is why I also
commented that passwords and certificates are certainly not the same in regard to the
legal significance of their respective authentication acts.  With a certificate, a  verifier
may maliciously build a non-repudiaton case even if the signer does not want it -- but,
with a password this is simply not possible at all.

A large difference, even though generally misunderstood.  But, there are other differences,
for example the "Radar O'Reilly attack" -- to which passwords are also immune.  Again,
just to make sure it is dead clear, I am not predicating that passwords are "better" than
certificates -- just that they are different and such cannot be ignored in authentication
acts as Steve predicated.

Vive la difference!

Cheers,

Ed Gerck

---

From: "Jan Nielsen" <[email-masked]>
Date: Fri, 23 Jul 1999 00:09:08 -0600

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.

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.

Regards,

jsn

---

From: Ed Gerck <[email-masked]>
Date: Fri, 23 Jul 1999 10:54:21 -0700

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

> 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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Jul 1999 13:14:39 -0400

jan,

>characteristics w.r.t. non-repudiation than the actual key type.

I agree.  My point to Ed was that his focus on challenge-response protocols
also does not get at the core features for NR.  One can build NR systems
based on secret key use; such designs were presented by Rabin and others in
the early 80s.  Nobody implements them because they place signnificant
communication and security requirements on TTPs that mjust be online for
transactions, instead of allowing most of the process to be effected via
communication only between the communicating parties.  Also, (user)
authentication protocols generally do not support NR, since a primary goal
of NR is to establish the integrity and authenticity of transactions, not
of a user login. I mentioned key marking only because it is standardized in
X.509 certs, for when one wants to declare that the corresponding private
key is to be used for NR.

>characteristics of a system will not be quantifiable; rather, it will be

Again, user authentication protocols are not, in general, a basis for NR,
because they fail to link the user, in a technically non-repudiable way, to
subsequent transactions.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Jul 1999 13:07:41 -0400

Ed,

>connection -- and certainly none that would make passwords provide NR.

I said it was oversimplified because I interpreted your comments as
indicating that passwords fail to provide a basis for NR because of a lack
of challenge-response functionality.  Such functionality is not the central
issue for NR and so I felt that you were confusing two separate topics.

>This answers your original question, saying that this is absolutely NOT a

I'm uncomfortable with the phrase "deny NR" and so maybe I don't know what
your intention is in choosing that phrase.  Simply stated, passwords are
not sufficient as a basis for NR, while certificates do proivide such a
basis.  However, certs do not, by themselves, ensure NR.

>Another is certificate storage liability.

We may disagree here.  there is no technical requirement for a CA to store
certs in support of NR.  A perfectly valid alternative model is for relying
parties to retain the certs and CRLs needed for NR, appropriately time
stamped by a third party time stamper, to establish the time at which this
evidence was acquired.

<snip>

>passwords, why are there any new legal issues?"

if the certs used to authentication are not used for NR, by explicit
marking and CA policy, then theft of private keys associated with certs
should have no NR implications.

>equivalent, albeit incorrect.

I have yet to see a technical basis for distinguishing cert-based
authentication from cert-based authentication, in terms of liability.
Lacking case law precedent, we'll just have to agree to disagree on the
possibility that there are such differences.

>be better placed and substantiated  for context in the document itself,

The rationale for the NR bit is to signal the intent of the cert user that
data signed with the cert is intended as evidence in support of NR, vs.
authentication, key exchange, etc.

>(even less secure) has even less hassle.

I do employ SSL access from hotels, and I am not too concerned about the
security risk posed by having a private key, encrypted by just a password,
in my laptop. The reason is that I am fairly careful about physical
security for my laptop (probably better than my desktop, given occasional
theft within our facility) and I don't see the TH risk as any greater for
the laptop than the desktop.  besides, the certs I use in both cases are
not for NR (a security service that is not provided by SSL due to the layer
at which SSL operates).

>exists or, even, that it is less.

We disagree. Using client certs for SSL user auth is more convenient for me
as a user, and offers better security than use of a password for
authentication.  The  security examples you cite are more along the lines
of access control, rather than authentication.  Once one decides that
authenication is a requirement (for access control and accountability),
then one can choose from among different mechanisms with different security
properties and different user inconveniece levels.

>software/system without the verifier knowing it, not the verifier's trust

The comments above are rather vague.  Try to use more technical terms, and
maybe exmaples, to explain your point.

>trust the Certificate.  I hope it is clearer.

No, it is not clearer. Software is ALWAYS between people and hardware, or
between people, trying to perform user authentication.  We don't see what
operations are performed on our behalf, what is transmitted down the wire,
etc.  What people mean when they use the word "trust" is not the same as
what you are referring to when you say that software "trusts ... a
certificate" so the notion of associativity is not applicable here; the
operators are different.  I don't think your use of symbology helps at all.

>see several reasons NOT to adopt the latter; unwanted NR and cert storage

You continue to assert these as problems, but I don't accept the assertion.

>authentication mechanism.

Trust is almost always the wrong word to use here.  It is not transitive,
it is not readily quantifiable, it is a human emotion not a characteristic
of software, hardware, or PKI.  As Tina Turner might have said, "What's
trust got to do with it?"

>this has no bearing either on the CA or on the subscriber.

if a cert carries a policy OID, the implication is that a relying party can
fetch the policy governing cert issuance and make a decision to rely on the
cert or not, based on that policy.  If the RP does not accept the language,
jursidiciton, etc. of the policy, then the RP should not accept the cert,
period.

>the law regime of its jurisdiction (the right to deny an electronic

You assert that a user cannot associate a policy with a cert, but I provide
examples of how to do this. we clearly are not speaking the same language,
and so it is not clear that we ought to pursue this line of discussion.
besides, my company works with a number of large CA service providers, as
well as being one, who believe that they have adequately addressed this
problem, in practice.  So, I'm willing to go with the opinions of our
counsel, and the counsels of half a dozen CA services providers in an equal
number of countries, rather than continue the debate.

>pointers to a meaning -- which meaning can be  inacessible to the application.

Your model assume a set of constraints that prejudice the outcome.  For
example, you assert that a sysadmin has "accepted" policies, and imply that
a user is now bound to rely on certs based on the sysadmin's acceptance of
these policies.  however, the cert validation application cited is unable
to comply with at least one aspect of a policy, making reliance by the
user, in the context of that application, unwise.  The technical term here
is "broken."  it would be a mistake for the sys admin to accept policies on
behalf of users if the sysadmin does not know what apps will process certs
under these policies.  if acceptance is to be enforced, the sys admin needs
a way to distribute this info to user apps, but your example (current
browsers) does not have such a mechanism, so the whole scenario is a bad
example.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 23 Jul 1999 20:36:23 -0700

> issue for NR and so I felt that you were confusing two separate topics.

Ok, then we seem to disagree -- since positive challenge-response (not
necessarily cryptographic, of course) is what distinguishes live from dead
data and is IMO a sine qua non condition in legal NR.  However, what you
say can also be NR, though not legal.  In order to preclude further
interpretation problems, let me present a NR model that classifies what I
consider to be the major aspects that any system wishing to provide
non-repudiation at any given level should include, also naming each of a
series of levels and providing for a division between Variables (which I
can't control) and Modifiers (which I can control to some extent):

A. Variables -- involves only "you", where "you" is the one that authenticates

A1. syntatic form (Is the authentication yours?),

A2. semantic form (Did you understand what you were authenticating?),

A3. trust form (Did you yourself willfully authenticate it?),

A4. identification form (Are you the authenticator you claim to be?),

A5. temporal form (When did you authenticate it?),

A6. local form (Where did you authenticate it?),

A7. etc.

B. Modifiers -- involves also "me" (ie, "I", the verifier)

B1. legal form (Can I legally prove it?)

B2. liability form (Can you back and idemnify it to me?)

B3. extent form (What is the temporal and legal extent of the authentication, for you
                         towards me and me towards you?

B4. policy form (Is that allowed by the applicable policies, for you towards me
                         and me towards you?)

B5. etc.

Where I prefer to divide the issues of non-repudiation according to a
state-space where one has a FIRST set of clear variables which I do not
control, but measure:

 Variables: syntatic, semantic, trust, identification, temporal, local, etc.

and a SECOND set of clear modifiers which I can control at least to
some extent:

 Modifiers:  legal, liability, extent, policy, etc.

As needed, one combines the components for a specific
"law/policy non-repudiation system" as a logical function that uses
A1, A2,... and B1, B2, ...  above as functional inputs, but in
each respective classification.

So,  weak authentication (as provided by passwords) fails to
provide values for *ALL* variables when viewed under B.1
since any such value could be replayed at will by the verifier
(for example, or by an attacker) and there is nothing that the
password holder could do to avoid it. Thus, as a legal principle
valid in law theory in general (between power and liability),  since
the password holder has no power to deny weak authentication it
also has no derived liability from it, including non-repudiation.

However, it is possible that some A variables could provide
non-repudiation for passwords when viewed under the B4 modifier,
for example --  such as when an ISP uses A.1 and B.4 in order to
put an user's account on hold when two succesfull logins occur at a
given time (indicating either two persons using the same account or
a password compromise).  But, this is not legal NR -- which is what
we are focusing here.

So, to avoid further confusions whenever I mention NR, I mean legal
NR unless otherwise noted.

> basis.  However, certs do not, by themselves, ensure NR.

I would phrase it differently -- simply stated, passwords are not necessary as
a basis for NR, while certificates may be necessary. Further, certificates are
not sufficient as basis for NR.  So, passwords are neither necessary nor sufficient
for NR, while certificates may be necessary but not sufficient.

That is why I wrote that passwords "deny NR" -- because if I exclusively
use a password when authenticating myself to a site, then I am one-sidedly denying
NR capability to that site over my authentication, try as the site may.

OTOH, if I use a certificate then I may be faced with NR *evidences*
against myself which I may find difficult to deny -- so, certificates cannot
deny NR capability (ie, I am at the mercy of the other side will or ineptitude).

> certs in support of NR.

This is a simple confusion -- we were talking about private-key certs and
the cert storage liability that is borne by the *user* (ie, the private-key
holder), not the CA.

But, the same does not occur with passwords, so with certificates the user
must not only be liable for keeping the password but also the private-key
cert itself (otherwise, someone may off-line break its password and then
use it).  This is also in accord with the concept that more security comes at a
"hassle price".

> should have no NR implications.

I am usually wary of forecasting judicial decisions. But, suppose we
agree that "explicit marking" is a function of the software that reads it
while CA policy is a function of what you can read at a URL if you
use reasonable reliance and go there and check it.

However, in the majority of US states and in US Federal courts I
am not required by law to use reasonable reliance in order to perform
due diligence -- I may justifiedly rely on what you affirm if  it looks
right without further checking.  Thus, theft or even use of NON-NR
private keys can have NR implications by justified reliance in all cases
so allowed by law already -- for example, if the private-key holder
commits a tort (in the verifier's jurisdiction, which may not be a tort in
the keyholder's jurisdiction).

> authentication from cert-based authentication, in terms of liability.

Do you mean password-based vs. cert-based? See the Munden case in the
UK for the former. See the Utah legislation for the later.

> authentication, key exchange, etc.

The intent is IMO fine, the problem is calling it a "non-repudiation bit".
But, names are simply names .. perhaps law should change what it calls
non-repudiation ;-)

> not for NR (a security service that is not provided by SSL due to the layer

Yes, and the fact that you are "fairly careful about physical security for my
laptop" stems also from your storage of private-key certs in it -- if you would
be satisfied with the security level provided by a password you would not
even need to carry your laptop for that reason or to have anything valuable in
it.  So, your explanation seems to confirm what I was trying to explain -- that
different authentication procedures carry different legal consequences for both
parties (eg, in yourcase, the bad karma of client cert theft) .

> properties and different user inconveniece levels.

Requirements are usually chosen as a compromise between cost and risk. And,
choosing authentication as a requirement still needs a further analysis between
"weak authentication" (passwords) and "strong authentication" (certificates).
I understand that you tend to use the word authentication in the later sense,
exclusively, but "weak authentication" can be more secure than "strong
authentication" as we all know -- so there is no reason to exclude passwords
from a choice "among different mechanisms with different security properties
and different user inconveniece levels".  And, where passwords will, almost
always, correspond to much lesser inconvenience levels -- and, most importantly,
much lesser liability levels.

> operators are different.  I don't think your use of symbology helps at all.

Yes, many different people may mean different things by that pesky word "trust"
and that is why I was careful enough to note:

  ... if the User knows that the Software trusts (ie, relies upon for its actions)
  some aspect that the Software can exploit in the Certificate ...

where I consistently use the word ttrust o mean "that which I rely upon for my
decisions" -- which is trust in the subjective sense. I can also use the word "trust"
to mean a "license" or "authorization" as a trusted user in a network, who is a
user authorized to access some services -- but this is using the word "trust" in an
objective sense.

The symbology helps to show that a certificate binds to a system, not to a user --
for many reasons, for example because a certificate can be read by a system
without any intervention *from* a user and because a certificate can be created
by a system without any connection *from* a user. If a certificate would bind to
a user, then one would have (U*S)*C = U*(S*C) because this would be equivalent
to (U*S)*U == U*(S*U) -- and not (U*S)*C <> U*(S*C); where '*' means
"trusts" and the parentheses mean precedence order as usual.

> trust got to do with it?"

Go with Tina Turner then to quantify trust in IETF protocols ;-) If we all
find a need to talk about "trusted systems", "trusted third-parties", "trusted
certificates", "trusted user" then the least we can do is define it in a coherent
way that we can all use. And, this is not so hard if we consult the dictionary,
for example. Yes, sure, trust can be a human emotion -- but this is not all that
trust can be, or is.

The concept of trust in communication systems must have nothing to do with
friendship, acquaintances, employee-employer relationships, loyalty, betrayal
and other overly-variable concepts.  Here, trust is not to be taken  in the
purely subjective sense either,  nor as a feeling or something purely personal or
psychological -- trust is to be understood as something potentially communicable.
Further, if trust must bridge different instances and observers, otherwise
communication would be isolated in domains, then all different subjective and
intersubjective realizations of trust must depend on some common, basic and
abstract idea -- an archetype in some terminologies.  As used in the context of
Generalized Certification Theory [see the relevant URLs, pls.] trust is, simply:

 "trust is that which is essential to a communication channel but which cannot be
 transferred from a source to a destination using that channel".

and from this definition more than 30 different definitions can be *derived*, including
the linguistic meanings and the following:

 "trust is that which an observer has estimated with high-reliance at epoch T,
 about an entity's behavior on matters of x",

> jursidiciton, etc. of the policy, then the RP should not accept the cert,

This is OK as long as it is not the only choice to continue the transaction --
but for which a CA policy does not provide. Of course, one may say, but
the point was that the same does not apply to passwords (as we were
comparing both for "nuisance levels").

> number of countries, rather than continue the debate.

Let me carefully re-state what I asserted:

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

and I am sure your counsels have carefully made such policies exactly so
that users remain not privy to the contract -- thus, they have also denied
a user any power to even demand that the policy be kept unchanged, not
to mention to demand suitability of purpose (which, the CA policies do
not have, for users).   Of course, there are reasons for this and a CA would
be on to a fast-finish without this -- but, again, the point is that passwords
do not include this "hassle".

> >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
> >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?
> >
> >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.
>
> these policies.

This is what companies do, perhaps even yours. Or, do you recommend to
a company that their employees can accept any CA policy at will? In the
praxis, what I observe is that some CA policies are acceptable to a company
(perhaps, only two or three) as defined by their security officer or whatever,
while  the others are unacceptable.

> however, the cert validation application cited is unable
> is "broken."

No, I differ. The technical term is "non-existent". No application today AFAIK
tests for this -- but this is just one purposeful example of the notion that no
application, ever,  can test for everything, so that there must always be
untestable features of certs and policies. Thus, my example concretely brings
to light one case of what  I described before -- that there may be policy meanings
unacessible to the application, outdated, wrong, etc.  BTW, just look at the
OID list ;-)

> it would be a mistake for the sys admin to accept policies on
> under these policies.

No, the case here is simpler and decidable -- current browsers. All very
well known --  so the sysadmin certainly knows what apps will process certs
under the two CA policies.

>  if acceptance is to be enforced, the sys admin needs

;-) not a bad example, I am afraid, but a good example of a bad case in
regard to your previous argument line. As I wanted it to be, in order to explain
by examples and not only in theory.

Cheers,

Ed Gerck

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Jul 1999 10:31:45 -0400

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

---

From: Ed Gerck <[email-masked]>
Date: Thu, 29 Jul 1999 10:50:56 -0700

> challenge-response protocol is involved.

No, it does not provide for legal NR unless there is some mechanism of
challenge-response involved (which does not need to be cryptographic).
Please see my last msg with the subject "non-repudiation" for an analysis
which also deals with non-legal NR.

Cheers,

 Ed Gerck