3. IDENTIFICATION AND AUTHENTICATION

3.1. Initial Registration

3.1.1. Types of names

A conforming CA assigns each entity a X.501 Distinguished Name (DN, see X.501) which serves as a unique identifier of the entity. The DN is inserted in the subject field of the certificate(s) issued to the entity to bind the entity to the certificate(s). The DN MUST be a non-empty printableString.

The certificate DN SHOULD be constructed using following naming attributes:

3.1.1.1. organizationName (O)

Necessity. Mandatory.

For personal certificates, this is the official name of the institution the subscriber is affiliated with. For server certificates, it is the official name of the institution operating the server.

3.1.1.2. commonName (CN)

Necessity. Mandatory.

For personal certificates, this is the full name of the person as stated in the proof-of identity documents, with any diacritical marks removed.

For server certificates, it is the fully qualified domain name of the server prefixed by the string "host/". E.g. CN for server server.cesnet.cz will be host/server.cesnet.cz.

3.1.2. Need for names to be meaningful

A conforming SHALL be able to identify the entities associated with subject and issuer names contained in the certificates.

3.1.3. Rules for interpreting various name forms

All end entity certificates issued under this CP SHALL start with invariable part identifying the CA (e.g. O=CESNET or C=CZ,O=CA Name). The variable part following consists of the RDN indicating the organization which the subscriber is affiliated to (O=name of the organization, see Section 3.1.1.1) followed by the subscriber's common name (CN=subscriber's name, see Section 3.1.1.2).

3.1.4. Uniqueness of names

Every name assigned by a conforming CA SHALL be associated with exactly one entity.

3.1.7. Method to prove possession of private key

The requester is required to prove possession of the private key which corresponds to the public key in the certificate request before signing.

The method used to prove possession of private key MUST be detailed in the CPS.

3.1.8. Authentication of organization identity

All certificates issued under this CP include the name of a certain organization. The subscriber MUST provide a written statement of affiliation signed by the representatives of the organization.

3.1.9. Authentication of individual identity

The RA MUST personally authenticate any requester asking a personal certificate, using officially recognized identity card containing a photograph.

If the entity to be certified is a software or hardware component the requester MUST prove that he has the necessary authorization.

3.2. Routine Rekey

After certificate expiration, the CA MUST NOT issue a new certificate for the same key. The CA MAY issue a new certificate for a new key. The rekey authentication MAY be accomplished with the same procedure indicated in Section 3.1 for initial registration or using requests digitally signed with the old certificate. These requests MUST be sent to the CA before the old certificate expiration.

3.3. Rekey after Revocation

A public key whose certificate has been revoked for private key compromise MUST NOT be re-certified. The public key MAY be re-certified if the revocation is only due to certificate suspension. In the latter case the rekey authentication MAY be accomplished with the same procedure indicated in Section 3.1 for initial registration or using digitally signed requests. These requests MUST be sent to the CA before certificate expiration.

3.4. Revocation Request

A proper authentication method is required in order to accept revocation request. The CA MUST accept as a revocation request a message digitally signed with a not expired and not previously revoked certificate issued under this policy. The same procedures adopted for the authentication during initial registration are also considered suitable. Alternative procedures MAY be supported such as secure communication of a revocation passphrases.

The exact procedures supported MUST be detailed in the CPS.