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