4. OPERATIONAL REQUIREMENTS

4.1. Certificate Application

An entity generates its own key pair and submit public key and other required data to the CA. After that the request MUST carefully follow the procedures detailed in this policy and in the CPS for identification and authentication.

4.2. Certificate Issuance

The CA and RA MUST carefully check the compliance and validity of documents presented by the subscribers. After the authentication accomplished by methods specified in Section 3.1, the CA SHOULD issue the certificate. In the case of issuance the CA MUST notify the requester. If for any reasons the CA decides not to issue the certificate (even if the checks and the authentication were correct) it SHOULD notify the reason for this choice to the requester.

4.3. Certificate Acceptance

No stipulation.

4.4. Certificate Suspension and Revocation

4.4.1. Circumstances for revocation

A certificate SHALL be revoked when information in the certificate is known to be suspected or compromised. This include situations where:

  • the subscriber's data changed

  • the subscriber's private key is compromised or is suspected to have been compromised or lost

  • the subscriber's information in the certificate is suspected to be inaccurate

  • the subscriber is known to have violated his obligations

4.4.2. Who can request revocation

The CA MUST accept a revocation request made by the holder of the certificate to be revoked. Moreover the revocation request MAY come from the CA that issued the certificate or from associated RA.

Other entities MAY require revocation, presenting evident proof of knowledge of the private key compromise or the change of subscriber's data.

4.4.3. Procedure for revocation request

The entity requesting the revocation SHALL be properly authenticated. The authentication method SHOULD be as strong as the one used in the issuing procedure. Conforming CA MUST accept as a revocation request a message digitally signed with a not expired and not previously revoked certificate issued under this policy. An alternative procedure MAY require the entity to visit RA or CA and to present a viable identity document.

If the entity is a CA, the CA SHALL in addition:

  • Inform subscribers and cross-certifying CAs

  • Terminate the certificate and CRLs distribution service for certificates/CRLs issued using the compromised private key.

4.4.4. Revocation request grace period

The conforming CA decides what is the amount of time necessary to accept the request.

4.4.5. Circumstances for suspension

A CA MAY temporarily suspend a subscriber s certificate if the subscriber requests that service. Unlike revocation, suspension of a user allows for re-enabling at a later time. In every case conforming CA are not required to offer the suspension service. Information on public keys of disabled users MAY be available from CA repository.

4.4.6. Who can request suspension

In the case that a CA offers the suspension service, CA MUST accept a suspension request made by the holder of the certificate to be suspended.

4.4.7. Procedure for suspension request

The entity requesting the suspension SHALL be properly authenticated. A conforming CA MUST accept as a suspension request a message digitally signed with a not expired and not previously revoked certificate issued under this policy . An alternative procedure MAY require the entity to visit RA or CA and to present a viable identity document.

4.4.9. CRL issuance frequency (if applicable)

CRL lifetime MUST be at least 7 days and MUST NOT be longer than 30 days. CRLs MUST be reissued at least 7 days before expiration, even if no additional revocations have occurred.

4.4.10. CRL checking requirements

Relying party MUST verify a certificate against the most recent CRL issued from conforming CA in order to validate the use of the certificate.

4.4.11. On-line revocation/status checking availability

A conforming CA MAY support on-line revocation/status checking. Bearing in mind that this policy requires conforming CA to issue CRL, it is not mandatory to implement on-line revocation/status checking procedures. However this policy suggests taking into consideration OCSP RFC 2560 as such a mechanism.

4.5. Security Audit Procedures

This policy recognizes the importance of security audit procedures suggesting that a conforming CA specifies all this kind of provisions in the CPS.

4.6. Records Archival

This section specifies the type of events that are recorded for archival purposes from CA and RA and how this collected data are maintained. For further details not explicitly stipulated here the reference is the CPS.

4.6.1. Types of event recorded

A conforming CA SHOULD archive:

  • certification requests corresponding to actually issued certificates

  • issued certificates

  • issued CRLs

  • all signed agreements with other parties (e.g. RA)

  • documents collected from the subscriber during the enrollment procedure

  • all relevant messages exchanged with RA

The RAs SHOULD archive:

  • all validation information collected from the subscriber

  • all relevant messages exchanged with CA

4.6.2. Retention period for archive

The minimum retention period is 2 years.

4.7. Key changeover

No stipulation.

4.8. Compromise and Disaster Recovery

If a CA s private key is compromised or suspected to be compromised, the CA SHALL at least:

If a RA s private key is compromised or suspected to be compromised, the RA SHALL at least inform the CA and request the revocation of the RA's certificate

If an entity s private key is compromised or suspected to be compromised, the entity SHALL at least inform the relying parties and request the revocation of the entity's certificate.

4.9. CA Termination

Termination of a CA is regarded as the situation where all service associated with a logical CA is terminated permanently.

Before the CA terminates its services the following procedures MUST be completed as a minimum:

A subordinate CA MAY terminate or continue operation as a self-standing CA.