The CESNET 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 naming attributes of the subscriber to be requested to identify and authenticate the requester depend on the type of certificate that the subscriber requires. The choice of the types and format of names used in the fields of the certificate is conforming to RFC 2459.
Following naming attributes MAY be used in entities' Distinguished Names. In the case where the applicable CP states the rules for constructing the DN, the rules required by the CP take precedence over this CPS.
Necessity. Optional.
Comments. For personal certificates, this is the country of residence of the subscriber. For server certificates, it is the country where the server is located.
Necessity. Optional.
Comments. For personal certificates, this is the locality of residence of the subscriber. For server certificates, it is the locality where the server is located.
Necessity. Mandatory.
Comments. For personal certificates, this is the first name followed optionally by initials followed by surname. For server certificates, it is the fully qualified domain name of the server.
Necessity. Optional.
Comments. For personal certificates, this is the official name of the institution employing the subscriber. For server certificates, it is the official name of the institution operating the server.
Necessity. Optional.
Comments. For personal certificates, this is the official name of the organizational unit or department in which the subscriber works. For server certificates, it is the official name of the organizational unit or department running the server.
The Subject and Issuer names contained in a certificate MUST be meaningful in the sense that the issuing CA has proper evidence of the existent association between these names and the entities to which they belong.
For Personal Certificates, the Common Name DN attribute contains the legal name as presented in government issued photo-identification.
For Server Certificates, the Common Name DN attribute contains the fully qualified domain name of the server.
The CESNET CA guarantees the uniqueness of the subject names.
Name disputes are managed according to the law of the Czech Republic.
The CESNET CA does not guarantee that the names issued will contain the requested trademarks.
The requester is required to prove possession of the private key which corresponds to the public key in the certificate request before signing.
For signature keys, this is done by the requester using its private key to sign a value and providing that value to the RA. The RA SHALL then validate the signature using the public key from the subscriber's certificate request.
For encryption keys, the requester is asked to decrypt a random challenge encrypted with the public key contained in the certificate request.
In case that the validation fails, the certificate MUST NOT be issued.
Every time a subscriber requires the inclusion of the name of a certain organization in a certificate, issuing CA MUST have evidence that the organization has completely knowledge about this fact. In order to obtain this result the CA MUST require written legally binding documents. In all cases suitable legal documents that prove the data to be certified MUST be presented by means of out-of-band methods.
The procedures of initial authentication of individual identity MUST comply with the CP applicable to the certificates.
In case where the CP requires personal photo-id authentication, the RA MUST meet the holder in person to compare the photograph and register the number of the identification document. Any identity card issued by government is accepted for authentication. The relevant CP MAY specify other acceptable identity documents.
The requester asking for a certificate for a software component MUST prove that he has the necessary authorization by providing a signed statement made by the representatives of the organization operating the software. The statement MAY be in electronic form in which case it MUST be digitally signed by a valid certificate issued by the CESNET CA.
The identification and authentication for routine rekey may be accomplished either with the same procedure as for Section 3.1 or using digitally signed requests sent to the CA before certificate expiration.
In case where the certificate to be reissued contains the name of a certain organization, new legal documents as indicated in Section 3.1.8 must be presented before rekeying.
A rekey after a revocation without a key compromise is handled as a routine rekey (see Section 3.2).
A public key whose certificate has been revoked for private key compromise MUST NOT be re-certified.
Revocation requests are authenticated either by procedures described in Section 3.1.9 or by verifying the digital signature of the revocation request made by a valid certificate under the corresponding CP.