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.
All end entity DNs in certificates issued under this CPS SHALL
start with invariable part identifying the CA
(dc=cesnet,dc=cz). The following variable part can
consists of the optional RDN indicating the organization which the
subscriber is affiliated to (O=name of the
organization, see Organization), followed by
an optional RDN indicating the organizational unit which the subscriber
is affiliated to (OU=name of the
organization unit), followed by the end entity's common name
(CN=end entity's name, see
Common name). The structure of the variable part of
the DN MAY be defined or restricted by the relevant CP.
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 conforms to RFC 3280.
Following naming attributes MAY be used in end 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.
| Attribute name | C |
| OID | 2.5.4.6 |
| 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. CESNET CA requires a proper evidence of the relation. |
| Attribute name | L |
| OID | 2.5.4.7 |
| 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. CESNET CA requires a proper evidence of the relation. |
| Attribute name | CN |
| OID | 2.5.4.3 |
| Necessity | Mandatory. |
| Comments | For personal certificates, this attribute SHOULD contain subscriber's first name followed optionally by initials followed by surname. CESNET CA MUST verify the personal names comparing them with an official id document. For server certificates, it SHOULD contain the fully qualified domain name of the server. |
| Attribute name | O |
| OID | 2.5.4.10 |
| Necessity | Optional. |
| Comments | 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. In both cases CESNET CA requires an evidence of the affiliation. |
| Attribute name | OU |
| OID | 2.5.6.5 |
| Necessity | Optional. |
| Comments | For personal certificates, this is the official name of the organizational unit or department the subscriber is affiliated with. For server certificates, it is the official name of the organizational unit or department operating the server. In both cases CESNET CA requires an evidence of the affiliation. |
In addition to names used to construct the
Subject field of the certificate, other names, as
specified in Section 4.2.1.7 of RFC 3280, are
recognized by CESNET CA and MAY be included in the certificate upon
subscriber's request. These include:
| Included as | subjectAltName extension |
| type | rfc822Name |
| Necessity | Optional. |
| Comments | Email address(es) in the addr-spec format,
as defined in RFC 822 provided by the
subscriber. The functionality of all email addresses MUST be
checked by sending a unique email challenge message to which the
subscriber must respond. |
| Included as | subjectAltName extension |
| type | dNSName |
| Necessity | Optional. |
| Comments | DNS name(s) in the “preferred name syntax”, as defined by RFC 1034 provided by the subscriber. The CESNET CA MUST be presented a signed statement of the DNS name(s) holder claiming its rights to use the name(s) and delegating the right to use the name in a certificate to the subscriber. |
| Included as | subjectAltName extension |
| type | iPAddress |
| Necessity | Optional. |
| Comments | IP address as in “network byte order”, as specified in RFC 791 (IPv4) or RFC 1883 (IPv6) provided by the subscriber. The CESNET CA MUST be presented a signed statement of the IP address holder claiming its rights to use the address and delegating the right to use the address in a certificate to the subscriber. |
Other names defined in in Section 4.2.1.7 of RFC 3280 MAY be used in full conformance with the standard.
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 CN DN attribute SHOULD contain the legal name as presented in a government issued photo-identification.
For server certificates, the CN DN attribute SHOULD contain the fully qualified domain name of the server.
See Section 3.1.1 and Section 3.1.2.
The CESNET CA guarantees the uniqueness of the subject names. In case of name collision when more than one person use the same name, a random string is appended to the CN to make the name unique.
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.
When obtaining a personal or individual certificate is initiated by a key generation tag or control which the individual's web browser reads on the CA's user registration web page. Key generation and certificate signing request generation and submission are tied together in a single session, and there is a reasonable presumption of possession of private key in requests originating in web browser functions.
For signature keys not generated in a single certificate certificate issuing HTTPS session, 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 not generated in a single certificate certificate issuing HTTPS session , 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.
When the initial identification is performed by an RA representing the organization the name of which is requested to be included in the certificate, the RA MUST validate the request according to the rules defined by the organization and described in its CPS.
When the RA performing the initial identification is not itself affiliated with organization the name of which is requested to be included in the certificate, it MUST require written legally binding documents as evidence. 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 or by the organization operating the RA is accepted for authentication. The relevant CP MAY specify other acceptable identity documents.
The requester asking for a certificate for a server or 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, the new affiliation verification procedure as described in Section 3.1.8 MUST be performed 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.