Between the two of us, Arjo and I have helped design, set up or run on the order of a dozen public key infrastructures (PKIs). Looking back, not a single one of these was not somehow embroiled in administrative or organizational infighting, bogged down by uncooperative management, or less-than-optimally functional due to design decisions taken for some sort of political reason. To use a colleague’s phrase, these things seem to attract managers like FOS — flies on you-know-what.
We were recently asked to put together a requirements paper for a PKI that was being re-engineered from the ground up. It occurred to me that this might actually be a stellar opportunity to help a client get things right from the start. So, why do we always get bogged down in PKI-related organizational or management issues?
Obviously, the PKI’s main purpose is management of digital certificates for persons, organizations and technical entities. Certificate keys fall into three general categories, which I’ll use Entrust nomenclature to describe: encryption (obvious enough), signing (you can be sure that what you got from me is what I intended to give you) and non-repudiation (you can be sure that I cannot disavow what I gave you.) So, let’s look at what you might actually use these for:
- User authentication (such as web sites or to workstations via smart cards)
- Email and file encryption
- Secure key exchange (e.g. for phase II IPSEC negotiation) between devices
- Source code, binary and other data signing (e.g. financial transaction information)
Why is this important? Two reasons: first, your certificate templates, which govern the formats of the certificates and their usage, depend on what you intend to do with certificates. In most certificates, for example, there is a key usage flag (a hex value) that is used for this.
Second, and more importantly, your LDAP structure must reflect you organizational structure, certificate usage and a number of other factors from the outset. This is usually the largest bone of contention in PKI design; the classic example is the Jane Doe who marries Bob Smith and changes her last name. So a distinguished name (DN) like C=Albania,O=Bob’s Widgets Inc,OU=Research,CN=Jane Doe is now kind of messy. This can be dealt with by using a friendly name, but you get the idea. Changes in requirements for LDAP attributes and DN structure affect other areas, like host naming, validity of signing and encryption keys, and and and. It gets even more fun when you start doing things like cross-certification, setting up a metadirectory for multiple directories, or integrating existing directory structures.
The upshot of all this is that a PKI affects all aspects of an enterprise that are in some way involved in authentication, security, encryption, verification of data integrity, etc. — and it has to pretty much be done right from the outset, or you run into problems of application integration, user acceptance and overall cost. We know of several directory projects that had their scope drastically cut down after they were built, when it was discovered that they simply wouldn’t work for some of what they were intended for; someone obviously hadn’t done their homework.
Most tragically, sometimes design decisions are taken or changed late in the development phase. I will recount one infamous experience of a client who, based on a few casual observations our team made, called a stakeholder meeting consisting of a room full of 35 people shouting at each other, and reversed his entire enterprise directory strategy _twice_ in the course of two hours. We’d done the underlying design and recommended a certain set of project technology several months previously, but were ignored due to political reasons. In this meeting, our group just tried to remain rational and calm, and to give information when prompted, but in the end we realized there was just nothing to be done and snuck out. It was telling that nobody noticed.
Probably, everyone who’s affected will want a piece of the discussion, and we all know how well design by committee works. Many managers also seem naturally threatened by (or nervous about) any technology that effects a lot of blanket organizational and procedural change — a perfect categorization of an enterprise PKI. It doesn’t help that such products sometimes carry the stigma of taking away autonomy from other groups; at some level, any infrastructure component using PKI certificate must follow certain standards and procedures, there’s just no way around that. This is often seen as a loss of self-determination, or it may require technical effort, and who’s going to pay for that?
So, how does one deal effectively with this? A lot of good PKI design practice involves some pretty common-sense elements:
- A knowledgeable, strong project manager who can organize management buy-in and support
- A small design team who’ve done this before and have a clue what they’re doing (good luck!)
- Individual discussions with potential stakeholders about what they want and how their concerns can be addressed
- A _lot_ of time spent on research and design — use the “hire a 6-year-old to spot any obvious flaws in your plan” model liberally here
- A clear idea of budget responsibilities in PKI deployment — but not to the end that every affected team will try to pawn off even minor changes on the PKI budget
And last but defnitely not least, a really good LDAP guy, you won’t regret it.
p.s.: If you’re interested in reading more about non-repudiation, including how it differs from the usual technical usage of “signing”, have a look at Non-Repudiation in the Digital Environment.
Recent Comments