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.
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.
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
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.
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.
A conforming CA MUST decide what is the amount of time necessary to accept the request and make the information available in its CPS.
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.
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.
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.
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.
Relying party MUST verify a certificate against the most recent CRL issued from conforming CA in order to validate the use of the certificate.
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.
This policy recognizes the importance of security audit procedures suggesting that a conforming CA specifies all this kind of provisions in the CPS.
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.
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
all relevant messages exchanged with subscribers
The conforming 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 CA's keys:
A new 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.
If a CA s private key is compromised or suspected to be compromised, the CA SHALL at least:
inform subscribers, cross-certifying CAs and relying parties
terminate the certificates and CRLs distribution service for certificates/CRLs issued using the compromised private key
request the revocation of the CA's certificate
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.
A conforming CA SHOULD recover its operation from backups as soon as possible.
Termination of a CA is regarded as the situation where all services associated with a logical CA are terminated permanently.
Before the CA terminates its services the following procedures MUST be completed as a minimum:
inform all subscribers, cross certifying CAs, higher level CAs, and relying parties with which the CA has agreements or other form of established relations,
make publicly available information of its termination,
stop distributing certificates and CRLs.
A subordinate CA MAY terminate or continue operation as a self-standing CA.