This chapter advises on points to remember, ideas to consider, and pitfalls to avoid if you
are designing a PKI for your organization. This is by no means an exhaustive list, but is intended to be helpful in suggesting points to consider.
- Don't design a PKI with a particular application in mind - rather, think of it as a fundamental part of your organization's general data processing setup. If you design it for use with a particular application, you are likely to find it inflexible when you try to use it with other applications.
- Authentication doesn't imply authorization. Just because someone has the necessary keys to access your data, that doesn't mean they necessarily should be allowed access to all your data. You should still have other mechanisms, for example an access control list (ACL), to ensure people can only access data appropriate to their position.
- You should make people change their keys from time to time, by applying for new certificate/key pairs. That way if a private key is stolen without anyone noticing, at least it will become useless to the thief next time the certificate/key pair is changed.
This applies to all private keys - client keys, server keys, subordinate CA keys, and root CA keys.
The easiest way to enforce this is to include expiry dates in certificates.
- There are many ways of structuring your tree of trust. Should there be just one root CA, or several? Should subordinate CAs be able to grant CA certificates to other subordinate CAs, or should only root CAs be able to do this?
- Will your CAs sometimes need to revoke certificates? The commonest way to do this is for a CA to maintain a certificate revocation list (CRL), a list of certificates it has granted and later revoked (they can be deleted from the list once they expire). Users can obtain the CRL and install it in their SSL software.
- Will users generate their own private keys? In some setups, the CA generates both the certificate and the private key for the user. This saves the ordinary user needing to know how to create a certificate signing request (many of the major CAs on the Web are willing to work in this way) but it means the private key must somehow be conveyed securely to the user. To obtain the maximum security benefit of asymmetric encryption - that the private key is never sent anywhere, so can't be listened in on - the user should him/herself use openssl.exe to create a private key and the matching certificate signing request, and send the latter to the CA, so the CA can create the certificate.
- It may be an advantage to have all certificate requests handled by your subordinate CA machines. Then your root CA machine only needs to be online when you are using it to certify subordinate CAs. After that it can be taken offline, or at least its private key can be stored offline, until you need it to certify more subordinate CAs. This can greatly improve the security of the root CA, by reducing to a minimum the times when it could be accessed illicitly. It also means the users are not dependent on a single machine, the root CA machine, to keep functioning.
It will still be possible - and simpler - to have your users install the root CA's certificate in their browsers (or whatever SSL-enabled software they use) rather than the certificates of all the subordinate CAs.
- If you want really tight control, you might want to delete from your Web browser all the CA certificates that have been installed by default, and install just certificates of your own choosing - from your own CA, if you are setting up a private PKI. However you'd have to think carefully about the effect on accessing other Web sites outside your PKI.
- If as a Web site owner you want the benefits of non-repudiation, that is, you want to be able to prove that data really was sent to you from a particular client, then you should use full authentication - you can if you wish generate client certificates for your clients (acting as a CA to this extent) and send the clients their certificates for them to store and use. Remember your clients will need to understand how to install these personal certificates in their software, e.g. their browsers.
- It's worth pointing out a few features of the "world-wide" PKI used on the World Wide Web, which you may or may not choose to emulate in your own PKI:
- It uses server-only authentication - although there's nothing to stop a particular online service arranging with its known clients that they should have to have certificates.
- All CAs are equally trusted - there's no concept of some being trusted more than others.
- When a certificate/keyfile pair is created, you can create pass phrases to protect them. It's essential to protect the keyfile in this way, because a private key is extremely sensitive information and every form of security available should be used to protect it. However, a certificate is intended to be available to anyone who wants to see it, so it's seldom appropriate to protect it in this way.
In looking at certificates installed in Web browsers, you may have noticed that (using Internet Explorer terminology, but the situation is the same with any Web browser) the Personal and Other People's lists are empty or nearly empty, while the Intermediate CA and Trusted Root CA lists contain many entries.
This is a fairly typical situation. As an ordinary Web user, you probably don't actually need a certificate of your own - Web businesses such as online banks and shops generally use server-only authentication. As for Other People's, you could install server certificates sent to you by such online businesses, but it's generally unnecessary as these businesses send their certificates in the initial hand-shake of any communication session. It's much more necessary to have CA certificates installed, since these are needed to validate the certificates these businesses send you.
You might sometimes find it useful to install an entity's client certificate, if you communicate with them peer-to-peer rather than client/server.
The security of your CA and RA machines is vital.
Remember you need to ensure reliability and availability, as well as confidentiality and trustworthiness.
Remember that SSL protects data only while it is in transit - once it has been received and stored, it is no longer encrypted, and so you need to look to other methods to ensure it remains confidential.
You will of course need to protect your machines with a firewall and with virus scanning, and require any user accessing the machines remotely (if you allow this at all) to login, giving their user ID and password.
It's advisable to have the latest version of your operating system - the security features are usually improved at each upgrade.
You should certainly require anyone using your CA and machines locally on to login, giving their user ID and password, and you should probably control access to the computer room too, so that no-one authorized can even get to the machine.
Also ask yourself about other ways an interloper could get in. Could someone insert an USB device between the printer and the system? Could someone run code from an I/O device? Could someone trick their way into your site by talking to the people who work there, finding out how they work, and emulating them?
The private keys of your CA machines are vital. Keep them backed up to guard against accidental loss - but keep the backups every bit as secure as the system itself, to guard against them being stolen.
Copyright © 2009 Micro Focus (IP) Ltd. All rights reserved.