Technical security controls

See below for the performed technical security controls.

• Key Pair Generation
• Private Key Protection
• Other aspects of key pair management
• Activation Data
• Computer security controls
• Life-Cycle technical controls
• Network security controls
• Time-stamping

Key Pair Generation

See below for the practice statements on key pair generation.

• CA key pair generation: At the RA request, an API-based, automated, documented process to generate CA key pairs is executed. The CA system will perform the following when generating a CA Key Pair:

  1. Generate the CA Key Pair in a physically secured environment;
  2. Generate the CA Key Pair within hardware cryptographic modules meeting the applicable requirements of §6.2.11;
  3. Log its CA Key Pair generation activities; and
  4. Maintain adequate controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in this CPS.

• Subscriber key pair generation: The Applicant or Subscriber must generate or initiate a new, secure, and cryptographically sound Key Pair to be used with the Subscriber’s Certificate or Applicant’s Certificate Application. PKIaaS only generates the subscriber key pairs when a chosen certificate profile supports the PKCS #12 format.

• Key delivery to subscriber: In the case where the CA generates the Key Pair on behalf of the Subscriber, the Private Key will be delivered to the Subscriber in a cryptographically secure manner with at least 168-bit encryption strength in a PKCS #12 format.

• Public key delivery to certificate issuer: Subscriber Public Keys are delivered to the CA in a Certificate Signing Request as part of the Certificate Application process.

• CA public key delivery to relying parties: The CA Public Keys are provided to the Relying Parties by the RA.

• Key sizes: For CA and Subscriber Certificates, the key sizes supported are:

  • RSA 4096
  • RSA 3072
  • RSA 2048
  • ECDSA P-521
  • ECDSA P-384
  • ECDSA P-256

• Public key parameters generation and quality checking: CA Public Keys are generated and protected on a cryptographic module compliant with at least FIPS 140-2 Level 3 certification standards.

• Subscriber public keys: No stipulation.

• Key usage purposes: No stipulation.

Private Key Protection

See below for the practice statement on private key protection.

• Cryptographic module standards and control: CA Private Keys must be used and unlocked on cryptographic modules that meet or exceed the requirements as defined in §6.2.11. The cryptographic modules are held in secure facilities.

• CA private key multi-person control: Upon activation of any CA Private Key, a minimum of two-person control will be established, and it may be implemented as a combination of technical and procedural controls. Persons involved in managing and using the CA Private Keys shall be Trusted Roles.

• Private key escrow: CA Private Keys are not escrowed.

• Private key backup: All copies of the CA’s Private Key shall be protected in the same manner as the original.

• Private key archival: CA Private Keys are not archived.

• Private key transfer into or from cryptographic module: CA Private Keys shall be generated by and secured in a cryptographic module. Private Keys are backed up and restored to multiple HSMs to provide high availability and disaster recovery, while remaining secured within the boundary of the cryptographic module.

• Private key storage on cryptographic module: PKIaaS stores CA Private Keys on a secure cryptographic module as defined.

• Method of activating private keys: PKIaaS activates CA Private Keys upon generation for automated signing of revocation data and RA-initiated certificate signing.

• Private key deactivation methods: PKIaaS deactivates CA Private Keys upon termination of service.

• Private signature key destruction method: No stipulation.

• Cryptographic module rating: PKIaaS generates and protects CA Key Pairs on a cryptographic module that is compliant with at least FIPS 140-2 Level 3 certification standards.

Other aspects of key pair management

See below for the practice statement in other aspects of key pair Management

• Public key archival: PKIaaS archives CA public keys.
• Certificate operational periods and key pair usage periods: As PKIaaS does not reuse CA Certificate Key Pairs, the validity of these Key Pairs is limited to the life of the Certificate, up to, but no more than, 20 years. No stipulation limits the usage period of Subscriber certificate key pairs.

Activation Data

See below for the practice statement on activation data.

• Activation data generation and installation: Trusted Role personnel generates CA Private Key activation data under two-person control using the methods provided by the HSM. PKIaaS transmits activation data for RA private keys via an appropriately protected channel, and out-of-band from the associated cryptographic module.

• Activation data protection: Only Trusted Role personnel can access to CA Private Key activation data. Two person secure the physical storage of CA Private Key activation data. The RA holds responsibility for protecting activation data for RA private keys.

• Other aspects of activation data: No stipulation.

Computer security controls

See below for the practice statement on security control.

• Specific computer security technical requirements: The CA systems are physically secured. The CA systems operate enforce identification and authentication of users. All Trusted Roles with access to the CAs must use hardware tokens in conjunction with a PIN or biometric to gain access to the physical room that contains the CA key material for such CAs.

• Computer security rating: No stipulation.

Life-Cycle technical controls

See below for the practice statement on life-cycle technical controls.

• System Development Controls: The deployment of Entrust-developed systems follows the Entrust software lifecycle development standards.

• Security management controls: The configuration of the CA system and any modifications and upgrades shall be documented and controlled. Entrust detects any unauthorized modification to the CA system to ensure the integrity of the security software, firmware, and hardware for correct operation. The system installation and maintenance follows a formal configuration and change management methodology.

• Life cycle security controls: No stipulation.

Network security controls

See below for the practice statement on security controls.

• A network firewall must protect network access to the CA system. The network firewall limits services allowed to and from the CA system to those required to perform CA functions.

• Protection of the CA system is provided against known network attacks. All unused network ports and services are turned off.

• Any boundary control devices used to protect the network on which PKI systems are hosted deny all but the necessary services to the CA system.

• Entrust scans the CA, network, and all connected ancillary equipment no less than once per month using recognized tools designed to detect network and system vulnerabilities. Entrust updates the scanning tools before each scan with the latest vulnerability signatures. Scans inside and outside the environment identify vulnerabilities. Entrust remediates identified vulnerabilities in accordance with the Entrust security remediation standard and patch management standard.

• All CA systems and all connected ancillary equipment hosted and operated by Entrust have active virus protection and mitigation as defined in the Entrust malware protection standard.

Time-stamping

The CA will record the time of all issued Certificates and recorded transactions using the system clock time derived, and periodically corrected, from a recognized time source.