Public Key Infrastructure (PKI) has been reviewed as a technical infrastructure by a number of security experts. In this paper we look at a number of pratical organizational issues that pure PKI suppliers often fail to mention.
Identification is inflexible – in my enterprise people move from one job to another and one location to another on a regular basis, but the PKI certificate is just inflexible unless I miss most of the stuff that would be useful in our internal directory;
CA hierarchy – doesn’t mean anything to us. We aren’t an organization structured out of Verisign or Entrust. They can’t ever be responsible for our people so why do they want to get in on the act and charge us as well? If anyone is going to make statements about our business it’s Standard and Poors, or Dun and Bradstreet, and not some IT shop;
Cross certification – we’re ISO 9000/1400 compliant so why do we need all this other stuff? If quality systems doesn’t include doing our security properly then something must be seriously wrong. Anyway – if we ever understand what is a certificate practice statement means why is it essential that we do it just like everyone else? We run our HR department just fine thank you.
Revoking our users – how come we can’t just stop them working, the same as we can with their Windows logon? Surely this is fundamental. The idea that we have to build an enormous system to publish information internally so that everyone has to check it all the time and use up horrendous amounts of bandwidth and resource does not stack up when it should have been implemented as a control just like logon;
Other people’s revocations – how is this supposed to work actually? Will other organizations actually let us see their directories and revocation systems? Given the complexity of those systems how can we rely on them anyway;
Relying party liability – get real. If we are stupid enough to put this one in front of our finance people they will shred us faster than you can say Sarbanes-Oxley. The only people we can rely upon is us, unless we have it in writing. So what we need is a system where we can switch on and off who we are willing to do business with whenever we choose. We certainly don’t want to be left letting them tell us if they can do business, which is what the whole relying party/revocation approach is all about;
Interoperability – what I actually wanted to do was enable our users to exchange some files with business partners when that was absolutely necessary. I don’t see the standard for an encrypted file(s) anywhere. What good is it having all this digital signature stuff if there’s no clear standard, like the OpenPGP one (that exists, is well proven and very widely implemented so that we can feel very good about it working), so that we all know what we are doing;
Identity provisioning – I can see a whole boatload of standards for XML that appear to use this PKI stuff but I just can’t see what it is supposed to be delivering. If I set it up to control the people inside then it is no help at all dealing with the people outside because they are not playing by my rules;
Organization – how come PKI hasn’t come up with how to work within departments or groups, or have a company wide public key? I just don’t see how any system can ever work that demands we work individual to individual rather than customer to business or business to business. We aren’t going to publish the public keys of all our employees to the world, so how does the first exchange with someone outside actually happen?
Economic model – we don’t want to embed a technology deep into my business only to find that the supplier can change the price on us whenever it suits them. This is not a sensible economic model for either of us. If our supplier is not delivering value-add or ROI then they should not be billing us at all. Having software is not a license to print money, after all.