6.1 Key pair generation and installation

6.1.1 Key pair generation

6.1.1.1 CA key pair generation

For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that 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 Root CA Key Pair generation process or record a video of the entire Root 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 created after the Effective Date 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 Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process.

In all cases, the CA SHALL:

  1. generate the keys in a physically secured environment as described in the CA’s Certificate Policy and/or Certification Practice Statement;
  2. generate the CA keys using personnel in trusted roles under the principles of multiple person control and split knowledge;
  3. generate the CA keys 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 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.

6.1.1.2 RA key pair generation

No stipulation.

6.1.1.3 Subscriber key pair generation

The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys).

6.1.2 Private key delivery to subscriber

Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.

If the CA or any of its designated RAs generated the Private Key on behalf of the Subscriber, then the CA SHALL encrypt the Private Key for transport to the Subscriber.

If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

6.1.3 Public key delivery to certificate issuer

No stipulation.

6.1.4 CA public key delivery to relying parties

No stipulation.

6.1.5 Key sizes

Certificates MUST meet the following requirements for algorithm type and key size.

(1) Root CA Certificates

  • Digest algorithm
    • SHA-1*, SHA-256, SHA-384 or SHA-512
  • Minimum RSA modulus size (bits)
    • 2048
  • ECC curve
    • NIST P-256, P-384, or P-521
  • Minimum DSA modulus and divisor size (bits) ***
    • L= 2048, N= 224 or L= 2048, N= 256

(2) Subordinate CA Certificates

  • Digest algorithm
    • SHA-1*, SHA-256, SHA-384 or SHA-512
  • Minimum RSA modulus size (bits)
    • 2048
  • ECC curve
    • NIST P-256, P-384, or P-521
  • Minimum DSA modulus and divisor size (bits)***
    • L= 2048, N= 224 Or L= 2048, N= 256

(3) Subscriber Certificates

  • Digest algorithm
    • SHA1*, SHA-256, SHA-384 or SHA-512
  • Minimum RSA modulus size (bits)
    • 2048
  • ECC curve
    • NIST P-256, P-384, or P-521
  • Minimum DSA modulus and divisor size (bits)***
    • L= 2048, N= 224 Or L= 2048, N= 256

* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.

*** L and N (the bit lengths of modulus p and divisor q, respectively) are described in the Digital Signature Standard, FIPS 186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf).

6.1.6 Public key parameters generation and quality checking

RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 216+1 and 2256-1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89].

DSA: Although FIPS 800-57 says that domain parameters may be made available at some accessible site, compliant DSA certificates MUST include all domain parameters. This is to insure maximum interoperability among relying party software. The CA MUST confirm that the value of the public key has the unique correct representation and range in the field, and that the key has the correct order in the subgroup. [Source: Section 5.3.1, NIST SP 800-89].

ECC: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 56A: Revision 2].

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:

  1. Self-signed Certificates to represent the Root CA itself;
  2. Certificates for Subordinate CAs and Cross Certificates;
  3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and
  4. Certificates for OCSP Response verification.