Previous     Contents     Index     Next     
iPlanet Certificate Management System Installation and Setup Guide



Chapter 22   Setting Up Key Archival and Recovery


When data is stored in encrypted form, you must have the private key that corresponds to the public key that was used to encrypt the data in order to decrypt and read it. If the private key is lost, the data cannot be retrieved. A private key can be lost because of a hardware failure, for example, or because the key's owner forgets the password or loses the hardware token in which the key is stored. Similarly, encrypted data cannot be retrieved if the owner of the key is unavailable to supply it—for example, has left the organization that owns the data.

This chapter explains how to use the Data Recovery Manager to archive users' encryption private keys and how to use the archived keys later, in place of missing encryption keys, to recover encrypted data.

The chapter has the following sections:



PKI Setup for Key Archival and Recovery

To be able to archive users' encryption private keys and recover them later, you need a PKI setup that includes the following elements:

  • Clients that can generate dual keys and that support the key archival option (using the CRMF/CMMF protocol)

  • An installed and configured Data Recovery Manager

  • HTML forms with which your users can request dual certificates (based on dual keys) and key recovery agents can request key recovery

The sections that follow explain these elements in detail. For step-by-step instructions on setting up your PKI environment for key archival and recovery, see "Configuring Key Archival and Recovery Process".


Clients That Can Generate Dual Key Pairs

Only keys that are used exclusively for encrypting data should be archived; signing keys in particular should never be archived. Having two copies of a signing key would defeat the certainty with which the key identifies its owner; a second copy could be used to impersonate the digital identity of the original key owner.

Clients that generate single key pairs use the same private key for both signing and encrypting data, so you cannot archive and recover a private key deriving from a single key pair. By contrast, clients that can generate dual key pairs use one private key for encrypting data and the other for signing data. Because the encryption private key is separate, you can archive it.

In addition to generating dual key pairs, your users' clients must also support the encryption key archival option in certificate requests. This option triggers the key archival process at the time encryption private keys are generated as a part of certificate issuance.

Netscape 6 and Netscape Communicator versions 4.7x (when used in conjunction with Netscape Personal Security Manager) support generation of dual key-pairs. For a brief introduction to Personal Security Manager, see page 40.


Data Recovery Manager

With the Data Recovery Manager, you can archive data encryption keys when they are created during dual key-pair generation. You can then recover the keys if they are lost or the key owner is unavailable.

The Data Recovery Manager can archive and recover keys only from clients that support dual key-pair generation and the key archival option in certificate requests.

Certificate Management System does not provide any policy plug-in modules for the Data Recovery Manager. However, you can write custom policy plug-in modules (that is, write Java classes that implement these rules), register them in the Data Recovery Manager's policy framework, and create policy rules using these plug-in implementations. For details about writing custom plug-ins, see "CMS SDK".


Forms for Users and Key Recovery Agents

End users' encryption private keys are archived by the Data Recovery Manager when they are generated. So, for key archival to occur, the enrollment form that users fill out to request dual certificates must have the JavaScript code for activating the key archival process embedded in it, along with a valid copy of the Data Recovery Manager's transport certificate. Then, when a Certificate Manager or Registration Manager that is processing the user's certificate issuance request detects the key archival option, it automatically requests the service of the Data Recovery Manager. For information on customizing this form, see "Step C. Customize the Certificate Enrollment Form".

Initiating the key recovery process also requires its own HTML form. By default, the Data Recovery Manager Agent Services interface provides a form for initiating the process and retrieving keys. For information on customizing this form, see "Step D. Customize the Key Recovery Form".



Key Archival Process


If your certificate infrastructure has been set up for key archival, the Data Recovery Manager automatically archives users' encryption private keys. For general information on the type of PKI setup needed for archiving keys, see "PKI Setup for Key Archival and Recovery". For specific instructions on setting up a key archival and recovery infrastructure, see "Configuring Key Archival and Recovery Process".


Why You Should Archive Keys

If a user loses a private data-encryption key or is unavailable to use his or her private key, the key must be recovered before any data that was encrypted with the corresponding public key can be read. You can recover the private key if an archival copy of it was created when the key was generated.

Here are a few situations in which you might need to recover a user's encryption private key:

  • An employee loses the encryption private key (for example, after a disk crash or by forgetting the password to the key file) and cannot read encrypted mail messages.

  • An employee is on an extended leave, and you need access to an encrypted document in his or her files.

  • An employee leaves the company, and company officials need to perform an audit that requires gaining access to the employee's encrypted mail.


Where the Keys are Stored

If configured properly, the Data Recovery Manager, stores your users' encryption private keys automatically whenever the associated or connected Registration Manager or Certificate Manager issues certificates to your users. The Data Recovery Manager stores encryption private keys in a secure key repository in its internal database; each key is stored as a key record.

The archived copy of the key remains encrypted (or wrapped) with the Data Recovery Manager's storage key; see "Storage Key Pair". It can be decrypted (or unwrapped) only by using the corresponding private key, to which no individual has direct access. A combination of one or more key recovery agents' passwords enables the Data Recovery Manager to retrieve its private storage key and use it to decrypt and recover an archived key. For details on how this process works, see "Key Recovery Agents and Their Passwords".

The Data Recovery Manager indexes stored keys by key number (or ID), owner name, and a hash of the public key, allowing for highly efficient searching by name or by public key. The key recovery agents have the privilege to insert, delete, and search for key records. The search feature works like this:

  • When the key recovery agents search by the key ID, only the key that corresponds to that ID is returned.

  • When the agents search by user name, all stored keys belonging to that owner are returned.

  • When the agents search by the public key in a certificate, only the corresponding private key is returned.


How Key Archival Works

When a Certificate Manager or Registration Manager receives a certificate request that contains the key archival option, it automatically requests the service of the Data Recovery Manager to archive the user's encryption private key. The Data Recovery Manager receives an encrypted copy of the user's private key and stores the key in its key repository. To archive the key, the Data Recovery Manager uses two special key pairs:

  • A transport key pair and corresponding certificate

  • A storage key pair

Figure 22-1 illustrates how the key archival process occurs when a user requests a certificate. The deployment scenario shown in this figure has a Registration Manager acting as the trusted enrollment authority to a Certificate Manager and Data Recovery Manager.

Figure 22-1    How the key archival process works

These are the steps shown in Figure 22-1:

  1. A user uses a client capable of generating dual key pairs to access the certificate enrollment form served by the Registration Manager, fills in all the information, and submits the request.

    The Registration Manager detects the key archival option in the user's request and asks the client for the user's encryption private key.

    The client encrypts the user's encryption private key with the public key from the Data Recovery Manager's transport certificate; a copy of the transport certificate is embedded in the enrollment form.

  2. Upon receiving the encrypted key from the client, the Registration Manager sends it to the Data Recovery Manager for storage, along with some other information (including the user's public key). Then, the Registration Manager waits for verification from the Data Recovery Manager that the private key has been received and stored and that it corresponds to the user's public encryption key.

  3. Upon receiving the encrypted key from the Registration Manager, the Data Recovery Manager decrypts it with the private key that corresponds to the public key in its transport certificate. After confirming that the private encryption key corresponds to the user's public encryption key, the Data Recovery Manager encrypts it again with its storage key before storing it in its internal database. (The storage key either resides in a software or a hardware token and is never exposed to any other entity.)

  4. Once the user's private encryption key has been successfully stored, the Data Recovery Manager uses the private key of its transport key pair to sign a token confirming that the key has been successfully stored; the Data Recovery Manager then sends the token to the Registration Manager.

  5. After the Registration Manager receives and verifies the signed token, it sends the certificate request to the Certificate Manager for issuance.

  6. The Certificate Manager formulates two certificates, one each for signing and encryption key pairs, and returns them to the Registration Manager.

  7. The Registration Manager forwards the certificates to the client (the user).

Note that all three subsystems subject the request to configured policy rules at appropriate stages. If the request fails to meet any of the policy rules, the subsystem rejects the request.



Key Recovery Process


The Data Recovery Manager supports agent-initiated key recovery. In this method of key recovery, designated recovery agents use the Key Recovery form provided in the Data Recovery Manager Agent Services interface to process key recovery requests, list archived keys, and approve recovery. With the approval of a specified number of agents, an organization can recover keys when the key's owner is unavailable or when keys have been lost.


Key Recovery Agents and Their Passwords

Key recovery agents have the authority to retrieve end users' encryption private keys. The recovery agent's role can be performed by any person in your organization. As system administrator, you can designate one or more individuals to be key recovery agents. These individuals need to do the following:

  • They must specify a secure password, which in combination with other recovery agents' passwords will be used for protecting the database in which the Data Recovery Manager stores users' keys. You facilitate this by allowing each recovery agent to enter a password in the Data Recovery Manager configuration.

  • They must be available to retrieve your users' encryption private keys if the need arises. It isn't necessary for all key recovery agents to be available for the key recovery operation. You specify how many agents are required to authorize the recovery of a key; see "Key Recovery Agent Scheme". However, the specified number of key recovery agents must all provide their passwords at the same time to authorize the recovery of a specific key.

The first time you create key recovery agents and specify their passwords is during the installation of the Data Recovery Manager. However, you can change the number of recovery agents and their passwords later by modifying it in the Data Recovery Manager configuration; see "Changing Key Recovery Agents' Passwords".


Secret Sharing of Storage Key Password

The Data Recovery Manager uses the private key of its storage key pair to encrypt the repository where it store users' encryption private keys. This requires that the storage key be well protected. For the protection of the storage key pair, the Data Recovery Manager supports a password-splitting mechanism called m of n secret splitting or sharing, whereby it splits the PIN that protects the token in which the storage key pair resides among n number of key recovery agents and reconstructs the PIN only if m number of recovery agents provide their individual passwords; n must be an integer greater than 1 and m must be an integer less than or equal to n.

Here's how the m of n secret splitting mechanism gets built and works:

During the installation of a Data Recovery Manager, you generate the storage key pair and specify the hardware token in which the key pair is to be stored. At this time, you also specify a PIN (or password) to protect the token, the total number of key recovery agents (n), and how many of these agents (m) are required to perform a key recovery operation. You can change the m of n secret splitting later; for details, see "Key Recovery Agent Scheme".

The Data Recovery Manager splits the PIN for the token into n parts or pieces. It then encrypts these parts with the passwords that are provided by the authorized key recovery agents.

During the key recovery procedure, the required number of key recovery agents (m) provide their identifiers and passwords. After verifying the passwords, the Data Recovery Manager reconstructs the PIN for the token based on the given information.


Interface for the Key Recovery Process

With the Key Recovery form provided in the Data Recovery Manager Agent Services interface, key recovery agents can collectively unlock the key repository of the Data Recovery Manager and retrieve end users' encryption private keys and associated certificates in a PKCS #12 package, which can then be imported into the client. For an overview of this process, see "How Agent-Initiated Key Recovery Works".

Because key recovery agents use the Data Recovery Manager Agent Services interface, agent-initiated key recovery invariably involves the Data Recovery Manager agent and key recovery agents. The Data Recovery Manager agent's certificate is required to access the Key Recovery form, and key recovery agents' passwords are required to unlock the key repository. For information on Data Recovery Manager agents, see "Agents".

Your organization's PKI policy may require that the key recovery process be restricted to authorized recovery agents only, preventing any Data Recovery Manager agent from being involved. If so, you should ask all key recovery agents to get client certificates and set them up as Data Recovery Manager agents. For instructions, see "Setting Up Agents".


Local Versus Remote Key Recovery Authorization

Key recovery agents can authorize the recovery of a key locally or remotely. The overview of local and remote authorization provided in this section is intended to help you determine which to use for your organization. You may find it useful to take a look at the Data Recovery Manager agent-specific information in the CMS Agent's Guide.


Local Key Recovery Authorization
To initiate key recovery locally, the required number of recovery agents assemble in front of the host system that allows them to access the Data Recovery Manager Agent Services interface. Either a Data Recovery Manager agent or a key recovery agent with a Data Recovery Manager agent certificate accesses the Key Recovery form hosted by the Data Recovery Manager and initiates the key recovery process. All key recovery agents enter their IDs and passwords on the same Recovery Authorization form presented by the Data Recovery Manager. If the information presented is correct, the Data Recovery Manager retrieves the requested key and returns it along with the corresponding certificate in the form of a PKCS #12 package.

By default, key recovery authorization is local.


Remote Key Recovery Authorization
To authorize key recovery remotely, the required number of recovery agents access the Data Recovery Manager Agent Services interface at their own locations and use the Authorize Recovery button to enter each authorization separately.

Before key recovery agents can authorize key recovery remotely, they must be set up to function as Data Recovery Manager agents. This role gives them the privilege to access the Data Recovery Manager's Agent Services interface directly.

In remote key recovery authorization, one of the key recovery agents informs all required recovery agents about an impending remote key recovery process. All recovery agents access the Key Recovery page hosted by the Data Recovery Manager. One of the agents initiates the key recovery process. The Data Recovery Manager returns a notification to each agent. The notification includes a recovery authorization reference number identifying the particular key recovery request that the agent is required to authorize. Each agent uses the reference number and authorizes key recovery separately.

The Data Recovery Manager informs the agent who initiated the key recovery process of the status of the authorizations. When all of the authorizations are entered, the Data Recovery Manager checks the information. If the information presented is correct, it retrieves the requested key and returns it along with the corresponding certificate in the form of a PKCS #12 package to the agent who initiated the key recovery process.

Key recovery agents can switch to remote authorization by deselecting the local authorization option in the Key Recovery form.


How Agent-Initiated Key Recovery Works

In an agent-initiated key recovery, the key is recovered by the collective efforts of a Data Recovery Manager agent and authorized key recovery agents. You may need to resort to this type of key recovery if the owner of a key cannot be reached and the authorities in the organization need to access that user's encrypted data (for example, S/MIME mail messages).

Upon retrieving the private encryption key (in the form of a PKCS #12 package), the agents may forward the key to the original user, the manager of the original owner, or some other authorities.

Figure 22-2 illustrates how agent-initiated key recovery works.

Figure 22-2    The agent-initiated key recovery process

These are the steps shown in Figure 22-2:

  1. The Data Recovery Manager agent accesses the Key Recovery form using the appropriate client certificate, types the identification information pertaining to the person whose encryption private key needs to be recovered, and submits the request.

    The request is submitted to the Data Recovery Manager over HTTPS.

  2. The Data Recovery Manager subjects the key recovery request to its policy checks.

  3. If the request passes all the policy rules, the Data Recovery Manager sends a confirmation HTML page to the web browser the agent used. If the request fails any of the policy checks, the server logs an appropriate error message.

    The confirmation page contains information and input sections:

    • The information section includes the user's information.

    • The input section includes fields for entering the user's certificate corresponding to the key that needs to be recovered, the password for the PKCS #12 package, and key recovery agents' passwords.

      The Data Recovery Manager uses the certificate to construct the
      PKCS #12 package (which includes the user's encryption private key and corresponding certificate), the PKCS #12 password to encrypt the PKCS #12 package, and key recovery agents' passwords to construct the PIN required to unlock its key repository.

  4. The key recovery agents verify the information in the confirmation page and enter the certificate in MIME-64 format, the password for the PKCS #12 package, and their individual identifiers and passwords. The Data Recovery Manager agent submits the page to the Data Recovery Manager.

  5. The Data Recovery Manager matches the key recovery agent information with its m of n scheme (see "Key Recovery Agent Scheme"). After verifying that the required number of recovery agents entered their passwords, the server uses the agents' passwords to construct the PIN required to access the private key repository.

  6. The Data Recovery Manager then retrieves the user's private key from its key repository and decrypts it by using the private component of the storage key pair.

  7. The Data Recovery Manager packages the user's certificate and the corresponding private key as a PKCS #12 package and encrypts it with the PKCS #12 password provided by the recovery agent. It then delivers the package to the client the recovery agent used to initiate the key recovery process, and prompts the agent to store the encrypted package. The agent may choose to store the package in the local file system of the client machine (only if it has restricted access) or on a floppy diskette.

    The recovery agent can then send the encrypted PKCS #12 package and the corresponding password to an individual by any secure, out-of-band means.


    Caution

    		The PKCS #12 package contains the private key. To minimize the risk of key compromise, the recovery agent must use any secure, out-of-band means to deliver the PKCS #12 package and password to the key recipient. As an administrator, you should recommend the recovery agent to use a good password for encrypting the PKCS #12 package, and also consider setting up an appropriate delivery mechanism.



Key Recovery Agent Scheme

The key recovery agent scheme consists of configuring the Data Recovery Manager to recognize a fixed number of key recovery agents (a minimum of one) and specifying how many of these agents are required to authorize a key recovery request before the archived key is restored. Each recovery agent provides the Data Recovery Manager with a password, which it uses to generate a unique PIN; the Data Recovery Manager uses the PIN to protect its storage key pair, which in turn protects users' keys.

The Data Recovery Manager tracks the key recovery agent password for each agent and allows you to facilitate changing agents' passwords; you do not have direct access to these passwords or the actual storage key password. Each password retrieves only a part of the private storage key.

You first specified the key recovery agent scheme when you installed the Data Recovery Manager.


Changing the Key Recovery Agent Scheme

You can change the total number of key recovery agents for a Data Recovery Manager and the number of key recovery agents required to retrieve an end user's encryption private key from the Data Recovery Manager's key repository.

To change the key recovery agent scheme:

  1. Access the CMS window (see "Logging In to the CMS Window").

  2. Click the Configuration tab.

  3. In the navigation tree, select the Data Recovery Manager, and in the right pane, click the Scheme Management tab.

    The Scheme Management tab shows the current key recovery scheme.

  4. Click Change scheme.

    The Change Recovery Key Scheme window appears.

  5. In the New Scheme section, make the appropriate changes:

    Number of recovery agents required. Type the number of agents required to authorize a key recovery process. The number cannot be zero and must be equal to or less than the total number of recovery agents.

    Total number of recovery agents. Specify the total number of key recovery agents. The number cannot be less than one and must be equal to or greater than the number of agents required to authorize the key recovery operation.

  6. Click Next.

  7. For each agent, enter a user name and password, then click Next.

    The number of screens depends on the total number of agents you have specified.

  8. When you have entered all agent information, click Finish.

    You are returned to the Scheme Management tab.


Changing Key Recovery Agents' Passwords

As administrator, you have the responsibility of safeguarding the security of each Data Recovery Manager installed in your PKI setup. One of the safety measures you can implement is to ask your key recovery agents to change their passwords periodically. This way, you will be sure that the required number of agents are available if a key needs to be recovered. If key recovery agents routinely change their passwords, they are less likely to forget them.

The CMS window allows you to view the list of currently designated key recover agents and, if necessary, change an agent's password.

To change key recovery agents' passwords:

  1. Access the CMS window (see "Logging In to the CMS Window").

  2. Click the Configuration tab.

  3. In the navigation tree, select the Data Recovery Manager, and in the right pane, click the Recovery Agent Password tab.

    The tab shows current key recovery agents in the Available Agents list.

  4. Select the agent whose password needs to be changed, and click Change Password.

    The Change Password dialog box appears.

  5. Allow the agent to enter the appropriate information.

    During installation, the Data Recovery Manager prompts you to enter key recovery agent passwords (by default, they are set to agent<n>, where <n> can be 1, 2, and so on, depending on the number of agents). The number of passwords you must enter depends on the key recovery agent scheme you chose; for details, see "Key Recovery Agent Scheme". If you are changing a password for the first time after installation, in the "Old password" field you must enter the recovery agent password you specified during installation. Then in the remaining fields, allow the key recovery agent to enter the new password information. If you have more than one key recovery agent, repeat this procedure for all the agents.

    Old Password. Type the current password for the key repository.

    New Password. Type the new password for the key repository.

    Confirm Password. Retype the new password exactly as you typed it in the previous field.

  6. Click OK.

    You are returned to the Recovery Agent Password tab.



Configuring Key Archival and Recovery Process

By default, the Data Recovery Manager is not configured to archive or recover end users' encryption private keys. This section explains how to set up key archival and recovery processes.


Step 1. Set Up the Key Archival Process

Before proceeding with this section, you should have read "Key Archival Process". In particular, you should be familiar with how the key archival process works. If you are not, see "How Key Archival Works".

To set up the key archival process, follow these steps:


Step A. Deploy Clients That Can Generate Dual Key Pairs

You can use the Data Recovery Manager to archive and recover keys only from clients that support dual key-pair generation, the key archival option, and the CMC protocol. Clients that do not meet this criteria cannot be used with the Data Recovery Manager. To understand why you need to use clients that can generate dual key pairs, see "Clients That Can Generate Dual Key Pairs". The same section also points you to an introduction to Netscape Personal Security Manager, which when plugged into Netscape Communicator version 4.7x enables it to support the CMC protocol and generate dual key pairs.

You may have already installed Personal Security Manager—for example, you might have installed it as an OCSP-compliant client when setting up a Certificate Manager to publish CRLs to an OCSP responder; see "Step 2. Install an OCSP-Compliant Client".


Step B. Connect the Enrollment Authority and the Data Recovery Manager

Key archival occurs when dual key pairs are generated by the client. The client generates the key pairs when a user requests a certificate by filling out the appropriate certificate enrollment form served by an enrollment authority, which can be either a Certificate Manager or a Registration Manager. When the enrollment authority detects the key archival option in the request, it initiates the key archival process and requests the service of the Data Recovery Manager for archiving the key.

For the enrollment authority to be able to request the service of the Data Recovery Manager, the two subsystems must be configured to recognize, trust, and communicate with each other. When you installed the Data Recovery Manager, you were asked to connect it to a Certificate Manager or Registration Manager. You might have specified some of the configuration information required for the two subsystems to communicate with each other. Also, if the enrollment authority and the Data Recovery Manager are installed in the same CMS instance, certain configurations are done automatically.

However, to ensure that key archival takes place successfully, you must make sure that the Data Recovery Manager is connected to the appropriate enrollment authority. Also verify whether the enrollment authority has been set up as a privileged user, with an appropriate SSL client authentication certificate, in the internal database of the Data Recovery Manager. By default, the Certificate Manager uses its SSL server certificate for SSL client authentication, whereas the Registration Manager uses its signing certificate for this purpose; for more information, see "Keys and Certificates for the Main Subsystems".

Otherwise, follow the instructions in "Setting Up Trusted Managers" and set up the enrollment authority as a trusted front end to the Data Recovery Manager.


Step C. Customize the Certificate Enrollment Form

For the enrollment authority to automatically initiate the key archival process at the time key pairs are generated, a certificate request must include the following information:

  • The key archival option—this must be included in the certificate enrollment form that your users use to request certificates.

  • The Data Recovery Manager's transport certificate—this must also be included in the certificate enrollment form. The Data Recovery Manager uses it to encrypt the user's encryption private key with the public key in the transport certificate before sending the user's key to its key repository. For information about the key repository, see "Where the Keys are Stored".

    Make sure that the transport certificate, in its base-64 encoded format, is embedded in the form. Otherwise, the Data Recovery Manager will fail to archive users' keys.

All the end user enrollment forms provided by Certificate Management System—for example, the directory-based enrollment form (DirUserEnroll.html), directory- and PIN-based enrollment form (DirPinUserEnroll.html), and manual enrollment form (ManUserEnroll.html)—contain the necessary JavaScript code for initiating the key archival process. If you are using any of these forms for end-user enrollment, make sure to update the generateCRMFRequest() JavaScript method. If you plan to use custom enrollment forms for users, be sure to include the required JavaScript code in those forms.

Figure 22-3 shows the default directory-based enrollment form with the information related to the generateCRMFRequest() JavaScript method highlighted. Note that the JavaScript method includes parameters for specifying various things. You are required to update the following information only:

  • The Data Recovery Manager's transport certificate.

  • The algorithm, length, type, and usage for end users' key pairs. When you update this information, the key archival option is automatically set. For information on specifying the key type, length, and algorithm, see generateCRMFRequest() in Javascript API for Client Certificate Management. This document is located where you extracted Personal Security Manager files after downloading it from the web site. You can also get the latest version of this document from http://docs.iplanet.com/docs/manuals/psm.html.

The steps that follow explain how to do this.

Figure 22-3    Data Recovery Manager's transport certificate in the enrollment form


  1. Copy the transport certificate in its base-64 encoded format.

    The transport certificate is stored in the Data Recovery Manager's certificate database. If the transport certificate is signed by a Certificate Manager, then a copy of the certificate is also available with the Certificate Manager. Follow the instructions as appropriate.

    To copy the transport certificate information from a Certificate Manager's database:

    1. Open a web browser window.

    2. Go to the end-entity page hosted by the Certificate Manager.

    3. Click the Retrieval tab.

    4. List or search for the transport certificate.

    5. Click Details, and view the certificate information.

      Make sure that the certificate you are looking at is the correct one; the certificate shows the DN that was specified for the transport certificate during the installation of Data Recovery Manager.

    6. Scroll down to the section that says "Installing this certificate in a server."

    7. Copy the base-64 encoded certificate, excluding the marker lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, to a text file. An example is shown below:

      MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI0
      5ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29yZTEnMCUG
      A1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzNDIxOVoXDTk5MD
      UxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQwwCgYDVQQDEwNLUmEw
      XDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m83kX6bdhytRYNkdHB9

    To copy the transport certificate information from a Data Recovery Manager's certificate database:

    1. Open a terminal window in the system that hosts the Data Recovery Manager.

    2. Use the command-line tool called certutil to retrieve the transport certificate from the Data Recovery Manager's certificate database. (For information on the certutil tool, see Chapter 11 , "Certificate Database Tool" of CMS Command-Line Tools Guide.)

      First, go to this directory: <server_root>/cert-<instance_id>/config

      Next, run this command: <server_root>/bin/cert/tools/certutil -L
      -d . -n kraTransportCert cert-<instance_id> -a

      The transport certificate appears. View the certificate information. Make sure that the certificate you are looking at is the correct one; the certificate shows the DN that was specified for the transport certificate during the installation of Data Recovery Manager.

    3. Copy the base-64 encoded certificate, excluding the marker lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, to a text file. The copied information should look like the example below:

      MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI0
      5ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29yZTEnMCUG
      A1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzNDIxOVoXDTk5MD
      UxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQwwCgYDVQQDEwNLUmEw
      XDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m83kX6bdhytRYNkdHB95B

  2. Update the JavaScript method in the enrollment form.

    To do this:

    1. Go to the host system of the enrollment authority and locate the user-enrollment form. The default forms are at this location: <server_root>/cert-<instance_id>/web/ee

    2. Open the enrollment form that you want to use in a text editor.

    3. In the form, locate the generateCRMFRequest() JavaScript method (see Figure 22-3).

    4. Add a variable for the transport certificate.

      Below the commented text, add this line:

      var kraTransportCert =

    5. Open the text file that has the Data Recovery Manager's transport certificate (the one you copied earlier) and copy the certificate.

    6. Paste the certificate as the value of the kraTransportCert variable.

      Paste the certificate in front of the = sign, remove any line breaks, enclose the certificate within double-quotation marks (""), and end the string with a semicolon (;). When deleting line breaks, be sure not to delete any of the characters in the encoded blob.

      An example is shown below:

      var kraTransportCert = "MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
      qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQ
      LEwhIYXJkY29yZTEnMCUGA1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIEl
      JMB4XDTk4MTExOTIzNDIxOVoXDTk5MDUxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETA
      PBgNVBAoTCG5ldHNjYXBlMQwwCgYDVQQDEwNLUmEwXDANBgkqhkiG9w0BAQEFAANLADB
      IAkEArrbDiYUI5SCdlCKKa0bEBn1m83kX6bdhytRYNkdHB95Bp85SR";

    7. Pass the kraTransportCert variable to the JavaScript method.

      Replace null (the fourth line in the method) with kraTransportCert.

    8. Specify the key algorithm and key type (see "generateCRMFRequest()" in Javascript API for Client Certificate Management).

      Below is an example that shows how the updated generateCRMFRequest() method would look:

      // generate keys for PSM.
      if (navigator.appName == "Netscape" && (navMajorVersion() > 3) &&
               typeof(crypto.version) != "undefined") {
               certNickname.value = subject.value;
               crmfObject = crypto.generateCRMFRequest(subject.value,
                           "regToken",
                           "authenticator",
                           kraTransportCert,
                           "setCRMFRequest();",
                           512, null, "rsa-ex",
                           1024, null, "rsa-sign");
      }

      The method triggers the client to generate two RSA key pairs—one key of length 512 for encrypting data and another key of length 1024 for signing data.

    9. Save your changes.


Step D. Configure Key Archival Policies

This step is optional.

Unlike Certificate Manager and Registration Manager, no policy plug-in modules are provided for the Data Recovery Manager. If you have implemented any custom policy modules for the Data Recovery Manager's key archival process, you should make sure that they are configured properly. For details on configuring policies for a subsystem, see "Configuring Policy Rules for a Subsystem".


Step 2. Set Up the Key Recovery Process

Before proceeding with this section, you should have read "Key Recovery Process". In particular, you should be familiar with how the key archival process works. If you are not, see "How Agent-Initiated Key Recovery Works".

The Data Recovery Manager supports agent-initiated key recovery process, in which end users' encryption private keys are recovered by designated key recovery agents. This section explains how to set up the key recovery process.

To set up agent-initiated key recovery process, follow these steps:


Step A. Verify the m of n Scheme

During the installation of the Data Recovery Manager, you were asked to specify the total number of key recovery agents (a minimum of one) and the number of agents (of this total) required to authorize a key recovery operation. This combination is called m of n scheme. For more information about this, see "Key Recovery Agent Scheme".

Verify that the current m of n scheme is appropriate for your PKI setup. If it isn't, change the scheme following the instructions in "Changing the Key Recovery Agent Scheme".


Step B. Facilitate the Key Recovery Agents to Change the Passwords

During the installation of Data Recovery Manager, after you specified the m of n scheme, you were also prompted to provide unique passwords for each recovery agent. It is quite likely that you specified these passwords yourself instead of it being done by those individuals who have been designated with the key recovery agents' role in your organization. Therefore, you must get the designated recovery agents to change the passwords entered during installation.


Step C. Determine the Authorization Mode for Key Recovery

The Data Recovery Manager allows key recovery agents to authorize recovery of an end user's encryption private key locally or remotely. The default configuration is local authorization. It is important that you evaluate both the authorization modes, and choose the one that is appropriate for your organization. For more information about this, see "Local Versus Remote Key Recovery Authorization".

If want the key recovery agents to authorize key recovery remotely, be sure to set them up as Data Recovery Manager agents following the instructions in "Setting Up Agents".


Step D. Customize the Key Recovery Form

Key recovery agents need an appropriate interface to initiate the key recovery process. By default, the Data Recovery Manager's Agent Services interface includes an HTML form (recoverKey.html) that allows key recovery agents to initiate the key recovery process and retrieve users' encryption keys. For details about this form, check CMS Customization Guide.

If you want to customize this form to suit your organization, be careful not to delete any of the information that is vital to the functioning of the form; it is recommended that you restrict your changes to the content presented in the form.


Step E. Configure Key Recovery Policies

This step is optional.

Unlike Certificate Manager and Registration Manager, no policy plug-in modules are provided for the Data Recovery Manager. If you have implemented any custom policies for the Data Recovery Manager's key recovery process, you should make sure that they are configured properly. For details on configuring policies for a subsystem, see "Configuring Policy Rules for a Subsystem".


Step 3. Test Your Key Archival and Recovery Setup

The steps outlined in this section explain how to verify key archival and recovery process using Netscape Communicator 4.7 with Personal Security Manager, version 1.01.


Step A. Test Your Key Archival Setup

To test whether you can successfully archive a key, follow these instructions.

  1. Enroll for dual certificates.

    To do this:

    1. Open a web browser window.

    2. Go to the end-entity interface for the enrollment authority.

      The default URL is as follows: https://<hostname>:<end_entity_HTTPS_port> or http://<hostname>:<end_entity_HTTP_port>

    3. In the end-entity interface, open the enrollment form you customized in "Step C. Customize the Certificate Enrollment Form".

      (Perform a "View Source" to ensure that the browser loads the correct page with the JavaScript method you edited.)

    4. Fill in all the values and submit the request.

      The client prompts you to enter the password for your key database.

    5. When you enter the correct password, the client generates the key pairs.

      Do not interrupt the key-generation process.

  2. Approve the request.

    This step is required only if you used the manual enrollment form for requesting the certificate.

    1. Go to the enrollment authority's Agent Services interface.

      The default URL is as follows: https://<hostname>:<agent_port>

    2. Click the link that says List Requests.

    3. In the form that appears, select the "Show pending requests" option and click Find.

      You should see your request in the list of pending requests.

    4. Make sure the request has the appropriate extensions set for S/MIME (E-mail bit of the Netscape Certificate Type extension selected) and the subject name contains the email information (the value of the E attribute).

    5. Locate and approve the request.

  3. Check if the certificates have been issued.

    To do this:

    1. Click the List Requests link again.

    2. In the form that appears, select the "Show completed requests" option and click Find.

      You should see two new certificates with consecutive serial numbers.

    3. Download the certificates to the web browser.

    4. Go to the security information window of the browser (from the Communicator menu, choose Tools, and then choose Security Info).

    5. Click Certificates and then click Mine.

    6. Verify that the test certificates have been stored in the browser's certificate database.

      You will see only one entry for both the certificates you downloaded. If you select the entry and click View, you should see two certificates—one certificate for encipherment and another one for digital signature.

  4. Check whether the key has been archived. To do this:

    1. Go to the Data Recovery Manager's Agent Services interface.

    2. Click the link that says List Requests.

    3. In the form that appears, check the "Show completed requests" option and click Find.

    4. If the key has been archived successfully, you should see the information pertaining to that key. If you don't see the key archived, check the logs and correct the problem before proceeding to the next step.

    5. If the key has been successfully archived, exit the client completely—that is, from the File menu, select Exit; this will close all client windows.


Step B. Verify the Key

To do this:

  1. Open a browser window again.

  2. Open the email client, Messenger, and send a signed and encrypted email to yourself.

  3. When you receive the email, open it, and check the message to see if it is signed and encrypted.

    There should be a security icon at the top-right corner of the message window and it should indicate that the message is signed and encrypted.


Step C. Delete the Certificate

To do this:

  1. Open the security information window.

  2. Click Certificates and then click Mine.

  3. In the list of certificates, select the test certificate you downloaded previously and click Delete.

  4. When prompted confirm the delete action.

  5. Check your email again. This time, you should not be able to verify the email message because you have deleted the certificates from the client's certificate database.


Step D. Test Your Key Recovery Setup

To test whether you can successfully recover an archived key:

  1. Go to the Data Recovery Manager's Agent Services interface.

  2. Click the Recover Keys link.

  3. In the form that appears, enter any of the following information for the encryption private key that has been archived:

    • The key owner's name

    • The serial number of the key

    • The public key that corresponds to the private key (in the form of base-64 encoded certificate)

    • The instance ID of the enrollment authority that initiated the key archival process

    If you need more information about any of the fields in this form, click the Help button.

  4. Click Show Key.

    If the key has been archived successfully, you should see the information pertaining to that key.

  5. Click Recover.

  6. In the form that appears, enter the following information:

    • The PKCS #12 password; the Data Recovery Manager uses this password to encrypt the PKCS #12 package (see "How Agent-Initiated Key Recovery Works").

    • The base-64 encoded certificate that corresponds to the private key you want to recover; use the enrollment authority's end-entity or agent interface to get this information. If you searched for the archived key by providing the base-64 encoded certificate in (step 4), then you don't have to provide this information.

    • The key recovery agents' passwords.

  7. Click Recover.

    If you entered the correct information, the Data Recovery Manager returns the private key packaged as a PKCS #12 blob (it contains the recovered key pair and the corresponding certificate) and prompts you to save it. Specify the path and filename for saving the encrypted file. Be sure not to change the default file extension (.p12).


Step D. Restore the Key in the Browser's Database

To do this:

  1. Go to the security information window of your browser.

  2. Import the *.p12 file (that you saved in the previous step) back into the browser.

  3. Open the test email that you couldn't verify after deleting the certificate from the browser's certificate database; you should be able to verify it again.


Previous     Contents     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated April 02, 2001