6.1. Key Pair Generation and Installation

6.1.1. Key pair generation

Conforming CA's cryptographic keys are generated by the package chosen for certificate handling. End entities cryptographic keys are locally generated by their application during the requesting process.

6.1.2. Private key delivery to entity

The entity MUST generate his own key pair.

6.1.3. Public key delivery to certificate issuer

For individual certification, the entity SHALL submit a certification request containing the public key, locally generated, to the CA/RA. Every conforming CA MUST specify in its CPS the exact procedures for delivering public key. For CA's certification, the subject CA generates the key pair.

6.1.4. CA public key delivery to users

Conforming CA MUST provide mechanisms to deliver CA public key to the users in a trustworthy manner. Further details MUST be specified in the CPS. In every case CA's public keys MUST be publicly available in a repository accessible via standard protocol such as HTTP or LDAP.

6.1.5. Key sizes

The minimum length of the private key of an end entity to be certified MUST be decided by the CA issuer and MUST NOT be less than the value of 1024 bits. A CA key pair MUST have a minimum length of 2048 bits.

6.1.8. Hardware/software key generation

The keys can be generated in software or in hardware (e.g. on a cryptodevice) depending on the various tools available to the entities.

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

The purposes for which a key can be used MAY be restricted by a CA through the keyUsage extension in the certificate.

This is a field that indicates the purpose for which the certified public key is used. Certificates issued under this policy MUST have the keyUsage extension flagged as critical. This means that the certificate SHALL be used only for a purpose for which the corresponding key usage bit is set to one. CA certificates

In CA's certificates the keyUsage extension SHOULD contain the following bits set to one:

  • digitalSignature

  • nonRepudiation

  • keyCertSign

  • cRLSign

It MAY contain also other bits set to one. User certificates

In personal (user) certificates the keyUsage extension SHOULD contain the following bits set to one:

  • digitalSignature

  • keyEncipherment

  • nonReputiation

  • dataEncipherment Server certificates

In server (application, service) certificates the keyUsage extension SHOULD contain the following bits set to one:

  • digitalSignature

  • nonReputiation

6.2. Private Key Protection

6.2.1. Standards for cryptographic module

This policy does not mandate the adoption of cryptographic module compliant with pre-determined standards. Every conforming CA MAY give in the CPS more details about the adoption of standard compliant module.

6.2.2. Private key (n out of m) multi-person control

The private key of individual MUST NOT be under (n out of m) multi-person control. Only private keys belonging to a CA, a hardware component or a software component MAY be under such a control: in this case the type of control MUST be specified in the CPS.

6.2.3. Private key escrow

This policy discourages the implementation of private key escrow policy both for end entities and CA. Implementation of such policies MAY be permitted if and only if the governing law of the country in which the CA is established explicitly requires them.

6.2.4. Private key backup

This policy suggests that all the parties SHOULD maintain a backup copy of the private key in order to reconstitute it in case of destruction of the key. This backup MUST be carefully protected especially in the case of backup of private key CA.

6.2.5. Private key archival

This policy suggests the implementation of a procedure for private key archival only for private key used for encryption/decryption. Indeed it MAY be necessary to maintain a copy of a private key in order to correctly decrypt messages even if the corresponding public-key certificate is expired.

6.2.6. Private key entry into cryptographic module

The private key of all entities SHOULD be stored in an encrypted form. This provision is particularly important if the entity is a CA.

6.2.7. Method of activating private key

Specific details about how to activate private key SHOULD be found in the CPS. As a general suggestion this policy recommends that for the activation of a private key some specific activation data MUST be entered in the cryptographic module. At least the activation data MUST consist in a PIN or passphrase, but for the most valuable private key (e.g. the ones belonging to CA) the use of hardware tokens or biometrics data is suggested.

6.3. Other Aspects of Key Pair Management

6.3.1. Public key archival

A conforming CA MUST archive all issued certificates. Mechanisms to provide integrity controls other than digital signatures MAY be implemented.

6.3.2. Usage periods for the public and private keys CA key pair

The validity period of a conforming CA's key pair MUST NOT extend 5 years. End entity key pair

The validity period of an end entity key pair MUST NOT extend one year.

6.4. Activation Data

6.4.1. Activation data generation and installation

Pass phrases or PINs SHALL be selected according to "best practice". This means that it is necessary to suggest a suitable minimal length for the pass phrases and to enforce mechanisms to check that pass phrases show enough entropy.

6.4.2. Activation data protection

Pass phrases protecting private keys SHALL be accessible only to the legitimate users (e.g. certificate holder for personal certificates, CA operators for CA signing keys, etc). An exception for this indication is the implementation of a secure archival/backup mechanism for activation data. Such a mechanism MUST be clearly defined in the CPS.

6.5. Computer Security Controls

6.6. Life Cycle Technical Controls

6.7. Network Security Controls

This policy strongly suggests that the machine on which the cryptographic module used for CA operations SHOULD be kept off-line to prevent network attacks. In every case network access to the CA workstation MUST be limited in order to protect the CA's private key in an appropriate way from disclosure.

6.8. Cryptographic Module Engineering Controls

No stipulation.