CC Certificate 

Security Target 

Validation Report 

Assurance Activity 

Administrative Guide 

The TOE is Information Security Corporation’s CertAgent certificate authority, a Web-based, X.509-compliant certificate authority (CA) that is intended to be used as the core component of an enterprise public key infrastructure.

The TOE is the CertAgent v7.0 patch level 9, which is an X.509-compliant certificate authority (CA). It is an easily managed, web-based certificate authority (CA) intended to be used as the core component of an enterprise public key infrastructure (PKI). Designed to meet the needs of a wide variety of organizations, the current release offers enhanced enrollment services (EST), remote administration, integrated certificate and CRL database, and an OCSP responder. It supports an unlimited number of root and intermediate CAs, providing support for as complex a certificate hierarchy as the size of the enterprise warrants.

The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme for the Protection Profile for Certification Authorities, version 2.1. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 release 5, as well as the Assurance Activities contained in the Protection Profile. The product, when delivered and configured as identified in the guidance documentation, satisfies all of the security functional requirements stated in the Information Security Corporation CertAgent v7.0 patch level 9 Security Target for Common Criteria Evaluation. The evaluation was completed on August 6 2021. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.

Security Audit

The TOE generates audit records of administrator, user, and its own activities. Audit data includes date, time, event type, subject identity, and other data as required. Most audit data are written to the database. Audit records indicating a database failure are stored in a local text file as the database is inaccessible. The TOE allows an external IT entity to access TOE audit records in the database by polling the TOE using the DBAccess REST API.

Communications

The TOE relies on the TLS/HyperText Transfer Protocol Secure (HTTPS) when transmitting sensitive data to and from applicable endpoints.

Certificate requests, certificates, CRLs, and OCSP responses are formed and verified according to RFC 5280, RFC 6960, and RFC 7030. Certificate validation is performed by the TOE.

Sensitive data that needs to be recovered (PKCS#11 Cryptographic Module PINs and other authentication passwords) are encrypted using CMS, in conformance with RFC 5652, and then stored in the database. Sensitive data that does not need to be recovered, EST passwords, are not stored directly, but a check value is created, using PBKDF2/SHA-256, and stored.

Cryptographic Support

Cryptographic support is provided by two components.

• ISC’s Cryptographic Development Kit (ISC CDK)
• PKCS#11 Cryptographic Module

ISC CDK

The ISC CDK is within the TOE’s boundary and is used by the TOE:

• to generate the initial set of authentication credentials (certificates and associated private keys) during installation,
• to generate symmetric keys, wrap them with public keys, and use them to encrypt sensitive data using the CMS format,
• to hash the “to be signed” message bodies of certificates, CRLs, and OCSP responses
• to validate signatures on certificates, CRLs, and requests, and
• to provide communication protection when clients establish TLS/HTTPS connections to the Administrative, CA, Public, EST, OCSP, DBAccess, or RAMI interfaces. Note: Cryptographic functions involving the TLS server private key are provided by the environmental PKCS#11 Cryptographic Module.

PKCS#11 Cryptographic Module

The PKCS#11 Cryptographic Module is used by the TOE:

• to generate, store, and provide cryptographic operations (unwrapping DEKs) involving the private key for the “System” credential (certificate and private key),
• to generate, store, and provide cryptographic operations (digital signatures) involving the private key for all issuer credentials (certificates and private keys), and
• to generate, store, and provide cryptographic operations (digital signature) involving the private key for the TLS/HTTPS server credential (certificate and private key).

The PKCS#11 Cryptographic Module securely stores the high value certificate authority keys and uses them to perform the signature operations that define a certificate authority. The PKCS#11 Cryptographic Module also securely stores the TLS/HTTPS server key and provides cryptographic services involving that key. PKCS#11 Cryptographic Modules often require a PIN or other authentication when the application using them starts and the TOE provides mechanisms for injecting this information during its startup procedures.

In the evaluated configuration, the PKCS#11Cryptographic Module is Thales’ Luna USB HSM.

User Data Protection

The TOE supports the creation of multiple certificate profiles by CA Administrators. Each profile is customizable by a CA Administrator and includes a certificate-based ACL of CA Operations Staff members allowed to issue or revoke certificates using the profile. Certificate requests are assigned a unique identifier upon submission that is used to link the request to the issued certificate.

The TOE provides relying parties two methods to check the status of a certificate:

• X.509v2 CRLs
• OCSP

CRLs can be issued manually, on a schedule, or when a certificate is revoked for a set of configurable reason codes.

Identification and Authentication

The TOE uses two different identification and authentication methods, depending on the role and action being performed:

• EST authentication - EST authentication supports either certificate-based authentication or subscriber name/password authentication (over HTTPS) in cases where the requester does not have a valid certificate. For subscriber name/password authentication (over HTTPS), privileged users in the CA Operation Staff role create and manage the subscriber name/password associations.
• Certificate-based Identification and Authentication - Access to the Admin Site, CA Account Site, DBAccess API, or RAMI API requires certificate-based client authentication using HTTPS. The functions available depend on the ACL and permissions that are assigned to the certificate used to authenticate. The portion of the Public Site allowing self-service revocation by subscribers also requires certificate-based client authentication using HTTPS.

Most TOE activities, and all activities involving the issuance or revocation of certificates, require certificate-based authentication.

PKCS#11 Cryptographic Modules support a variety of authentication options including passwords, smart cards, PED devices, and fingerprints. In all cases, someone must enable the PKCS#11 Cryptographic Module as part of the initialization of the TOE. This step is performed locally on the system during startup of the TOE.

Access to the TOE’s local console is controlled by the underlying environmental operating system which performs the required identification and authentication when an administrator logs on.

Security Management

The TOE is managed by authorized administrators using a web user interface and the local console as needed. All certificate issuance related administrative actions are performed via the web interface. The TOE supports three (3) roles (Administrator, Auditor, and CA Operations Staff) each of which consists of an access control list (ACL) of one or more X.509 certificates and one or more permissions (issue, revoke, RAMI, etc.).

Only users who hold an administrator role in the TOE are allowed to have administrator privileges on the physical system on which the TOE is installed. They can:

• inject the PKCS#11 Cryptographic Module PIN to unlock the “System” credential’s private key,
• start/stop the TOE and the Database,
• run the CACLI program (allows the scripting of the creation of a root or issuer, trust anchor management, ACL management),
• run the Report Generator Program, or
• run the update tool (to check for updates or apply updates to the system).

Protection of the TSF

The TOE encrypts any sensitive information, before it is sent to the environmental database, using the asymmetric “System” credential’s public key and the CMS format. These encrypted symmetric keys are the only symmetric keys that are persisted by the TOE. When the information is needed later, the encrypted data is retrieved from the database, and the TOE uses the “System” credential’s private key, via the PKCS#11 Cryptographic Module’s PKCS#11 API, to unwrap the symmetric key.

The TOE maintains the password of PKCS#11 Cryptographic Module storing the “System” credential in memory until it exits. The TOE does not store, or directly use, any private keys (they are stored and protected by the PKCS#11 Cryptographic Module which performs operations with those keys at the TOE’s request). When the TOE shuts down all sensitive data in memory is cleared.

TOE Access

The TOE’s Admin Site and CA Account Site display a warning banner prior to allowing any administrative actions to be performed. The TOE’s web interface will terminate sessions when they time out or when an authenticated user clicks the logout link in the navigation pane.

Trusted Path/Channels

The TOE provides a trusted path/channel for secure communication between itself and external IT entities such as a registration authority (RA), audit server, or similar entities which are permitted to connect to the TOE, over client authenticated HTTPS/TLS. Privileged users accessing the TOE’s web interfaces also use a trusted path established and secured with client authenticated HTTPS/TLS. Subscribers with existing, valid certificates, also use a trusted path, established and secured with client authenticated HTTPS/TLS, to perform certificate renewal, via EST, or self-management, via the TOE’s Public Site web interface. Subscribers, and other non-privileged users, are permitted to connect to the TOE’s Public Site with unauthenticated HTTPS/TLS. Relying parties are permitted to connect to parts of the TOE’s Public Site, with either unauthenticated HTTPS/TLS or unprotected HTTP, to obtain certificate status or other information required to validate certificates issued by the TOE.

For communication between the TOE and environmental components (notably the database and the HSM) the Operational Environment provides a non-encrypted, trusted channel. Secure communication is enforced between the TOE and IT entities in the Operational Environment using the Operational Environment’s JRE, JNDI, JDBC, and PKCS #11 Cryptographic Module components installed on the local system. These trusted channels transfer TOE data to and from IT entities within the Operational Environment.

Vendor Information