Appendix B. Defining the Common Criteria Environment

This appendix provides information about the configuration used to set up Red Hat Certificate System 8.1 in the Common Criteria environment, as well as information for the certification security target.

B.1. Common Criteria: Setup and Operations

The purpose of this appendix is to give administrators a guideline on how to set up and maintain the Common Criteria environment. This is separate from the sections for the security target which defines how Red Hat Certificate System satisfies the requirement.
This section lists the configuration that is required or allowed for a Common Criteria environment. The actual procedures and instructions are contained in the Administrator's Guide or this Deployment Guide.

IMPORTANT

The Certificate System Registration Manager subsystem is not included in the target of evaluation, and therefore its configuration and features are not included in this discussion.

B.1.4. Target of Evaluation Security Environment Assumptions

B.1.5. IT Environment Assumptions

The assumptions about the target of evaluation'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 target security functions-discovered attacks in order to identify attacks and create an attack deterrent.
  • Require inspection for downloads.
  • Respond to possible loss of stored audit records.
  • Run the subsystem instances in an environment where the applications and services are restricted to a trusted path (SELinux).
  • Run the subsystem instances in an environment that enforces data integrity and establishes policies for periodic integrity checks (SELinux).

B.1.5.1. Reliable Timestamp

Red Hat Certificate System 8.1 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, Red Hat Certificate System 8.1 administrators need to make sure the operating system has a time-syncing mechanism with a reliable source.

B.1.5.2. Private and Secret Key Zeroization

Red Hat Certificate System 8.1 relies on a FIPS 140 validated module accessed through NSS to perform critical key generation, key storage, and zeroization for key destruction. There are no explicit calls from Red Hat Certificate System 8.1 code to do private and secret key zeroization. NSS automatically handles zeroization for Red Hat Certificate System 8.1 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.

B.1.5.3. Password and Certificate Storage

By default, Red Hat Certificate System 8.1 stores passwords on a per instance basis in /var/lib/instance_name/conf/password.conf (protected by Linux operating system permissions). However, for Common Criteria purposes, Red Hat Certificate System 8.1 utilizes the nuxwdog executable to store unencrypted passwords in the kernel keyring through sockets, and the associated instance-specific password.conf file is deleted for security reasons.
Red Hat Certificate System system certificates are stored in an NSS database on a FIPS-validated HSM (Section B.1.5.4, “Hardware Token”).

B.1.5.4. Hardware Token

To meet Common Criteria requirements, Red Hat Certificate System 8.1 protects security critical keys and other information by either encrypting it or storing it within a hardware cryptographic module that has been certified to FIPS 140 Level 3 operating in a FIPS-approved or recommended mode of operation. Red Hat Certificate System 8.1 uses the PKCS#11 module provided by the cryptographic hardware vendors to access the hardware cryptographic modules. Supported cryptographic hardware components are listed in Section 6.1.4, “Supported HSM”.

B.1.5.5. Protection of Private and Secret Keys

Within a Common Criteria certified environment, Red Hat Certificate System 8.1 certificate private keys and secret keys are to be generated and stored in a FIPS 140-1 level 3 certified hardware cryptographic token. Administrators are required during the installation process to select an HSM which conforms to this requirement in order to generate its CIMC keys.
The Red Hat Certificate System 8.1 private (asymmetric) keys for a CA are:
  • Private key associated with the CA server certificate.
  • Private key associated with the CA subsystem certificate.
  • Private key associated with the CA audit log signing certificate.
  • Private key associated with the CA signing certificate.
  • Private key associated with the OCSP Responder signing certificate.
The Red Hat Certificate System 8.1 private (asymmetric) keys for a DRM are:
  • Private key associated with the DRM server certificate.
  • Private key associated with the DRM subsystem certificate.
  • Private key associated with the DRM audit log signing certificate.
  • Private key associated with the DRM transport certificate.
  • Private key associated with the DRM storage certificate (for DRM key archival).
The Red Hat Certificate System 8.1 private (asymmetric) keys for an OCSP are:
  • Private key associated with the OCSP server certificate.
  • Private key associated with the OCSP subsystem certificate.
  • Private key associated with the OCSP audit log signing certificate.
  • Private key associated with the OCSP signing certificate.
The Red Hat Certificate System 8.1 private (asymmetric) keys for a TKS are:
  • Private key associated with the TKS server certificate.
  • Private key associated with the TKS subsystem certificate.
  • Private key associated with the TKS audit log signing certificate.
The Red Hat Certificate System 8.1 private (asymmetric) keys for a TPS are:
  • Private key associated with the TPS server certificate.
  • Private key associated with the TPS subsystem certificate.
  • Private key associated with the TPS audit log signing certificate.
The sole use of secret (symmetric) keys by Red Hat Certificate System 8.1 is to generate a DES3 key on-the-fly which is used to encrypt a user's private (asymmetric) key before this generated secret key and encrypted user's private key are wrapped together by the DRM's storage key and stored as archived data in the DRM's internal Red Hat Directory Server 8.2 LDAP database.

B.1.6. Red Hat Certificate System 8.1 Privileged Users and Groups (Roles)

The procedures for creating Certificate System subsystem users are covered in the Certificate System Administrator's Guide:
Of all privileged roles supported by Red Hat Certificate System 8.1, the Certificate Manager agents role and the DRM agent role are the ones that map directly to the officer role defined in the security target and the CIMC PP. The Online Certificate Status Manager agents are a sub-group of the administrator role defined in the CIMC PP.
Table B.1, “Mappings for Default Roles” shows the mapping between Certificate System roles and CIMC PP roles.

Table B.1. Mappings for Default Roles

CIMC PP Role Certificate System Role
Administrator
  • Administrators for the CA, DRM, OCSP, and TKS subsystems
  • Online Certificate Status Manager agents
  • Administrators for the TPS
Officer
  • Certificate Manager agents
  • Data Recovery Manager agents
  • TPS agents
Auditor
  • Auditors from CA, DRM, OCSP, TKS, and TPS

B.1.7. Understanding Setup of Common Criteria Evaluated Red Hat Certificate System 8.1

This document describes at a high level the steps for setup, installation, and configuration of Red Hat Certificate System 8.1 in an IT environment of the kind described in Section 4.7, “Implementing a Common Criteria Environment”. It gives administrators an idea of what's ahead before starting them on the exact setup steps involved in installation and setup.

B.1.7.1. Understanding the Common Criteria Environment

This section describes the environment before Red Hat Certificate System 8.1 is installed and configured.
B.1.7.1.1. Secure Environment
This section describes the secure environment you will be instructed to set up before installing and configuring Red Hat Certificate System 8.1.
B.1.7.1.1.1. Network Environment
It is important to make sure that only those users that are part of the Red Hat Certificate System 8.1 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.
B.1.7.1.1.2. Operating System Environment
Because Red Hat Certificate System 8.1 relies on the IT environment to provide the basic operating system file system security, inter-process communication, and process space protection, Red Hat Certificate System 8.1 must be installed and run on an operation system certified at a Common Criteria assurance level no less than the level of Red Hat Certificate System 8.1 itself, such as Red Hat Enterprise Linux 5.6 with SELinux in enforcing mode.
B.1.7.1.2. Verifying Package Bits
All Red Hat Certificate System packages are GPG signed by Red Hat, for security. Our key is available at https://access.redhat.com/security/team/key/#package. You can verify each package with the following command:
rpm --checksig -v filename
If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command:
md5sum filename
B.1.7.1.3. Red Hat Certificate System 8.1 Roles Assignment
In order to maintain accountability, it is prudent to require individual users to log into their individual accounts for regular Red Hat Certificate System 8.1 operations and maintenance. To achieve this, you first have to assign Red Hat Certificate System 8.1 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 Red Hat Certificate System 8.1. Red Hat Certificate System 8.1 allows more than one user to have the same role (for example, you can have two CA agents); however, Red Hat Certificate System 8.1 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 Section B.1.6, “Red Hat Certificate System 8.1 Privileged Users and Groups (Roles) ” for a description of the various Red Hat Certificate System 8.1 privileged roles.
B.1.7.1.4. Who Needs to Be Present
During the installation and configuration, the Red Hat Certificate System 8.1 audit function is not operational, so it is crucial that all Red Hat Certificate System 8.1 roles be present to witness the installation and make necessary operations and decisions. Section B.1.6, “Red Hat Certificate System 8.1 Privileged Users and Groups (Roles) ” lists the default Certificate System user types, while the procedures for creating the required operating system accounts are in Section 6.3.7, “Setting up Operating System Users and Groups”.
Required configuration files like CS.cfg are protected and audited within the operating system environment. Therefore, only operating system administrators can directly edit these files. During installation, an operating system administrator must be present to help set any custom configuration in the CS.cfg file that is required.

B.1.8. Common Criteria Deployment Scenarios

As long as the subsystems are installed and configured following the Common Criteria environment rules and guidelines outlined in this book, Red Hat Certificate System 8.1 can be deployed in any desired scenario. A deployment can, for example, have a root CA, a CA subordinate to an Red Hat Certificate System 8.1 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.
Likewise, Data Recovery Manager can work with any CA within the Red Hat Certificate System environment. An OCSP responder can work with any CA within the environment, and one OCSP responder can work with multiple CAs.
Similarly, multiple TKS and TPS instances may be set up to deploy a token management system.
A Common Criteria environment can be set up with all subsystems installed on the same host, or with some or all subsystems on separate hosts.

B.1.9. Understanding Subsystem Setup

This section describes at a high-level what to expect when configuring an Red Hat Certificate System 8.1 subsystem as described in Section 5.2, “Common Criteria Environment: A Walkthrough of the Preparation, Installation, and Configuration for a Certified PKI”. Links to detailed procedures for each feature are given in Chapter 8, After Configuration: Checklist of Configuration Areas for Deploying Certificate System.

B.1.9.1. Red Hat Certificate System 8.1 Role Users and Authorization

In Red Hat Certificate System 8.1, you create users and then assign them to groups (also called 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 (Red Hat Certificate System 8.1 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 that will process the request.
Role users must follow the site policy on changing passwords and renewing certificates at appropriate intervals and to appropriate values. The site policy will govern the required settings for the password policy, such as proper password lengths, the password history, and password strength.
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 section 13.1. About Authorization in the Administrator's Guide and Section 2.4.6, “Users, Authorization, and Access Controls”.

NOTE

While there is flexibility to add groups and change the ACLs under the Common Criteria environment, be cautious about creating scenarios that are not secure, such as allowing anyone access to the agent services interface. Also, be careful when changing the default roles or when adding roles so 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.

B.1.9.2. Audit Logs

The Common Criteria environment requires that the signed audit log file feature be enabled and configured. Sections 14.2.5. Managing Signed Audit Logs and 14.3.3. Managing Audit Logs in the Administrator's Guide provide complete information about how to set up the signed audit logs.
Auditors must comply with the site policy to run the AuditVerify with sufficient frequency to verify the audit log signatures, along with reviewing the audit logs. Although the Certificate System subsystems are designed to deny operations that violate defined security policies, it is up to the site to define operational policies on the audit log review frequency to detect any type of attack.
If a subsystem is unable to write to its audit logs for any reason, that Certificate System subsystem will shut down to prevent possible loss of audit records.

B.1.9.3. Certificate Profiles

In the Common Criteria environment, you must set up the certificate profiles feature for certificate enrollment in a CA subsystem. You can set up and enable any or all of the pre-built certificate profiles. You can also create other certificate profiles in the Red Hat Certificate System 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 Red Hat Certificate System 8.1 CA administrators are allowed to configure the certificate enrollment profiles, such as setting ranges for fields and enabling extensions. It is the Red Hat Certificate System CA 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 Section 4.4.6, “Using and Customizing Certificate Profiles” and section 2.2 in the Administrator's Guide for complete information about certificate profiles.

B.1.9.4. 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 Section 4.4.7, “Planning Authentication Methods” and chapter 8 in the Administrator's Guide for complete information about authentication.

B.1.9.5. 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 6 in the Administrator's Guide.

B.1.9.6. 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 careful when selecting the email addresses to use, and make sure they belong to appropriate roles. For complete information on jobs, see chapter 10 in the Administrator's Guide.

B.1.9.7. Notifications

Automated email notifications are event-driven tasks that send out an email through 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 careful when selecting the email addresses to use, and make sure they belong to appropriate roles. For complete information on notifications, see chapter 9 in the Administrator's Guide.

B.1.9.8. Publishing

You can set up any of the methods of publishing in any of the configurations available in Red Hat Certificate System 8.1 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 7 in the Administrator's Guide.

B.1.9.9. Self Tests

Red Hat Certificate System 8.1 provides a self-diagnostic feature that checks the sanity of a few key items during an Red Hat Certificate System 8.1 subsystem startup. Any failed self test is an indication of a fatal error to the subsystem. Technically, Red Hat Certificate System 8.1 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 Red Hat Certificate System 8.1 Common Criteria setup, but this is because the self tests are turned on and operational by default. For more information, see section 12.11 in the Administrator's Guide.

B.1.9.10. 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 a minimum of two Data Recovery Manager agents to work to approve a recovery request cooperatively; the DRM settings can be configured to require even more than two recovery agents to approve a recovery request. 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 3 in the Administrator's Guide.

B.1.9.11. 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 set up 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 section 6.6 in the Administrator's Guide.

B.1.9.12. Token Management System

Certificate System creates, manages, renews, and revokes certificates, as well as archiving and recovering keys. For organizations which use smart cards, the Certificate System has a token management system — a collection of subsystems with established relationships — to generate keys and requests and receive certificates to be used for smart cards. For details, see section 1.4 in the Administrator's Guide.
To understand how to set up and use smart cards through the Token Key Service (TKS) and Token Processing System (TPS), see section 5.1 in the Administrator's Guide.

B.1.9.13. Features That Are Not Part of the Common Criteria Environment

Some features or ways of configuring Red Hat Certificate System 8.1 are not part of the Common Criteria environment:
  • Using anything other than hardware tokens to create and store CIMC keys and certificates is not supported for Common Criteria.
  • The watchdog daemon prompts for passwords to ensure that passwords are never entered or stored in the clear. Using the plain-text password file, password.conf is not supported for Common Criteria. nk
  • For security, all services should run using secure connections. Using the administrative interface (the subsystem Java console) in non-SSL client authentication mode is not supported for Common Criteria.
  • Using a Registration Manager is not supported for Common Criteria.
  • For security, all services should run using secure connections. Running the internal database or any publishing LDAP database in non-SSL client authentication mode is not supported for Common Criteria.
  • Enrollment is supported using certificate profiles. Using the deprecated policy feature is not supported.
  • Certificate System services use the operating system settings to provide an additional layer of security. SELinux must be in enforcing mode for the Common Criteria environment, not disabled or permissive.
  • For security, all services should run using secure connections. Configuring OCSP publishing to a non-SSL port on the OCSP is not supported for Common Criteria.
  • Customized plug-ins for jobs, notifications, or other extensible areas allow Certificate System performance to be extended, but they cannot be evaluated as part of the target of evaluation. Adding a custom plug-in in essence breaks the Common Criteria assurance. If adding custom plug-ins is unavoidable, it is the responsibility of all role users to carefully evaluate these plug-ins before making them part of the system.
  • As with Certificate System plug-ins, the Certificate System ACLs provide comprehensive security for susbsystem/subsystem and subsystem/user interactions. Any changed the default ACLs for a custom environment cannot be evaluated and is therefore not supported for Common Criteria. 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.
Instructions for disabling these features, where necessary, are included within the administration documentation to conform to the defined Common Criteria environment.

B.1.10. Reporting Security Flaws

Although a problem may reported through email by contacting pki-users@redhat.com, more serious issues should be reported to Red Hat support and entered as a software flaw. All software flaw reporting utilizes the Red Hat bug-tracking system Bugzilla. Bugzilla allows software flaws to be reported against specific versions of Red Hat Certificate System.
Updates are deliverd through the Red Hat Errata system and can be installed using local or remote content repositories and the yum system tools or by downloading packages from Red Hat Network. Applying updates and new packages is described at https://access.redhat.com/kb/docs/DOC-11259.
Support for a specific issue may be obtained through several different avenues:
  • The Red Hat Knowledgebase. Many technical issues can be resolved the Knowledgebase articles. Before contacting technical support, search the Knowledgebase to see if the question or issue is already a known case.
  • Production support. Red Hat Technical Support can be contacted through web or phone depending upon the level of service:
    • Basic support is for non-essential or prototype systems.
    • Standard support is for most business systems that are not mission critical and only require support during normal business hours.
    • Premium support is for mission critical services, which require rapid response.
    This is described in more detail on the Red Hat Customer Portal as part of explaining the service-level agreements, https://access.redhat.com/support/offerings/production/sla.html.
  • Technical account manager (TAM). A service provided by supper service highly personalized support relationships. This service offers a highly-skilled, proactive support engineer who knows the client personally and understands their IT infrastructure, internal processes and overall business needs. The TAM is accountable for driving technical issues like bugs. This level of support provides access to a separate issue tracker for reporting and tracking all technical requests.
    This is described in more detail on the Red Hat Customer Portal at https://access.redhat.com/support/offerings/tam/.