Lynn, et al,
Your point that PKI can be very "hard" is valid, but this must be
put in some sort of context. What is "hard" is handling
enrollment and registration of subjects (e.g., individuals,
businesses, roles) and managing the associated credentials and
transaction histories over potentially long time periods. Sort of
like what most banks do for their customer accounts (individual
consumers and businesses). Similar problems exist for employers
who must deal with complex employee relationships and associated
access controls and entitlements often spanning global
enterprises with all types of employees and contractors.
The key point is that the machinery associated with an
infrastructure to support public key cryptographic applications
(PKI, if you will) does *not* have to be absurdly complex or
overengineered to meet overblown requirements.
Your point that "industrial strength service operations are
really hard to do right" is certainly true, but I think you are
also helping to make my case that we have tended to blame PKI for
the fact that legacy systems and applications are not easily
retrofitted to deal with transactions taking place over public
infrastructure, such as the Internet. From a legacy systems
perspective, it might be nice if everyone would continue using
the same old protocols and proprietary networks in the way these
things were designed to be used, but that tends to inhibit
progress and improvement.
To expand on my earlier point that the Financial Industry is
largely responsible for driving PKI requirements to unreasonable
levels, I would contend that this was motivated by two sets of
objectives:
(1) Attempts to move the burden of adapting legacy applications
to meet Internet security requirements onto the backs of PKI
systems and services, and
(2) The desire to deflect new sources of liability away from
financial institutions and onto PKI service providers and
their technologies.
To be fair, both sets of objectives are understandable from the
perspective of traditional financial service providers. Their
investments in legacy infrastructure and applications are
enormous; and, as institutions that accept some financial
liabilities on behalf of their customers, new sources of
liability must be approached with great caution.
The AADS model you advocate addresses an aspect of integrating
public key crypto into legacy applications. For the benefit of
others on this list, AADS recognizes that if a party is
attempting to conduct secure transactions with a service that
issued credentials to the party, then the service should know, a
priori, what public key goes with that party. In other words, if
the service can recognize the party, and if the party is already
registered with the service, then the service should be able to
look up the party's public key without having to get a
certificate from the party. The service can then authenticate the
party by issuing a challenge that requires a response using the
private key held by the party. Similarly, other security
functions, such as encryption and digital signatures can be
implemented without having to exchange public key certificates.
AADS may help reduce the challenge of upgrading some legacy
systems to support new secure transactions. However, it is also
worth noting that this is exactly the model originally proposed
for use of public key crypto back in the 1970s when civilian uses
of this sort of cryptography were first being introduced. I.e.,
it is nothing new, although AADS provides useful formalization
for the procedures.
The reason that certificates were "invented" was that new
applications for public key cryptography emerged where "a priori"
knowledge of public keys could not be assumed. Secure email is a
classic example of an application where there is a need to
exchange public keys between parties where there is no prior
knowledge of the other party's keys. SSL web sessions represents
another such application as do some payment applications (e.g.,
the FSTC eCheck initiative). I should also acknowledge that
different approaches for creating public key certificate-like
structures do exist, along with different trust models.
The danger in continuing to flog the "dead" PKI horse is that it
further deflects attention away from the more relevant problems
of inadequate commercial solutions for any of the critical
security problems confronted by individuals, businesses and
governments. The ongoing debates surrounding authentication
services serves to sharply illustrate just how little progress
has been made. Furthermore, the current climate continues to
promote a contentious atmosphere with bitter competitive
rivalries and conflicting priorities undermining many efforts to
make forward progress.
To my earlier point, our current definition of PKI should be
viewed more as a path that is no longer going anywhere useful.
The options are to:
* backtrack to some earlier stage of development and start anew,
* somehow switch onto another path that shows greater promise,
* or pick a new direction and take advantage of what progress has
already been achieved.
Each of these options has its advocates, but I'll admit that I
tend to favor the latter option on pragmatic grounds.
What is even more important, however, is to focus on the critical
needs for effective security measures that can be widely deployed
and adopted, and that can evolve rapidly to confront an array of
new threats.
Let's be honest, the security of payment transactions today is
far worse than it was a decade ago. This is due to the failure to
improve security measures for payment transactions, while broader
information dissemination and new technologies have enabled an
array of new threats with corresponding risks. Put differently,
the "moral hazards" embedded in our current payments
infrastructure are of historic proportions, and the trends are
not looking healthy right now.
Therefore, debating the "death of PKI" is a distraction that
deflects attention from the true problems. It is high time we
focus on better ways to mitigate the security risks associated
with both legacy and new payment transaction services. The need
for public key infrastructure to support new security measures
can then be defined rationally based on real requirements instead
of impossible or conflicting objectives. My personal suspicion is
that the eventual solutions will have aspects of many of the
current models, but without so much baggage.
Does this make sense?
Regards...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
+1 508 625-1137 Office Phone/Voice Mail
+1 309 422-9871 Fax Service
[EMAIL PROTECTED] wrote:
>
> I was on a PKI panel at NISSC conference a couple years ago. The first
> three speakers were from the traditional PKI vendors and their basic
> message was something to the effect that .... everybody has heard all the
> stories about how really hard PKIs are ... well, I'm here to tell you that
> it is much, much easier than you've heard.
>
> I then gave a AADS talk
>
> Then the last speaker made some opening statement to the effect that ....
> they were responsible for the oldest and largest PKI in existance (some DoD
> thing) and everybody has heard all the stories about how really hard PKIs
> are ... will, I'm here to tell you that it is much, much harder than you've
> heard.
>
> Now a couple years before that, my wife and I had been doing this stuff
> associated with electronic commerce.
> http://www.garlic.com/~lynn/aadsm5.htm#asrn2
> http://www.garlic.com/~lynn/aadsm5.htm#asrn3
>
> and we had a couple decades experience between us with data processing that
> provided industrial strength service operations. So one of the things that
> we did as part of this SSL thingy was go around and perform due dilligence
> on the major PKI operations and talk about what it means to operate an
> industrial strength service. I think w/o exception the response was that
> they were starting to find that out ... that they had gone into it with the
> idea that it was somehow a computer or cryptographic technology thing and
> were finding out that the computer stuff and the crypto stuff represented
> possible 5 percent of what they needed to do.
>
> The AADS stuff isn't so much about certificates or no certificates ... it
> is about industrial strength service operations are really hard to do right
> ... and incorporating public key into an existing service operation may
> have significant upfront effort just to get off the ground (aka AADS)
> compared to deploying a simple, stand-alone CA server (aka CADS) ... but
> AADS then is able to take advantage of significant investment in existing
> infrastructures for providing industrial strength data processing service
> ... and opposed to growing it from scratch for a brand-new operation.
>
> Simple CA servers are pretty straight forward ... comparable to say any
> other departmental server effort. It is making the transition from simple
> departmental server stuff into large scale industrial strength data
> processing that lots of other issues start to raise their head (the
> transition from 10-20 person departmental service to a several hundred
> thousand person enterprise service is not necessarily a straight forward or
> even linear scale-up).
>
> [EMAIL PROTECTED] on 5/28/2002 4:07 pm wrote:
>
>
>
>
> [EMAIL PROTECTED] wrote:
> >
> > http://www2.cio.com/research/security/edit/a05232002.html
>
> Lynn,
>
> Thanks for passing along the reference to the ALARMED editorial
> in CIO by Scott Berinato. It manages to come a bit closer to the
> truth than have many of the other pieces written on the death of PKI.
>
> I would add a couple of observations of my own. First, the
> financial industry itself is largely responsible for escalating
> the requirements of PKI systems and services to truly absurd
> levels. Building massive infrastructure with extreme security
> appealed to the investment community that was happy to finance
> the PKI endeavors of multiple startups and spinoffs. After all,
> if the major banks were all saying they needed this stuff, then
> it must be a good investment to back the folks building these PKI
> palaces and Maginot Line defenses.
>
> It is interesting to reflect on the original concepts for PKI
> systems (developed long before the term "PKI" came into use).
> These concepts envisioned simple workstation systems with addon
> security hardware for key protection that would operate as
> Certification Authorities (CAs) out where the credentials were
> being issued. The US DoD secure messaging systems actually
> deployed such CAs. The early Netscape server products also
> included simple CA software solutions, still used by many today.
> Microsoft offers similar CA solutions as well.
>
> What is unfortunate in the current dialogue is how few people
> discuss the successes of PKI in their rush to be among the first
> to stamp on the grave of PKI. In reality, PKI is widely used
> today, and not just for SSL server side authentication and key
> exchange. Many organizations effectively use secure email
> solutions (e.g., S/MIME) with standard X.509 certs (I regularly
> conduct sensitive client business using S/MIME and certs I
> conveniently acquired from Thawte's service). Lotus Notes is very
> popular with many corporations, and is based on public key
> certificates, although only recently has Notes begun to use
> standard certs instead of their earlier proprietary constructs.
>
> But more importantly, and perhaps more to the point, the core
> concept of digitally signing a public key remains central to many
> applications of public key cryptography. Furthermore, public key
> crypto remains a useful security technology that can be applied
> to a wide range of problems. Whether or not a signed document
> containing a public key is called a certificate, or something
> else, is mostly a matter of terminology and choice of standards.
>
> Lynn, before you jump in with any claims about the virtues of
> AADS, I will acknowledge that certificate-like objects are not
> always required, especially when the appropriate keys (private
> and public) can be selected through some other context, such as
> the name or userid or account number of one of the parties.
> Hopefully, you will also agree that there are also situations
> where parties do not know "a priori" the public keys of the other
> parties, and some sort of mechanism is required to exchange and
> confirm the authenticity of the public keys.
>
> So, as Mr. Berinato's editorial points out:
>
> "As complex as Public Key Infrastructure is,
> the theory is sound."
>
> "So while the concept behind PKI was appealing,
> everything else about it was shoddy."
>
> Both are accurate observations, although I would tend to refer to
> commercial PKI solutions as more "overblown and gilded" than
> "shoddy," although I do know of some examples of shoddy PKI systems.
>
> My conclusion is that PKI has come to mean a "poorly chosen path"
> for achieving effective deployment of security measures based on
> public key cryptography. The PKI path has favored entrenched
> interests and "big iron" solutions. This path has also confused
> many about what the ultimate destination should be. What needs to
> be recognized--and more broadly communicated--is that there are
> other paths to achieving effective use of public key crypto as a
> set of mechanisms for building secure applications. We need to
> stop focusing on the wrongness of the PKI path, and move the
> debate to more constructive dialogues about what the right path
> (or paths) should be. To this extent, I appreciate the
> suggestions that Anders has been putting forward because I
> believe he's talking about possible new paths, not bemoaning how
> we got here.
>
> Just some thoughts...
> --
> ...Chuck Wade
> Consultant, Internet Security and Financial Services
> +1 508 625-1137 Office Phone/Voice Mail
> +1 309 422-9871 Fax Service
