Home Similarity Diff BR Diff CS Diff EVG Diff SMIME Diff TLS

Home Show similarity Differences BR (in/out) Differences CS (in/out) Differences EVG (in/out) Differences SMIME (in/out) Differences TLS (in/out)

BR

CS

EVG

SMIME

TLS

BR

### 6.1.1 Key pair generation

EVG

### 6.1.1 Key pair generation All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA's Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. The Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process: 1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement; 2. Included appropriate detail in its Root Key Generation Script; 3. Maintained effective controls to provide reasonable assurance that the Root CA key pair was generated and protected in conformity with the procedures described in its CP/CPS and with its Root Key Generation Script; 4. Performed, during the Root CA key generation process, all the procedures required by its Root Key Generation Script.

BR

#### 6.1.1.1 CA Key Pair Generation For CA Key Pairs that are either i. used as a CA Key Pair for a Root Certificate or ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: 1. prepare and follow a Key Generation Script, 2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and 3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair. For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD: 1. prepare and follow a Key Generation Script and 2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process. In all cases, the CA SHALL: 1. generate the CA Key Pair in a physically secured environment as described in the CA's Certificate Policy and/or Certification Practice Statement; 2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge; 3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's Certificate Policy and/or Certification Practice Statement; 4. log its CA Key Pair generation activities; and 5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

CS

#### 6.1.1.1 CA Key Pair Generation For CA Key Pairs that are either i. used as a CA Key Pair for a Root Certificate or ii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: 1. prepare and follow a Key Generation Script, 2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and 3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair. For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD: 1. prepare and follow a Key Generation Script and 2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process. In all cases, the CA SHALL: 1. generate the CA Key Pair in a physically secured environment as described in the CA's Certificate Policy and/or Certification Practice Statement; 2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge; 3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's Certificate Policy and/or Certification Practice Statement; 4. log its CA Key Pair generation activities; and 5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

SMIME

#### 6.1.1.1 CA key pair generation For CA Key Pairs that are either 1. used as a CA Key Pair for a Root CA Certificate; or 2. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: 1. prepare and follow a Key Generation Script; 2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process; and 3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair. For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD: 1. prepare and follow a Key Generation Script; and 2. either (i) have a Qualified Auditor witness the CA Key Pair generation process, or (ii) video-record the entire CA Key Pair generation process for review by its Qualified Auditor. In all cases, the CA SHALL: 1. generate the CA Key Pair in a physically secured environment as described in the CA's CP and/or CPS; 2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge; 3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's CP and/or CPS; 4. log its CA Key Pair generation activities; and 5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its CP and/or CPS and (if applicable) its Key Generation Script.

BR

#### 6.1.1.2 RA Key Pair Generation

BR

#### 6.1.1.3 Subscriber Key Pair Generation The CA SHALL reject a certificate request if one or more of the following conditions are met: 1. The Key Pair does not meet the requirements set forth in [Section 6.1.5](#615-key-sizes) and/or [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); 2. There is clear evidence that the specific method used to generate the Private Key was flawed; 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; 4. The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate); 5. The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see ). If the Subscriber Certificate will contain an `extKeyUsage` extension containing either the values `id-kp-serverAuth` [RFC5280] or `anyExtendedKeyUsage` [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.

CS

#### 6.1.1.3 Subscriber Key Pair Generation The CA SHALL reject a certificate request if one or more of the following conditions are met: 1. The Key Pair does not meet the requirements set forth in [Section 6.1.5](#615-key-sizes) and/or [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); 2. There is clear evidence that the specific method used to generate the Private Key was flawed; 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; 4. The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate); 5. The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see ).

SMIME

#### 6.1.1.3 Subscriber key pair generation The CA SHALL reject a Certificate Request if one or more of the following conditions are met: 1. The Key Pair does not meet the requirements set forth in [Section 6.1.5](#615-key-sizes) and/or [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); 2. There is clear evidence that the specific method used to generate the Private Key was flawed; 3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; 4. The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of [Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate); 5. The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see ). The CA or a Delegated Third Party MAY generate the Private Key on behalf of the Subscriber.