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.
The entity MUST generate his own key pair.
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.
No stipulation.
No stipulation.
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:
digitalSignature
nonRepudiation
keyCertSign
cRLSign
It MAY contain also other bits set to one.
In personal (user) certificates the keyUsage extension SHOULD contain the following bits set to one:
digitalSignature
keyEncipherment
nonReputiation
dataEncipherment
In server (application, service) certificates the keyUsage extension SHOULD contain the following bits set to one:
digitalSignature
nonReputiation
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.
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.
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 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.
The private key of all entities SHOULD be stored in an encrypted form. This provision is particularly important if the entity is a CA.
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.
No stipulation.
No stipulation.
A conforming CA MUST archive all issued certificates. Mechanisms to provide integrity controls other than digital signatures MAY be implemented.
The validity period of a conforming CA's key pair MUST NOT extend 5 years.
The validity period of an end entity key pair MUST NOT extend one year.
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.
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.
No stipulation
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
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.
No stipulation.