Entrust PKI as a Service

Certificate life-cycle operational requirements

See below for the certificate life-cycle operational requirements.

Certificate application

Applicants submit requests for certificates issued under this CPS through electronic means.

  • Who Can Submit a Certificate Application: Applications for Certificates are submitted via authenticated API request from an RA. Each RA receives unique authentication credentials.

  • Enrollment process and responsibilities:

    • The enrollment process includes authentication of the API requests and validation of the certificate request contents.
    • PKIaaS authenticates and protects from modification all communications among PKI components (such as CAs or RAs) supporting the Certificate application and issuance process. PKIaaS encrypts and digitally signs Electronic communication between the Customer or RA enrollment environments, automated RA applications, and the CAs.

Certificate application processing

Certificate application processing follows the life-cycle outlined below.

  • Performing identification and authentication functions:

    • The CA performs verification of the RA by checking that the credentials supplied in the API request entitle the RA to issue certificates for the designated CA and that the designated CA has license capacity.

    • The RA will identify and authenticate the Subscriber.

  • Approval or rejection of certificate applications: PKIaaS approves a Certificate Application after validating all of the following conditions.

    • The request contains valid syntax
    • Proof‑of‑possession verification succeeds
    • The customer holds available Certificate inventory to consume

  • Time to process certificate applications: The RA holds responsibility for Certificate Application processing. The CA will respond to API requests with a Certificate or with an error indicating why the Certificate failed to issue.

Certificate issuance

After verifying the information provided with a Certificate Application, an RA operating under a CA may request that a CA issue a Certificate.

  • CA actions during certificate issuance: Upon receiving the issuance API request, the CA verifies the integrity of the information in the Certificate request, builds and signs a Certificate, and returns the Certificate in the API response to the API requester (RA). The CA will not issue any Certificates with validity period that exceeds the validity period of the corresponding Issuing CA Certificate.

  • Notification to subscriber by the ca of issuance of certificate: The RA holds responsibility for notifying the Subscriber.

Certificate acceptance

Certificate acceptance processing follows the life-cycle outlined below.

  • Conduct constituting certificate acceptance: No stipulation.
  • Publication of the certificate by the CA: The CA will provide the Certificate to the RA through an API response.
  • Notification of certificate issuance by the CA to other entities: The CA does not provide notification of Certificate issuance to other entities.

Key pair and certificate usage

See below for the practice statement on key pair and certificate usage.

  • Subscriber private key and certificate usage: The Customer holds responsibility for the use of Subscriber Private Keys and Certificates.
  • Relying party public key and certificate usage: PKIaaS provides Certificate status in accordance with this CPS. This CPS does not cover Relying Party Public key and Certificate usage.

Certificate renewal

See below for the practice statement on certificate renewal.

  • Circumstance for certificate renewal: Responsibility of the RA.
  • Who may request renewal: Responsibility of the RA.
  • Processing certificate renewal requests: PKIaaS processes Certificate renewal as Certificate issuance.
  • Notification of new certificate issuance to subscriber: The RA holds responsibility for notifying the Subscriber.
  • Conduct constituting acceptance of a renewal certificate: No stipulation.
  • Publication of the renewal certificate by the CA: The CA will provide the Certificate to the RA through an API response.
  • Notification of certificate issuance by the CA to other entities: The CA does not provide notification of Certificate issuance to other entities.

Certificate re-keying

See below for the practice statement in certificate re-keying.

  • Circumstance for certificate re-keying: A Subscriber should request a Certificate with a new Public Key for a Private Key compromised or at the end of the Key Pair lifecycle.
  • Who may request certification of a new public key: Responsibility of the RA.
  • Processing certificate re-keying requests: PKIaaS processes Certificate re-keying as Certificate issuance.
  • Notification of new certificate issuance to subscriber: Notification to Subscriber is the responsibility of the RA.
  • Conduct constituting acceptance of a re-keyed certificate: No stipulation.
  • Publication of the rey-keyed certificate by the CA: The CA will provide the Certificate to the RA through an API response.
  • Notification of certificate issuance by the ca to other entities: The CA does not provide notification of Certificate issuance to other entities.

Certificate modification

PKIaaS processes Certificate modification as issuance. The RA holds responsibility for submitting the modified CSR and revoking the replaced certificate.

Certificate revocation and suspension

The CA will revoke a Certificate after receiving a valid revocation request from an RA operating under such CA.

  • Circumstances for CA certificates revocation: Revocation of CA Certificates may be performed by Entrust in the following circumstances.

    • The RA requests for an Issuing Certificate to be revoked;
    • The RA can be shown to have violated, or appears to have violate, the requirements of this CPS or the Agreement;
    • Suspected compromise of the associated private key; or
    • Termination of the Agreement with Entrust.

  • Circumstances for CA subscribe revocation: The RA requests for a Subscriber Certificate to be revoked.

  • Who can request revocation of a certificate: The RA may request revocation of any Certificates issued. The RA holds responsibility for handing Subscriber requests for Certificate revocation.

  • Procedure for revocation request:

    • The RA shall request revocation of their Issuing CA Certificate, or of an individual Subscriber Certificate if the RA has a suspicion or knowledge of or a reasonable basis for believing that of any of the following events have occurred:

      1. Compromise of the Certificates Private Key;
      2. Knowledge that the original Certificate request was not authorized

    • The RA shall submit revocation requests to the CA via authenticated API.

  • Certificate revocation grace period: CAs to not apply any grace period. PKIaaS processes revocation requests synchronously, in sequence with the API request and response.

  • Time within which ca must process the revocation request: CAs will revoke Certificates upon receipt of a proper revocation request.

  • Revocation checking requirement for relying parties: Relying Parties should implement revocation checking. Each Relying Party must determine how often new revocation data should be obtained, considering the risk, responsibility, and consequences for using a Certificate whose revocation status cannot be guaranteed.

  • Revocation lists issuance frequency:

    • PKIaaS generates CRLs every 24 hours.
    • CRLs remain valid for 7 days.
    • The revocation request of a certificate can set an instant CRL update flag. In this case, PKIaaS will generate a new CRL containing the revoked certificate in the requests as soon as possible, depending on the service load. In a normal load the CRL will be generated in less than 15 minutes.

  • Maximum latency for CRLs: CRLs are available within seconds of issuance. PKIaaS does not impose delays between the issuance and publication of CRLs for caching or any other purpose.

  • On-line revocation and status checking availability On-line revocation/status checking of Certificates is available on a continuous basis by CRL and optionally OCSP.

  • On-line revocation checking requirements: CAs support an OCSP capability using the GET and POST methods for Certificates issued in accordance with this CPS.

    • The CAs shall sign and make available OCSP as follows:

      1. OCSP responses for Issuing CA Certificates are issued upon request.
      2. OCSP responses for Subscriber Certificates are issued upon request.

    • If the OCSP responder receives a request for status of a Certificate serial number that is “unused”, then the responder will not respond with a “good” status.

    • The on-line locations of the CRL and the OCSP response are included in the Certificate to support software applications that perform automatic Certificate status checking.

  • Other forms of revocation advertisements available: The CA does not provide any other forms of Certificate status.

  • Key compromise If an RA suspects, knows, or is informed of Private Key compromise, then the RA is required to take necessary steps to revoke the Certificate, immediately stop using such Certificate, and remove such Certificate from any devices and/or software in which such Certificate has been installed.

  • Circumstances for suspension: Suspension of Certificates is to be performed when the RA requests for a Certificate to be suspended.

  • Who can request suspension: The RA may request suspension of any Certificates issued. It is the responsibility of the RA to handle requests for Certificate suspension.

  • Procedure for suspension request: The RA shall submit suspension requests to the CA via authenticated API.

  • Limits on suspension period: There is no time limit on suspension.

Certificate status services

See below for the practice statement on certificate status service.

  • Operational Characteristics: Revocation entries on a CRL or OCSP response are not removed until after the expiry date of the revoked Certificate.
  • Service Availability: The CA operates and maintains its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions. Certificate status services are available on a continuous basis.
  • Optional Features: No stipulation.

End of subscription

End of subscription is addressed in the Agreement.

Key Escrow and Recovery

CA and Subscriber key escrow are not supported. Subscriber key recovery is not supported.

  • Key escrow and recovery policy and practices: CA Keys can be recovered from a database and HSM backup.
  • Session key encapsulation and recovery policy and practices: No stipulation.