In order to apply for a certificate, the following steps need to be undertaken:
A requester generates its own key pair and submits the public key and other required data to the RA. (See Section 6.1.1 and Section 6.1.3).
In order to issue a certificate, the following steps need to be undertaken:
RA verifies whether the requester qualifies for the certificate.
RA verifies the identity of the requester as indicated in Section 3.1.
RA validates the prove of possession of private key using procedures indicated in Section 3.1.7.
When the certificate request does not contain an email address, RA registers the email address to which the subscriber wants the certificate issuance notification to be sent.
RA sends the digitally signed certificate request to the CA.
On receipt of a certificate request, the CA will verify the RA's signature and issue a certificate.
The requester is notified via email to the address included in the certificate or to the address registered by the RA.
The certificate is assumed to be accepted unless its requester explicitly rejects it in an authenticated communication with the CA.
A certificate will be revoked when the information in the certificate is known to be suspected or compromised or at the request of the authorized entity. It includes following situations:
The associated private key is known to be compromised or misused.
The associated private key is suspected to be compromised or misused.
The subscriber's information in the certificate has changed.
The subscriber is known to have violated his obligations.
The authenticated requester requested the certificate revocation.
The following entities can request the revocation of a certificate:
The entity who originally made the certificate request.
The entity which can prove its current responsibility for a certified machine or service.
Any entity which demonstrates the compromise or misuse of a certificate.
Any entity which demonstrates the change of subscriber's data.
The issuing CA or the associated RA.
In case where the CA can independently confirm that the certificate has been compromised or misused, the CA SHALL revoke the certificate, even if the request to do so comes from an unauthenticated source and/or the holder of the certificate is unreachable.
In all other cases the CA SHALL authenticate the revocation request and try to contact the subscriber before revoking the certificate. If the subscriber is temporarily unreachable, the certificate SHALL be suspended.
If the revoked certificate is a CA certificate the CA SHALL in addition inform the subscribers and cross-certifying CAs and it SHALL terminate the certificate and CRLs distribution service for certificates/CRLs issued using the compromised private key.
The CESNET CA MUST respond within two days (excluding weekends and public holidays) to revocation requests. It SHALL however handle revocation requests with priority as soon as the request is recognized as such.
The CESNET CA will suspend a certificate only while there is uncertainty over its current status:
At the request of the subscriber or the CA or RA that requested issuing of the certificate.
If a revocation request for the certificate is on hold pending contact with the holder.
A certificate suspension can be requested only by the subscriber or by the CA or RA that requested its issuing.
Suspension request are accepted only when properly authenticated either by a message digitally signed with a valid certificate or by procedures described in Section 3.1.
There are no limits on suspension period.
CRLs issued by CESNET CA are renewed whenever any certificate is revoked or when any CRLs is more than 30 days old.
The CRLs are checked at the certificate relying party responsibility. Relying parties SHALL update their local copies of CRLs at least once per day.
The on-line revocation/status checking service is not currently applicable.
Not currently applicable.
The subscriber is notified of the revocation of his certificate by email.
No stipulation
The following types of events are recorded by RAs:
Boots of the equipment.
Login and logouts to the RA system.
Account management.
Use of the RA software.
Unauthorized attempts to access the RA system.
Requests for certificates.
Identity verification procedures.
The following types of events are recorded by CAs:
Boots of the equipment.
Login and logouts to the issuing machine.
Account management.
Use of the CA software.
Unauthorized attempts to access the CA system.
Requests for certificates.
Certificate issuing.
Requests for revocation.
CRL issuing.
The log files are analyzed at least once every month.
Audit logs MUST be retained as archive records. The audit logs MUST be kept on CA equipment until moved to the archive.
Only authorized CESNET CA personnel is allowed to to view and process audit log files.
Audit log files stored on the CA equipment will not be open for modification by any human, or by any automated process other that those that perform audit and archival.
A backup of the audit logs on physical removable media SHALL be performed weekly. The backup media are saved in safe storage.
The audit collection system SHALL be running separately form the CA software.
The audit collection system is internal to the CESNET CA.
The subjects causing an audit event are not notified of the audit action.
The CESNET CA personnel MUST pay attention to any sign of an attempt to violate the integrity of the PKI system. Any deficiency MUST be followed by a vulnerability assessment revision.
The following type of events are archived:
Certificate requests and related messages exchanged between the subscriber and the RA and CA.
Issued certificates.
Revocation requests and related messages exchanged with the requester and/or the subscriber.
Issued CRLs.
Records on CA rekeying.
Records on cross certification.
All implemented CPs and CPSs.
CA system configuration files.
Audit data as described in Section 4.5.1.
Digital signature certificates, encryption private keys stored by the CESNET CA and issued CRLs SHALL be archived for at least two years after key expiration. Private signature keys SHOULD NOT be archived after key expiration.
All other archive records SHALL be archived for at least 10 years.
Digitally stored archive records are stored encrypted in two copies placed in different locations. The encryption passwords SHALL be known only to the CESNET CA personnel.
Archive records are weekly moved from the CA/RA equipment to the encrypted removable media. The copies are stored in different locations. See Section 4.6.3.
All archive records are time stamped.
The archive collection system is internal to the CESNET CA.
All the data published by CESNET CA are publicly available.
Data used to identify subscribers are only for internal CESNET CA's usage and are not available to the public.
The CESNET CA's keys SHOULD be changed while sufficient validity time remains on the existing keys to allow uninterrupted validity of all subordinate keys. The following steps SHOULD be undertaken when changing the CESNET CA's keys:
A new CESNET CA key is generated and self signed certificate issued.
The old key is signed by the new one.
The new key is signed by the old one.
All the newly issued certificates are published.
In the case where the CESNET CA computing resource, software and/or data have been corrupted, the responsible personnel SHOULD immediately start the recovery procedures:
Backup public repository and services systems are started when needed.
Users are notified.
The cause of the corruption are diagnosed.
When the extent of the corruption cannot be exactly specified, the entire system MUST be rebuilt.
The corrupted parts of the system are repaired or replaced.
The corrupted data are replaced from backups if possible.
The certificates issued after disaster are re-issued.
The system is restarted and the users are notified.
The key is revoked.
The CRL is updated and published.
The CA system is brought down.
New CA keys pair is generated as indicated in Section 6.1.
Users are notified.
Whenever the subscriber's key is compromised, the subscriber is obliged to notify CESNET CA as soon as possible. The revocation procedure will follow according to Section 3.3, Section 3.4.
In case that the CA private key is compromised, the following actions will be undertaken:
The key is revoked.
The CRL is updated and published.
The CA system is brought down.
The cause of the compromising is analyzed to minimize the risk in future.
New CA keys pair is generated as indicated in Section 6.1.
Users are notified.
In the case of a natural or other type of disaster the CESNET CA MUST start the recovery as soon as possible using off-site stored backups.
The CESNET CA can decide to transfer the PKI services to another organization. In that case it MUST inform all subscribers, cross certifying CAs, higher level CAs, and relying parties with which the CA has agreements or other form of established relations about the transfer at least 3 months before the transfer date. The new organization MUST comply with this CPS.
The CESNET CA can decide to cease its services. In that case the following steps MUST be undertaken:
The CA MUST inform all subscribers, cross certifying CA s, higher level CAs, and relying parties with which the CA has agreements or other form of established relations about the decision at least one year before the termination date.
Any certificates issued after the announcement of the termination MUST have the expiration date not exceeding the termination date.
At the termination date all the certificates issued by the CA MUST be revoked.
The CA stops distributing certificates and CRLs.