Netscape Certificate Management System Administrator's Guide: Appendix C Understanding the Common Criteria Evaluated CMS Setup

Administrator's Guide
Netscape Certificate Management System

Appendix C Understanding the Common Criteria Evaluated CMS Setup

This document describes at a high level the steps for setup, installation, and configuration of the Netscape Certificate Management System (CMS) in an IT environment of the kind described in "IT Environment Assumptions". It gives administrators an idea of what's ahead before starting them on the exact setup steps involved in installation and setup. Step-by-step instructions for installing and setting up CMS in the Common Criteria environment are contained in the document CMS Common Criteria Setup Procedure.

Understanding the Common Criteria Environment

This section describes the environment before CMS is installed and configured.

Secure Environment

This section describes the secure environment you will be instructed to setup before installing and configuring CMS.

Network Environment

It is important to make sure that only those users that are part of the CMS installation have access to the system that is about to be installed; unauthorized personnel should not have access. It is recommended that you carry out the installation/configuration procedures in an isolated, secure network and re-establish the full network access only when the configuration is complete.

Operating System Environment

Because CMS relies on the IT environment to provide the basic operating system file system security, inter-process communication, and process space protection, it is highly recommended that you install and run CMS on an operation system certified at a Common Criteria assurance level no less than the level of CMS itself.

CMS Roles Assignment

In order to maintain accountability, it is prudent to require individual users to log into their individual accounts for regular CMS operations and maintenance. To achieve this, you first have to assign CMS privilege roles to users. It is also recommended that the user ID at the operating system level is the same user ID that is used in CMS. CMS allows more than one user to have the same role (for example, you can have two CA agents); however, CMS does not allow one person to have more than one role within the same subsystem (for example, the user Joe cannot be both the CA Administrator and Agent for the same CA subsystem). See "CMS Privileged Users and Groups (Roles)", for a description of the various CMS privileged roles.

Who Needs to be Present

During the installation and configuration, the CMS audit function is not operational, so it is crucial that all CMS roles be present to witness the installation and make necessary operations and decisions.

Understanding Operating System Setup (Users, Groups, and File Permissions)

There is a requirement to allow only the CMS auditor to view the signed audit logs from the IT environment, and a requirement to prohibit any one person from editing any CMS configuration undetected or unaccounted for. The procedure for setting up such an environment on a Solaris 8.x system involves utilization of operating system users, groups, and file system manipulation. The detailed procedure can be found in the CMS Common Criteria Environment Setup and Installation Process (see CMS Common Criteria Setup Procedure). If you are installing on a trusted operating system on which you can assign privileges, you need to follow the operating system instructions on setting them to achieve the proper levels of access.

When you begin installation, you will be instructed to create a special user ID, which you will then use to log in to the Operating System when you install CMS. This user ID will be the effective user ID of the CMS server itself during runtime. You will then need to create groups for the auditor and administrator roles, which you must then assign to the actual user IDs for the CMS administrators and CMS auditor users on the operating system.

After CMS files are installed, you will be instructed to change the ownership of the CMS files to the special user ID that you've created by running a shell script provided with this product. Finally, you will be instructed to disable this special user ID account, preventing users from logging in with this user ID.

Understanding CMS Installation

You must install CMS on each host on which a CMS subsystem is installed. You can set up the environment with all subsystems installed on the same host, or with some or all subsystems on separate hosts, but every host must have CMS.

Configuring CMS to Use Hardware Tokens

You will be instructed to configure each CMS installation to use a FIPS 140-1 Level 3 certified hardware token after installing CMS on the host, but before installing and configuring any subsystems on that host. Hardware tokens are required for all subsystems (CA, RA, DRM, and OCSP Responder); DRM needs at least two: one for user private key transport key, and one for user private key storage key.

Revocation Checking

In order to check the status of CMS user certificates, you will be instructed to set up revocation checking for each CMS instance by setting up the revocation feature in the NES instance used by that CMS instance.

SSL Client Authentication with the Internal Database

In the Common Criteria Environment, the internal LDAP database used by the subsystem must be set up for SSL client authentication. You will be instructed on how to set this up when you follow instructions in the document CMS Common Criteria Setup Procedure.

CMS Administrative Console

In the Common Criteria Environment, you will not be able to start a CMS instance using Netscape Console and the CMS console. You must start the server on the command line because when you set up the Common Criteria environment, you disable the password plain-text file used for remote start-up. When you log in on the command line, you will be prompted for all the passwords you need to provide.

For complete information on the CMS console, see "The Administrative Interface". For instructions on how to set up SSL client authorization for the CMS console, see Appendix I, "Introduction to SSL."

Backup and Restore of a CMS Subsystem

CMS provides a command-line tool to backup a CMS subsystem instance. It also provides another command-line tool to restore a CMS subsystem instance to the state of the system when it was last backed up. In the CMS Common Criteria Setup Procedure, you will not be instructed on how to operate these command-line utilities, however, you should know when it's necessary to backup or restore a CMS subsystem running in Common Criteria evaluated environment, you should following the instructions for these utilities in the Backing Up and Restoring Data chapter of the CMS Tools Guide and the instructions on how to sign and verify the data.

Note: All secure information that needs encryption (component secret keys, component private keys, and passwords) is cryptographically encrypted with FIPS 140-1 Level 3 certified hardware token. Disclosure is therefore not a concern of the backup utilities.

Common Criteria Deployment Scenarios

As long as the subsystems you install are installed and configured following the Common Criteria Environment rules and guidelines contained in this chapter, you can deploy CMS in any deployment scenario you wish. You can set up a root CA, for example, a CA subordinate to a CMS CA, a CA subordinate to a public third-party CA, or have any number of CAs in vertical or horizontal chains as long as they follow the constraints contained in the CA signing certificate. If you are setting up the FBCA (cross-certification) feature, you need to cooperate with the administrator of the remote CA to set up the trust between the two certificates.

You can configure one or more RAs to any CA you set up. You can also install a Data Recovery Manager to any CA that you install. Though connecting a Data Recovery Manager to a Registration Manager is one possible CMS deployment scenario, it is not currently part of the Common Criteria Evaluation. You can install and configure an OCSP responder to any CA you install and configure, or you can have one OCSP responder work with multiple CAs.

Features That Are Not Part of the Common Criteria Environment

The Common Criteria Environment tests all of the features and ways of configuring CMS except for the following, which are not part of the Common Criteria Environment:

Using anything other than hardware tokens to create and store CIMC keys and certificates.

Using the remote startup plain-text password cache, password.conf.

Using the administrative interface, CMS console, in non-SSL client authentication mode.

Cloning a Certificate Manager.

Connecting a Data Recovery Manager to a Registration Manager.

Running the internal database, or any publishing LDAP database in non-SSL client authentication mode.

Using the non-profile Policy feature for enrollment.

Using the certificate-based authentication, face-to-face authentication (in-person authentication) available in a Registration Manager,

Adding a custom plug-in, which in essence breaks the Common Criteria assurance. If adding custom plug-ins is inevitable, it is the responsibility of all role users to carefully evaluate these plug-ins before making them part of the system.

The default ACLs contain access control enforcement requirements specified in the CIMC Security Level 3 protection profile. Caution must be taken when making changes to them.

Using the internal OCSP services of a Certificate Manager.

CEP enrollments.

Challenge Revocation.

You will be instructed on how to disable these features in order to conform to the Common Criteria Environment.

Understanding Subsystem Setup

This section describes at a high-level what to expect when you configure a subsystem following the instructions in the document CMS Common Criteria Setup Procedure. This section contains links to the main guidance documents where detailed information is provided for each feature, but you will need to follow the CMS Common Criteria Setup Procedure in order to set up a Netscape CMS Common Criteria evaluated environment.

CMS Role Users and Authorization

In CMS, you create role users and then assign them to groups (also roles) to give them the privileges of the role represented by the group membership. You need to set up at least one auditor role user, one agent role user, and one administrator role user for each subsystem. You specify the first administrator role user when you install the subsystem. You will be setting up the administrative interface (CMS console) for SSL authentication; all agent role users, auditor role users, and administrator role users you set up will need to obtain a certificate, and the certificates for those role users will need to be stored with their role user entries. It is recommended that you have the auditor role users, administrator role users, and agent role users use their hardware tokens to submit requests to the end-entity interface of the Certificate Manager or Registration Manager that will process the request.

You can also configure new groups and assign them privileges other than the default privileges assigned to the default groups, thus creating new roles in the subsystem. You do this by creating a group, setting up ACIs for this group in the ACLs pertinent to the privileges you want to define for this group.

For complete information on creating users, assigning them to groups, creating groups, and changing the ACLs, see Chapter 9 "Authorization."

Note that while you have the flexibility to add groups and change the ACLs under the Common Criteria Environment, you have to be extra cautious about creating scenarios that are not secure, for example allowing anyone access to the agent services interface. You also need to be careful when making changes to the default roles, or when adding roles that you do not create security holes or vulnerabilities.

Any custom plug-ins for the Access Control feature are not part of the Common Criteria Environment. Also recall that any custom plug-ins for the Access Control feature are not part of the Common Criteria Environment.

Audit Logs

The Common Criteria Environment requires that the signed audit log file feature be enabled and configured. "Signed Audit Log" provides complete information about how to set up the signed audit feature.

Certificate Profiles

In the Common Criteria Environment, you must set up the certificate profiles feature for certificate enrollment in a CA or RA subsystem. You can set up and enable any or all of the prebuilt certificate profiles. You can also create other certificate profiles in the CMS Administrative console using the defaults, constraints, inputs, and outputs that are defined. Custom plug-ins for any of the components of the certificate profile feature are not supported as part of the Common Criteria Environment. It is important to note that only the CMS (CA, RA) administrators are allowed to configure the certificate enrollment profiles (setting ranges for fields, enabling extensions, etc.), and it is the CMS (CA, RA) agents' responsibility to approve the fields and extensions in the certificate profiles enabled by the Administrators. You will be instructed on how to perform these operations.

See the Chapter 11 "Certificate Profiles" for complete information about certificate profiles.

Certificate Policies

The non-profiles policy feature is not part of the Common Criteria Environment. All enrollments are set up using the certificate profiles feature.

Authentication

In the Common Criteria Environment, you can enable and configure the agent-approved authentication method or any of the authentication plug-ins in conjunction with a certificate profile. You cannot set up certificate-based enrollment or in-person enrollment. See Chapter 10 "Authentication" for complete information about authentication. See the Chapter 11 "Certificate Profiles" for information about using authentication with certificate profiles.

CRLs

In a CA subsystem, you can set up the CRL feature and any of the three issuing points for CRLs under the Common Criteria Environment. When setting up the CRL feature, you cannot set up a CRL that does not have an update frequency specified in the "Update at this frequency" field. Compliant CRLs must contain the nextUpdateTime extension, which will not be filled in correctly if an update frequency is not specified. Note that you can specify an update frequency and also specify that the CRL is updated every time a certificate is revoked; both settings will be respected. For complete information on CRLs, see Chapter 15 "Revocation and CRLs."

Jobs

Jobs are events that can be scheduled to be activated periodically. You can set up any of the available job plug-ins in the Common Criteria Environment. Any custom plug-ins for any of the Jobs feature are not part of the Common Criteria Environment, however. Although you will not specifically be instructed to configure Jobs, you can turn on and configure any jobs that are provided by default. If you want notifications to be sent, be cautious on the email addresses you provide and make sure they belong to appropriate roles. For complete information on jobs, see Chapter 14 "Automated Jobs."

Notifications

Automated email notifications are event-driven tasks that send out an email via SMTP when a specified event occurs. You can set up any of the available Notification plug-ins in the Common Criteria Environment. Custom plug-ins for the Notification feature are not part of the Common Criteria Environment, however. Although you will not specifically be instructed to configure notifications, you can turn on and configure any Notification task that is provided by default. Be cautious on the email addresses you provide and make sure they belong to appropriate roles. For complete information on Notifications, see Chapter 13 "Automated Notifications."

Publishing

You can set up any of the methods of publishing in any of the configurations available in CMS in the Common Criteria Environment. If you set up LDAP publishing, it is highly recommended that you set it up using SSL client authentication and that you set up the Directory Server in SSL mode as well. For information about publishing, see Chapter 16 "Publishing."

Self Tests

CMS provides a self-diagnostic feature that checks the sanity of a few key items during a CMS subsystem startup. Any failed self test is an indication of a fatal error to the subsystem. Technically, CMS allows users to add their own self tests as plug-ins; however, only the self-tests provided by default are Common Criteria evaluated. You will not be instructed to configure self tests during the CMS Common Criteria Setup Procedure, but this is because the self tests are turned on and operational by default. For more information, see "Self Tests".

Trust Between Subsystems

You will be instructed to set up trust between CMS subsystems in the following two scenarios:

Between a Registration Manager and the Certificate Manager that issues certificates for this Registration Manager

Between a Certificate Manager and the Data Recovery Manager that handles key archival and recovery for this Certificate Manager

The first scenario involves setting up a user in the Certificate Manager for the Registration Manager. This user is assigned to the trusted managers group, and its certificate is stored in the database for the Certificate Manager. You can then set up the Registration Manager to communicate with the Certificate Manager.

The second scenario involves setting up a user in the Data Recovery Manager for the Certificate Manager. This user is assigned to the trusted managers group, and its certificate is stored in the database for the Data Recovery Manager. You can then set up the Certificate Manager to communicate with the Data Recovery Manager.

Key Archival and Recovery

The DRM subsystem provides features to archive user private keys for encryption-only certificates. It also provides features to recover the user private keys that it has archived. Key recovery requires Data Recovery Manager Agents to work in cooperation. You will be instructed to configure the key recovery and key archival settings for the Data Recovery Manager and establish trust with the Certificate Manager. For complete information on key archival and recovery, see Chapter 6 "Data Recovery Manager."

OCSP Responder Revocation Information Store

The OCSP Responder revocation store contains information about where the CRLs can be retrieved for serving OCSP requests. You will be instructed to configure the Online Certificate Status Manager revocation store. If you setup the Online Certificate Status Manager to use the ldapstore option, the LDAP store you use must be configured for SSL authentication. For complete information about the OCSP responder, see Chapter 5 "OCSP Responder."

Common Criteria Environment Setup Procedures

Step-by-step instructions for installing and setting up CMS in the Common Criteria environment are contained in the document CMS Common Criteria Setup Procedure.

Last Updated November 23, 2004