Java Security

A Key Management Example

The Sun implementation of the keytool utility is useful in many circumstances where users have disjoint databases. In Figure 11.1 we showed just such an example, and we mentioned that this example was set up in such a way that the code signer and the end user could have different key databases.

This is not to say, however, that those two databases could not have been the same database—that is, one that is shared by the signer and the end user. Since access to the private key of the signer is protected by a password, the signer and the end user are able to share a single database without concern that the end user may obtain access to the signer’s private key (assuming that she keeps her password secret, of course). In the case of a corporate network, this flexibility is important, since an enterprise may want to maintain a single database that contains the private keys of all of its employees as well as the certificates of all known external entities.

We could have these users share the keystore by using the appropriate filename in the application and the java.policy files. But sharing the keytool database by a file is somewhat inefficient. If the global file is on a machine in New York and is referenced by a user in Tokyo, you’ll want to use a better network protocol to access it than a file-based protocol. In addition, the load() method reads in the entire file. If there are 10,000 users in your corporate keystore database, you shouldn’t need to read ...