RE: Software for PKI

[Ryan Hurst <ryanh@xxxxxxxxxxxx>]

I see the ROI coming from the benefits associated with unified
authentication systems and ability to manage fewer disparate authentication
technologies. 

I full heartedly agree about the continuous influx of drafts on solutions to
problems that are not well defined and even worse specifications that simply
do not map into any real business need :). I also see us continuously coming
up with new ways to do the same thing which is always fun :). I would
certainly advocate that we add a requirement that there is use case
documentation included with all of these technology drafts.

Ryan

-----Original Message-----
From: todd glassey [mailto:todd.glassey@xxxxxxxxxxxxxxxx] 
Sent: Thursday, November 08, 2001 9:51 AM
To: Ryan Hurst; 'Mitchell Arnone'; ietf-pkix@xxxxxxx
Subject: Re: Software for PKI



----- Original Message -----
From: "Ryan Hurst" <ryanh@xxxxxxxxxxxx>
To: "'Mitchell Arnone'" <marnone@xxxxxxxxxxxxxxxxxxxxxx>;
<ietf-pkix@xxxxxxx>
Sent: Thursday, November 08, 2001 8:18 AM
Subject: RE: Software for PKI


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

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


>
> My 2c,
>
> Ryan
>
> -----Original Message-----
> From: Mitchell Arnone [mailto:marnone@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, November 08, 2001 4:51 AM
> To: ietf-pkix@xxxxxxx
> 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" <harringtonc@xxxxxxxxxx> 11/07/01 12:20PM >>>
> ***********************************************************
> Mitchell Arnone
> Senior Consultant
> Technical Consulting Practice, Northeast Region
> Schlumberger Network Solutions
>
> marnone@xxxxxxxxxxxxxxxxxxxxxx
> www.slb.com/nws
>
> 35 Waterview Blvd.
> Suite 210
> Parsippany, NJ 07054-1200
> USA
>
> Phone  +1 410-579-8691
> Mobile  +1 443-838-9373