|
Administrator's Guide Netscape Certificate Management System |
|
||
|
|
Appendix B Common Criteria Environment: Setup and Operations
This chapter provides information about the configuration used to set up Netscape Certificate Management System (CMS) in the Common Criteria Environment. For an overview of PKI, see Appendix J "Introduction to Public-Key Cryptography." This chapter contains the following sections:
- PKI Overview
- Security Objectives
- TOE Security Environment Assumptions
- Security Requirements for the IT Environment
- IT Environment Assumptions
- CMS Privileged Users and Groups (Roles)
- CMS Common Criteria Environment Setup and Installation Guide
For an overview of PKI, see Appendix J "Introduction to Public-Key Cryptography."
For information about the Security Objectives, see Appendix D "Common Criteria Environment: Security Objectives".
TOE Security Environment Assumptions
For information about the TOE Security Environment, see Appendix E "Common Criteria Environment: TOE Security Environment Assumptions".
Security Requirements for the IT Environment
The security requirements for the IT environment are detailed in Appendix A "Common Criteria Environment: Security Requirements."
The assumptions about the TOE's environment are that you have the ability to:
- Recover to a viable state after malicious code is introduced and damage occurs.
- Provide time stamps to ensure the sequencing of events can be verified.
- Implement automated notification or other responses to the TSF-discovered attacks in order to identify attacks and create an attack deterrent.
- Require inspection for downloads.
- Respond to possible loss of stored audit records.
CMS relies on the operating system to provide reliable timestamps. To ensure that the certificates signed by the CA contain accurate timestamps and the audit log events record accurate time of event occurrence, CMS administrators need to make sure the operating system has a time-syncing mechanism with a reliable source.
Private and Secret Key Zeroization
There are no explicit calls from CMS code to do private and secret key zeroization. NSS automatically handles zeroization for CMS by invoking the zeroization routines provided by the cryptographic hardware, so there isn't anything the administrator needs to do specifically to activate this feature.
Password and Certificate Storage
Plan for the storage of any passwords and certificates. Also plan your user password policy. Make sure everyone knows and adheres to these policies.
This environment requires a FIPS 140-1 level 3 certified hardware cryptographic module.
You need to install the software and hardware for this hardware token before installing and configuring the subsystems. You will also setup the hardware token for use with CMS after installing CMS, but before installing a subsystem. Use the hardware token to create subsystem certificates during installation of each subsystem.
Protection of Private and Secret Keys
CMS certificate private keys and secret keys are to be generated and stored in a FIPS 140-1 level 3 certified hardware cryptographic token.
The CMS private (asymmetric) keys are:
- Private key associated with the CA signing certificate.
- Private key associated with the RA-to-CA SSL client certificate.
- Private key associated with the OCSP Responder signing certificate.
- Private key associated with the CA-to-DRM SSL client certificate.
- Private key associated with the DRM transport certificate.
- Private key associated with the CA, RA, DRM, and OCSP SSL server certificates.
- Private key associated with the audit log signing certificate.
- Private key associated with the DRM storage certificate used for encrypting user subject encryption private keys (for DRM key archival).
The CMS secret (symmetric) key is:
- Symmetric key used to encrypt passwords for password cache (single-sign-on). See "Password Cache".
Note: CMS does not store user secret keys, and it does not support the export of component (subsystem) private or secret keys.
CMS runs on the Solaris 2.8 and RedHat Advanced Server 2.1 operating systems.
The browsers that are supported in the Common Criteria Environment are Netscape 4.79, Netscape 6.2, and Netscape 7.x.
CMS Privileged Users and Groups (Roles)
Each CMS subsystem has four roles set up by default. The roles that are created are specific to the CMS subsystem, and depend on which CMS subsystem has been installed. All of the privileged roles (see About Roles for more information about privileges) require SSL client-authentication by presenting a certificate that maps to the user with the corresponding role (i.e., authorization). The following sections show the default roles that are created with each subsystem and the main privileges of each.
- Administrators
- Can start/stop the server (from the command-line).
- Can perform all configuration management for CA (unless assigned otherwise), including the configuration of certificate profiles (specifying the set of acceptable values for fields and extensions) for certificate enrollment requests (via the CMS Console).
- Can backup (CMSBackup) and restore (CMSRestore) the subsystem from the command-line.
- Certificate Manager Agents
- Can approve fields/extensions (to be included in a certificate) of certificate profiles that have been enabled and configured by the Administrator (via SSL-capable browsers to the CA Agent interface).
- Can run tools (CMCEnroll and CMCRevoke) to pre-approve certificate enrollment and revocation requests.
- Auditors
- Can view signed audit logs (from the IT environment). This is the only role allowed this privilege.
- Can verify audit log signatures by running the AuditVerify tool (from the IT environment).
- Trusted Manager
- The Trusted Manager role is a special role that is not for privileged users. It is created for inter-CIMC_boundary communication. The trust of this communication is established using the role authentication/authorization mechanism. Conceptually, this role is not an actual privileged role that a user can be assigned to. Rather, the Trusted Manager role is a means of establishing trust between two CMS subsystems. To have the RA communicate with the CA securely, the CA administrator needs to create an "RA user" on the CA with the Trusted Manager role when setting up the RA. All communications between the RA and CA are then made through this special user with the RA's certificate over SSL client-authentication and the Trusted Manager role authorization (via Inter-CIMC_boundary interface connectors).
- Administrators
- Can start/stop server (from the command-line).
- Can perform all configuration management for the RA (unless assigned otherwise), including the configuration of certificate profiles (specifying the set of acceptable values for fields and extensions) for certificate enrollment requests (via CMS Console).
- Can backup (CMSBackup) and restore (CMSRestore) the subsystem from the command-line.
- Registration Manager Agents
- Can approve fields/extensions (to be included in a certificate) of certificate profiles that have been enabled and configured by the Administrator (via SSL-capable browsers to the RA Agent interface).
- Auditors
- Administrators
- Can start/stop server (from the command-line).
- Can perform all configuration management for the DRM (via the CMS Console).
- Can backup (CMSBackup) and restore (CMSRestore) the subsystem from the command-line
- Data Recovery Manager Agents
- Can approve recovery of subject private keys (via SSL-capable browsers to the DRM Agent interface).
- Can export recovered subject private keys (via SSL-capable browsers to the DRM Agent interface).
- Auditors
- Can view signed audit logs (from the IT environment). This is only role allowed this privilege.
- Can verify audit log signatures by running the AuditVerify tool (from the IT environment).
- Trusted Manager
- The Trusted Manager role is a special role that is not for privileged users. It is created for inter-CIMC_boundary communication. The trust of this communication is established using the role authentication/authorization mechanism. Conceptually, this role is not an actual privileged role that a user can be assigned to. Rather, the Trusted Manager role is a means of establishing trust between two CMS subsystems. To have the CA communicate with the DRM securely, the DRM administrator creates a CA user in the DRM with the Trusted Manager role. All communications between the CA and DRM are then made through this special user with the CA's certificate over SSL client-authentication and Trusted Manager role authorization.
- Administrators
- Can start/stop server (from the command-line).
- Can perform all configuration management for DRM (via the CMS Console).
- Can backup (CMSBackup) and restore (CMSRestore) the subsystem from the command-line.
- Online Certificate Status Manager Agents
- Can add CRLs (to the OCSP Responder Agent interface via SSL-capable browsers).
- Can define supported CAs (via SSL-capable browsers to the OCSP Responder Agent interface).
- Auditors
Of all privileged roles supported by CMS, the Certificate Manager Agents role, the Registration Manager Agents role, and the DRM Agent Role are the ones that map directly to the "Officer" role defined in the ST and the CIMC PP. The Online Certificate Status Manager Agents are a sub-group of the Administrator role defined in the CIMC PP. The following further specifies this mapping:
- Administrator
- The Administrator role is divided into finer-grained sub-roles, each bearing different responsibilities:
- Officer
- Auditor
CMS Common Criteria Environment Setup and Installation Guide
Understanding Setup of Common Criteria Evaluated Netscape CMS
Appendix C "Understanding the Common Criteria Evaluated CMS Setup," provides a high level description of the steps for setup, installation, and configuration of Netscape 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.
CMS Common Criteria Environment Setup and Installation Process
Step-by-step instructions to install, configure, and run Netscape CMS in a Common Criteria Evaluated Mode are described in the document CMS Common Criteria Setup Procedure.
© 2001 Sun Microsystems, Inc. Portions copyright 1999, 2002-2004 Netscape Communications Corporation. All rights reserved.
Last Updated November 23, 2004