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.

Subscribers MAY request including other types of names in their certificates, such as email addresses, DNS host names, IP addresses, or URIs. These names are included in the subjectAltName certificate extension in accordance with RFC 3280.

3.1.2. Need for names to be meaningful

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

Alternative names' syntax SHOULD be validated and their connection to the subscriber verified using procedures described in the CPS.

3.1.3. Rules for interpreting various name forms

The Subject CN attribute of personal certificates SHOULD contain the full name of the subscriber. For server certificates, it SHOULD contain the fully qualified domain name of the server.

Internet email addresses MUST be included in the subjectAltName extension as rfc822Names in the addr-spec format, as defined in RFC 822.

DNS names MUST be included in the subjectAltName extension as dNSNames in the ‘preferred name syntax’, as defined by RFC 1034.

IP addresses MUST be included in the subjectAltName extensions as iPAddresses in ‘network byte order’, as specified in RFC 791 (IPv4) and RFC 1883 (IPv6) .

URIs MUST be included in the subjectAltName extensions as uniformResourceIdentifiers. The name MUST NOT be a relative URL, and it MUST follow the URL syntax and encoding rules specified in RFC 1738. The name MUST include both a scheme and a scheme-specific-part. The scheme-specific-part MUST include a fully qualified domain name or IP address as the host.

3.1.4. Uniqueness of names

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

3.1.5. Name claim dispute resolution procedure

No stipulation.

3.1.6. Recognition, authentication and role of trademarks

No stipulation.

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

When a subscriber requires the inclusion of the name of a certain organization into a certificate he or she MUST provide an evidence that the organization has completely knowledge about this fact.

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 pass phrases.

The exact procedures supported MUST be detailed in the CPS.