Subject: RE: Software for PKI

From: Ryan Hurst <[email-masked]>
Date: Thu, 08 Nov 2001 08:18:31 -0800

Mitchell --

The difference is that in many (but not all) cases "knowing that the user is
authorized" and "knowing that you have had previous contact with the user"
is adequate. But even in these cases we still want to know the literal "who"
we are doing business with, I think this is more a matter of human nature
than anything else.

I too think PKI can be a ROI tool, even if we do not take the security
aspects of the technology into consideration. Building heterogeneous
authentication infrastructure that is used across organizational and
technological boundaries has a great potential for return.

My 2c,

Ryan

-----Original Message-----
From: Mitchell Arnone [mailto:[email-masked]] 
Sent: Thursday, November 08, 2001 4:51 AM
To: [email-masked]
Subject: RE: Software for PKI

I am not sure I agree with the statement that no one really cares about 
identity.  How can anyone "know what you are authorized to DO" if you are 
not confident that you are who you say you are.  Only after proper identity 
has been established can proper permissions be assigned.  PKI is all about 
identity management and it may be the most effective method of identity 
management on the market today.

One of our problems is that we have not been selling solutions and that is 
because we have not properly identified the problem.  As a network 
engineer, I became tired and leery of building and supporting so many 
systems and applications with so many IDs and passwords.  I have designed 
and built IP networks, remote networks, VPN networks, Extranets and worked 
with all manner of application integration.  At one point, I had not less 
that 8 IDs and Passwords and it was a costly nightmare.  Companies are 
crying for a solution to this dilemma.

Now consider the alternative.  I have a badge that lets me into my 
corporate building and offices within the building with restricted 
access.  Then that same card permits me to login to the network from any 
workstation in the corporation and permits me access to personal 
information, applications, web pages and so on.   I can justify the cost 
for PKI simply as an effective identity management solution and this 
solution is available TODAY.

This is what attracted me to PKI in the first place and is the primary 
reason for pursuing a career focused on this exciting technology.

Yes ... non-repudiation, confidentiality and data integrity are crucial but 
until we can deliver a suite of applications that meet those needs simply 
and effectively, we need to focus on those areas where we can derive the 
greatest benefit today.  If we say that PKI is not effective because there 
are not sufficient applications to deliver on these benefits and the 
developers say that they will not deliver these kinds of applications 
because there is no business driver then we will be caught in a Catch 22 
with no way out.  But there is a way out.  PKI is an extremely effective 
Identity Management Tool/Service.  They say that if you develop a better 
mouse trap, people will buy it.  Well we have a great mouse trap right in 
front of our eyes, we just need to sell it, first to ourselves then to
others.

As more PKI deployments take place, we will be better able to justify the 
business case for application designers to improve upon their efforts and 
to develop more effective applications that will help take advantage of 
these other significant benefits.

PKI and Identity management is a foundation service just like the network 
infrastructure and directories.  You build a strong foundation and 
construct your application architecture in a manner to leverage the 
strength of the foundation.

Lets not underestimate the value of Identity management.  That would be 
like underestimating the value in having a little toe... try cutting your 
little toe off and see how well you walk.

Mitch

At 04:47 PM 11/07/2001, Bob Jueneman wrote:

It's rather ironic that as we are finally nearing the end of the PKIX 
development effort we are beginning to talk about why it isn't being used.

Let me offer my two cents worth:

I believe that we have passed over the peak of technology hype, and are now 
wallowing in the trough of disillusionment that always follows that kind of 
crest.  Unfortunately, the collapse of the dot-coms and the rest of the 
economy happened to coincide with the this disillusionment, and 9/11 has 
made matters even worse.  But although it may be difficult to see the 
bright side right now, I believe we will eventually climb out of this, and 
public key technology will be used -- either with or without PKI as we 
presently know it.

1.  The alleged communications security threat that PKI was envisioned as 
solving simply not perceived to be real.  Most companies just don't have 
any hard evidence that their e-mail is being compromised  -- at least not 
enough to justify implementing end-to-end S/MIME for the average user.  The 
Internet is envisioned by Joe Sixpack as being a dangerous place, but that 
is because of computer viruses and compromised web sites, NOT because of 
eavesdropping.

2.  Despite the hype and hopes for using PKI for e-commerce, 
nonrepudiation, etc., that hasn't materialized either.  By the time you get 
through reading all of the fine print behind the CA's policies, plus all of 
the legal  ifs, ands and buts required to effectively implement 
non-repudiation, you realize that there is no way that a TTP CA could 
really do a bang-up job of due diligence for any reasonable priced 
certificate.  So you might as well negotiate a set of business practices 
with your trading partners directly, and in which case you don't need a TTP 
CA at all -- you just need his certificates or certificate chain, without 
regard to any particular trusted root. So PKI doesn't scale nearly as well 
as we had hoped it would, primarily because of legal and business reasons, 
as opposed to technical ones.

3.  Perhaps the biggest single blunder that the PKI advocates committed 
(and I would include myself in that, unfortunately), was to focus 
excessively on the issue of identity.  In business no one really cares much 
about identity -- on the Internet no one knows you're a dog -- they just 
want to know what you are authorized to DO, and whether you will pay your 
bills.  Identity information provides an easy way to look up that 
information, but is otherwise relatively useless (except perhaps for audit, 
which no one does anyway).  And identity also collides with privacy, and 
may be perceived as making matters worse, rather than 
better.  Unfortunately, X.509 and PKIX got around to grappling with the 
issues of authorization and rights far too late in the game, with 
mechanisms that were poorly thought out (and remain so to this day) and 
never widely implemented.

In summary, PKI has not failed so much as TTP CAs have failed (at least for 
end users), and S/MIME has failed  both for lack of a demonstrable threat 
(unless you are a terrorist, in which case you would probably want to use 
steganography rather than cryptography, to avoid disclosing that you are 
doing something that might be suspicious) and because deployment is too
hard.

On the other hand, PKI has succeeded brilliantly in solving the identity 
problem for SSL, where it is now ubiquitous.  And it has been at least 
marginally successful in dealing with the security issues involved in 
executing downloaded applets, despite the debacle of the bogus Microsoft 
certificate.  And those areas are precisely where the focus on identity 
(and implied rights) is exactly on target.

In addition, PKI has failed because provisioning is too hard, i.e.,  too 
hard to manage.  Going to VeriSign for one certificate at a time is too 
much work and costs too much, but installing something like VeriSign's 
On-Site or the various toolkits available from Entrust or Baltimore 
Technologies takes too much of a leap of faith -- the cost of entry for a 
company is too high.

Finally, another blunder within the PKIX community was in avoiding making a 
firm commitment to use directory technology to distribute certificates, 
while at the same time not espousing any other workable solution either, 
such as some kind of an http mechanism.  As a result, S/MIME is too hard to 
use because it is too hard to get your hands on the recipient's 
certificates unless you go through a cumbersome exchange of signed e-mails 
and manually enter them into to your list of recipient's certificates. 
Yuck.  And I won't even mention the problem of managing trusted roots.

Sigh.  "Ve get so soon alt, und so late schmart."

Bob

 >>> "Harrington, Chris" <[email-masked]> 11/07/01 12:20PM >>>
***********************************************************
Mitchell Arnone
Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[email-masked]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  +1 410-579-8691
Mobile  +1 443-838-9373

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Nov 2001 09:51:20 -0800

----- Original Message -----
From: "Ryan Hurst" <[email-masked]>
To: "'Mitchell Arnone'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 08, 2001 8:18 AM
Subject: RE: Software for PKI

> technological boundaries has a great potential for return.

Where is the ROI over running a "hardened" computing environment with local
auth models?

The only thing that makes PKI of any real interest to many ifs that it
promises to take the "Human culpability" factor out of most long term
logging or instantaneous decision processes. But I to date have still failed
to see how its going to keep these promises.

This is the problems with allowing people to submit draft after draft on
technologies without require some rudimentary statement about how its to be
used and its constraints, which is why the TS Protocol, for example, is
still undergoing revision after revision.

Why not just mandate User Documents be required before anything is
transferred to a Standards Track? - BTW - take this as an official motion to
the WG as a whole for an amendment to the charter.

Todd