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.
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.
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 rfc822Name
s in the
addr-spec
format, as defined in RFC 822.
DNS names MUST be included in the subjectAltName extension as
dNSName
s in the ‘preferred name syntax’,
as defined by RFC 1034.
IP addresses MUST be included in the subjectAltName extensions as
iPAddress
es in ‘network byte order’, as
specified in RFC 791 (IPv4) and RFC 1883 (IPv6) .
URIs MUST be included in the subjectAltName extensions as
uniformResourceIdentifier
s. 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.
Every name assigned by a conforming CA SHALL be associated with exactly one entity.
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.
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.
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.
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.
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.
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.