I agree that PKI works horribly bad, but mostly for reasons other than those you listed.

You bring up the HSM argument, but in the example you point out the problem is the operational incompetence, not the HSM per se (which is just a big smartcard, do you hate smartcards too?) or PKI. It is also questionable to regard the HSM backup as a further root, the main reason being that such backup won't be for sure another HSM, but rather some caveau in some local banks.

The last argument (the Saudi case), is more related to trust, delegation, accountability and access control (within your device). I guess that RIM (the root?) gave out a certificate to Etisalat. Which rights did RIM gave away? Apparently all. Is Etisalat accuntable? Probably, but I'd be curious to see the contract for the certificate transaction. Is it a problem specific to PKI? I don't think so.

As I mentioned at the beginning, PKI is hideous, but because it is a absurd legacy system, and because of the fact it is misunderstood, too complex, and poorly documented.

recent (PKI related) news article thread

Security certificates warnings don't work, researchers say
http://www.garlic.com/~lynn/2009k.html#21
http://www.garlic.com/~lynn/2009k.html#23

as mentioned in the above ... ssl domain name digital certificates are redundant and superfluous ... frequently I've pontificated that most of the PKI-related hype has been to try and create the impression of a value proposition for the certificates.

original design point for digital certificates are the offline email days of the early 80s ... dial-up up electronic postoffice, exchange email, hang-up and then faced with authenticating first time communication with stranger. this is the electronic equivalent of the letters of credit/introduction from the sailing ship days (when relying party had no other alternative when faced with first time interaction with complete stranger).

we were called in to consult with small client/server startup that wanted to do payment transactions on server ... and the startup had invented this technology called "SSL". As part of that effort, we had to do business and technology walk thrus of the process ... including these new business operations calling themselves Certification Authorities.

I've frequently pontificated before that in that time-frame IPSEC was having difficulty (because it required upgrading underlying TCP/IP stacks, upgrading installed software on hundreds of millions of machines, upgrading underlying infrastructure). In fall '94 IETF meeting, what came to be called VPN was introduced in gateway committee meeting. My impression was this upset the IPSEC forces ... who eventually started referring to VPN as light-weight IPSEC (and gave the VPN folks the opportunity to refer to IPSEC as heavy-weight IPSEC).

The uptake of both VPN and SSL (in same time-frame) was because they didn't require any hits to underlying infrastructure ... in SSL case, it was purely new webserver software and new browser software (pure addon, w/o changes to existing legacy infrastructure).

The eventual problem (at least for SSL) is it layers a whole bunch of (technology and business operation) gorp on top of the underlying infrastructure ... that is much better integrated (seamlessly) into the underlying infrastructure (eliminating huge expense and complexity of duplicated operations). As SSL becomes pervasive ... the trade-offs change regarding the simplicity of adding something on-top verses seamless integration into the underlying infrastructure.

The SSL (PKI) security scenario is similar to lots of other security issues regarding the ease of adding something ontop (eventually creating huge complex patchwork) versus building security (seamlessly) into the basic design and implementation.

for a little other topic drift ... at '92 annual SIGMOD conference ... somebody raised the question about what was all this "x.5**" stuff about ... and somebody in the audience stated it was networking engineers attempting to reinvent 1960s database technology. some related posts:
http://www.garlic.com/~lynn/2009k.html#29 Oracle Database Abandons z/OS
and
http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing

lots of past posts mentioning SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

and lots of past posts mentioning certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

He he, ties right into the Symbian-signed mobile trojans news piece at El Reg..
http://www.theregister.co.uk/2009/07/23/sms_worm_analysis/

Quote

"Symbian reacted promptly to revoke these certificates. Handsets do not automatically check for these revocations, however. F-Secure warns: "The default setting in most Symbian phones has to be changed to enable them to receive revocation certificates. To do this, go to Application Manager's Settings and set the Online certificate check to Must be passed"."

Black Hat: SSL is fragile
http://www.computerweekly.com/Articles/2009/07/30/237120/black-hat-...

from above:

Researchers at the Black Hat security conference in Las Vegas have proved that the Secure Sockets Layer (SSL) protocol is fragile and could be broken at any time.

... snip ...

Note that we were brought in to consult with this small client/server startup that wanted to do payment transactions on their server and the startup had invented this technology called "SSL". As part of use for payment transactions, we had to do some end-to-end investigations of how the technology was being used and various business processes ... included some of this new operations calling themselves Certification Authorities. Part of the issue was that there were some specific requirements regarding how it was deployed ... which were almost immediately violated. That was one of the things that prompted us to coin the term "comfort certificates".

URL got truncated
http://www.computerweekly.com/Articles/2009/07/30/237120/black-hat-ssl-is-fragile.htm

Get a load of this.

OTHERWISE, ALL YOUR MONEY ARE BELONG TO US!!!111!!!

There are a whole load of things wrong with SSL and CA's certainly enough to fill a couple of books.

But discussing it is a bit like asking Nero to retune his fiddle, it's not going to stop the flames from spreading. with little doubt most security solutions are aimed at the wrong place in the wrong way and as such are a "bonfire of the vanities".

The real security issue which is being ignored is also the reason we use DOD TCP/IP not ISO OSI protocols and it's "pragmatism" and it's flip side "efficiency".

People need to get things done and in all honesty they care not how it is done just that it has the illusion of answering a need at a specific point of time within the available resources.

Due to various things the amount of data people want to move around appears to double about every 10 months, however it tends to hit the end stops of technology frequently enough to prevent the wished for target.

As long as there is a technology limitation and a market desire to go beyond it then pragmatism will win hands down every time.

Unfortunately pragmatism and security are usually not good bedfellows. Pragmatism is a business issue security a technical issue take a guess which one is going to win in a "free market economy".

Part of the issue is "efficiency -v- security", the more efficient a system the more it is susceptible to opening up side channels that leak information to those that know how to see it. Unless certain very fundamental steps are taken a system will always be vulnerable to "efficiency security weakness".

As an example unless a system designer clocks both the data in and the data out of a system then no matter how secure the OS the apps etc are a user can by exploiting simple timing attacks open up a side channel right through it (and even if the data is clocked synchronously there are a few other things that need doing as well).

With only moderately more work the side channel can be made covert enough that it is unlikely to be detected (ie below the "threshold of detection").

IPSec is not going to stop this and nor are most other security systems currently waiting in the wings.

So it does not really matter at what level above the real foundations (base hardware) of the system you put in security it is going to be possible to bypass it with a side channel that with only moderate work can be made covert to the point of invisibility.

The only real issue is the amount of bandwidth in the channel, the less there is the harder it is to spot the channel. But ask yourself the question just how much bandwidth do you need to leak a session key?