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.
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.
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.
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.
The keys can be generated in software or in hardware (e.g. on a cryptodevice) depending on the various tools available to the entities.
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.
In CA's certificates the keyUsage extension
SHOULD contain the following bits set to one:
keyCertSign
cRLSign
It MAY contain also other bits set to one.
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 a standard compliant module.
The private key of an 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.
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.
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.
This policy suggests the implementation of a procedure for private key archival only for private key used for decryption.
Private keys for all entities MUST be always stored in an encrypted form with the only exception being private keys corresponding to public keys certified for servers, applications or software agents.
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 pass phrase, but for the most valuable private key (e.g. the ones belonging to CA) the use of hardware tokens or biometrics data is suggested.
A conforming CA MUST archive all issued certificates. Mechanisms to provide integrity controls other than digital signatures MAY be implemented.
Activation data (e. g. pass phrases or PINs) SHALL be selected according to ‘best practice’. Activation data for the CA's private key SHOULD be equivalent to at least 15 characters long pass phrase. End entities' private keys SHOULD be protected by activation data equivalent to a pass phrase of at least 12 characters.
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.
In order to prevent network attacks, the cryptographic module used for CA operations MUST either
be installed on an off-line machine, or
comply with the FIPS 140-1 standard at level 3.