Chapter 28 Recovering Encrypted Data

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.

• PKI Setup for Key Archival and Recovery
• Key Archival Process
• Key Recovery Process
• Setting Up Key Archival and Recovery Process

• 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

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.

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.

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".

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.

• 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.

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.

• 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.

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

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).

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 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".

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 Netscape Certificate Management System Agent's Guide. To locate online versions (HTML and PDF) of this guide, check this file:

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.

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.

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).

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.

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.

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.

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.

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.

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.

• Step 1. Set Up the Key Archival Process
• Step 2. Set Up the Key Recovery Process
• Step 3. Test Your Key Archival and Recovery Setup

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".

• Step A. Deploy Clients That Can Generate Dual Key Pairs
• Step B. Connect the Enrollment Authority and the Data Recovery Manager
• Step C. Customize the Certificate Enrollment Form
• Step D. Configure Key Archival Policies

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.7 or later enables it to support the CMC protocol and generate dual key pairs.

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 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.

• 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 key type, length, and algorithm, see generateCRMFRequest() in Javascript API for Client Certificate Management. The document is at this location:

<server_root>/psm101/CMCJavascriptapi.html

You can also get the latest version of this document form this site:

http://docs.iplanet.com/docs/manuals/psm.html

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:

MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBA
oTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29y
ZTEnMCUGA1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzND
IxOVoXDTk5MDUxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQww
CgYDVQQDEwNLUmEwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m83
kX6bdhytRYNkdHB95Bp85SRadmdJV+0OyMxjYAtGCFrmcqEZ4sh2YSov6wIDAQABozYwNDARBg
lghkgBhvhCAQEEBAMCAEAwHwYDVR0jBBgwFoAUl7FtsrYCFlQMl9fjMm3LnNu3oAwDQYJKoZIh
vcNAQEEBQADgYEApvzcUsVIOstaoYSiWb4+aMVH6s1jiJlr5iVHnOKzfsYxPVdUw6uz04AT8N+
1KIarMTKxHPzGAFSLicKLEv4HG4vh6llc86uzRzWpUqqVHgeKN5A8Jyg56D4DkNrXEJ7QdKesA
p13dk5H5qvHelkSPLYYdMXNwNWP

• 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 Appendix D, "Certificate Database Tool".)

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:

MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBo
TI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29yZ
TEnMCUGA1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzNDI
xOVoXDTk5MDUxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQwwC
gYDVQQDEwNLUmEwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m83k
X6bdhytRYNkdHB95Bp85SRadmdJV+0OyMxjYAtGCFrmcqEZ4sh2YSov6wIDAQABozYwNDARBgl
ghkgBhvhCAQEEBAMCAEAwHwYDVR0jBBgwFoAUl7FtsrYCFlQMl9fjMm3LnNu3oAwDQYJKoZIhv
cNAQEEBQADgYEApvzcUsVIOstaoYSiWb4+aMVH6s1jiJlr5iVHnOKzfsYxPVdUw6uz04AT8N+1
KIarMTKxHPzGAFSLicKLEv4HG4vh6llc86uzRzWpUqqVHgeKN5A8Jyg56D4DkNrXEJ7QdKesAp
13dk5H5qvHelkSPLYYdMXNwNWP

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 28.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 =
"MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVB
AoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29
yZTEnMCUGA1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzN
DIxOVoXDTk5MDUxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQw
wCgYDVQQDEwNLUmEwXDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m8
3kX6bdhytRYNkdHB95Bp85SRadmdJV+0OyMxjYAtGCFrmcqEZ4sh2YSov6wIDAQABozYwNDARB
glghkgBhvhCAQEEBAMCAEAwHwYDVR0jBBgwFoAUl7FtsrYCFlQMl9fjMm3LnNu3oAwDQYJKoZI
hvcNAQEEBQADgYEApvzcUsVIOstaoYSiWb4+aMVH6s1jiJlr5iVHnOKzfsYxPVdUw6uz04AT8N
+1KIarMTKxHPzGAFSLicKLEv4HG4vh6llc86uzRzWpUqqVHgeKN5A8Jyg56D4DkNrXEJ7QdKes
Ap13dk5H5qvHelkSPLYYdMXNwNWP";
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.

For information on specifying key type, length, and algorithm, 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 nsm.

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.

This step is optional.

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".

• Step A. Verify the m of n Scheme
• Step B. Facilitate the Key Recovery Agents to Change the Passwords
• Step C. Determine the Authorization Mode for Key Recovery
• Step D. Customize the Key Recovery Form
• Step E. Configure Key Recovery Policies

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".

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.

• To understand the significance of key recovery agents' passwords, see "Key Recovery Agents and Their Passwords".
• To get the recovery agents to change the passwords, follow the instructions in "Changing Key Recovery Agents' Passwords".

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".

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, see "Agent Forms and Templates".

This step is optional.

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.

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

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://<host_name>:<end_entity_HTTPS_port> or

http://<host_name>:<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.

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://<host_name>:<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.

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.

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.

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.

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.

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).

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.