| Administrator's Guide Red Hat Certificate System |
| Previous |
Contents |
Index |
Next |
Appendix B
Common Criteria Environment: Setup and Operations
This chapter provides information about the configuration used to set up Red Hat Certificate System (CS) 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
- CS Privileged Users and Groups (Roles)
- CS Common Criteria Environment Setup and Installation Guide
PKI Overview
For an overview of PKI, see Appendix J, "Introduction to Public-Key Cryptography."
Security Objectives
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."
IT Environment Assumptions
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.
Reliable Timestamp
CS 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, CS 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 CS code to do private and secret key zeroization. NSS automatically handles zeroization for CS 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.
Hardware Token
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 CS after installing CS, but before installing a subsystem. Use the hardware token to create subsystem certificates during installation of each subsystem.
Protection of Private and Secret Keys
CS certificate private keys and secret keys are to be generated and stored in a FIPS 140-1 level 3 certified hardware cryptographic token.
The CS 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 CS secret (symmetric) key is:
- Symmetric key used to encrypt passwords for password cache (single-sign-on). See "Password Cache," on page 245.
Note: CS does not store user secret keys, and it does not support the export of component (subsystem) private or secret keys.
Supported Operating Systems
CS runs on the Solaris 2.8 and RedHat Advanced Server 2.1 operating systems.
Supported Browsers
The browsers that are supported in the Common Criteria Environment are Netscape 4.79, Netscape 6.2, and Netscape 7.x.
CS Privileged Users and Groups (Roles)
Each CS subsystem has four roles set up by default. The roles that are created are specific to the CS subsystem, and depend on which CS subsystem has been installed. All of the privileged roles (see "About Roles" on page 695 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.
CA
- 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 CS Console).
- Can backup (CSBackup) and restore (CSRestore) 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
- 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 CS 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).
RA
- 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 CS Console).
- Can backup (CSBackup) and restore (CSRestore) the subsystem from the command-line.
- Registration Manager Agents
- Auditors
DRM
- Administrators
- Data Recovery Manager Agents
- Auditors
- 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 CS 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.
OCSP
About Roles
Of all privileged roles supported by CS, 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:
The Administrator role is divided into finer-grained sub-roles, each bearing different responsibilities:
CS Common Criteria Environment Setup and Installation Guide
Understanding Setup of Common Criteria Evaluated Red Hat CS
Appendix C, "Understanding the Common Criteria Evaluated CS Setup," provides a high level description of the steps for setup, installation, and configuration of Red Hat CS in an IT environment of the kind described in "IT Environment Assumptions" on page 690. It gives administrators an idea of what's ahead before starting them on the exact setup steps involved in installation and setup.
CS Common Criteria Environment Setup and Installation Process
Step-by-step instructions to install, configure, and run Red Hat CS in a Common Criteria Evaluated Mode are described in the document CS Common Criteria Setup Procedure.
| Previous |
Contents |
Index |
Next |