Of course, the great problem with a one-time pad is key management. In this example, the CD-ROMs containing the key would have to be physically transported to both the sender and receiver. The key couldn't be transmitted across the network, because that would expose it to capture and violate the single use principle of the one-time pad. Furthermore, precautions might need to be taken to ensure that the CD-ROMs weren't serendipitously copied en route. Once used, the CD-ROMs couldn't just be discarded, because the used key might then fall into malicious hands and be used to decrypt previously recorded cryptotext. These issues are for perhaps the simplest cryptosystem ever devised, so imagine how much more complex key management becomes for practical systems!
Two major issues in key management are key lifetime and key exposure. The lifetime of a key is the limit of its use, which can be measured as an duration of time, or as the amount of data encrypted with the key. Every time a key is used, cryptotext is generated and transmitted, potentially into the hands of an attacker trying to cryptoanalyze the traffic and discover the plaintext. The more cryptotext an attacker possesses, the more information he possesses and the better the chances of unraveling the key and discovering its secrets. Therefore, lifetime and exposure are closely related concepts. Long-duration keys should be infrequently used, and oft-used keys should have a short, carefully limited lifetime.
To meet the conflicting demands of encrypting a significant amount of data using a long-lived key, keys are usually chained. For example, consider an email message encrypted with PGP, using the recipient's RSA public key to ensure that only he can read the message. An RSA key pair used to establish identity would be a fairly long-lived key, since the public key would probably be published and made available for anyone wanting to send the owner secure email. Therefore, the entire message would not be encrypted with this key. Instead, the sender would randomly generate a block cipher key, perhaps a 128-bit key for IDEA or a 168-bit key for Triple DES, and encrypt the message using this key. Then, the block cipher key (only 128 or 168 bits) would be encrypted using the RSA public key and attached to the message in a header. An attempt to crack the message would have less than a hundred bytes of RSA cryptotext to work with. Even if the main body of the message could be cracked to reveal the block cipher key, this would only compromise the single message, not any other encoded using the RSA key. Key chaining is a common technique used by almost every major cryptographic protocol.
Another key management issue is the encryption of key itself. Long-lived keys used only periodically (PGP keys, for encrypting and authenticating email, for example) are often encrypted to protect them while stored on disk. The encryption is typically done using a conventional symmetric cipher, its key formed from the hash of a user-supplied passphrase. To use the key, its owner must enter the passphrase when prompted. The entered passphrase is then hashed, and the hash used to decrypt the key, which is formatted so that if the wrong passphrase is provided, the decryption will produce gibberish, which won't match the format. Use of the key thus requires knowledge of the passphrase. Obviously, a key stored in this manner can't be used by automated processes. Encrypting the key implies that it will only be used when a user is available to supply the passphrase.
I recently had the unpleasant experience of having forgotten the passphrase to a fairly important key. For long-lived keys of any importance, I suggest keeping an unencrypted version of the key in a secure location, perhaps a floppy disk or CD-ROM locked in a safe deposit box. Even if you keep an encrypted copy of the key available for periodic use, I suggest locking away at least one unencrypted copy.