Certificate Life Cycle Management

Introduction to Certificate Life Cycle Management

Life cycle management, in the context of PKI, is the process by which entities and certificates are managed from creation ,revocation, re-issuance, revocation and deletion. Simply stated, the life of an end entity or certificate should be managed from inception through archival or purging from your PKI infrastructure. These functions are easily performed in the administrative web interface or from the command line interface ( CLI ).

The following covers managing an end entity through its life cycle from the CLI.

Entity Issuance and Maintenance

During the life cycle of an end entity or certificate there are several required tasks and other tasks which are specific to certain situations. For instance, when creating an end entity several steps must be employed and are required for the creation of the end entity. However, once an end entity is created, you are not required to verify it, create certificates for it, nor revoke or re-issue it. These tasks will be situation specific.

Creation of Entity and Certificates

Creating an end entity and its associated certificates is the main function of a certificate authority. An administrator must be aware that issuance of an endentity in no way attests to the identity of that end entity. The function of verifying an end entity’s identity (whether an individual or a piece of equipment) should be performed prior to allowing issuance of the end entity or any associated certificates and is usually performed by some external function that is interfaced into the registration authority. For instance, when issuing an end entity to a user for authentication an administrator should take either physical or digital precautions to ensure the identity of that user prior to providing the user with an end entity and the associated certificates. This can be done in a myriad of ways depending on the requirements of your organisation.

Verification

Once an end entity or certificate is issued, administrators can verify the information related to that end entity or certificate prior to delivering them to the end entity for use. While this is an optional step, it is recommended during initial testing and deployment to ensure proper configuration of end entity profiles and other operational functions, via a quick command line verification of the information being issued.

Revocation, Re-issuance, Un-Revoke

Situation specific revocation, re-issuance, revocation and un-revoking an end entity is per-formed by an administrator or an automated process as a reaction or proactionto an event. For instance, if an employee of an organisation goes on an extended leave, the administrator can revoke the certificate with a status of ’On Hold’ essentially suspending the certificate which can then be un-revoked when the employee returns. Re-issuance and un-revoking are two entirely separate and distinct tasks. Re-issuance is the process in which new keys and certificates are generated for a specific end entity. Un-revoke is used for one task only to restore a certificate that has been put in an On Hold status during revocation. Lastly, revocation is used to deactivate a certificate’s usefulness, making it invalid for its intended or other uses. Revoking a certificate does not delete the certificate, it simply invalidates it.

Deletion of an End Entity

Deletion of an end entity sounds like a simple enough task of removing that entity from the PKI infrastructure, but this must be done with extreme care. In many situations the PKI infrastructure is being used for authentication, digital signing or other tasks that have legal implications. Maintaining the end entity and its associated audit trail of PKI activity is commonly desirable. It is better practice to use revocation to suspend or remove rights than to simply delete an end entity because you will retain the entity, its audit trail and other essential data that may be required for compliance or legal reasons.

Certification Authorities

Certificate authorities are often organized in a hierarchic model, similar to a business organisational chart. A root CA is the top level CA. This Ca can be used to issue all end entity certificates or issue an Intermediate CA that will issue all end entity certificates. If the root CA’s keys become compromised, all of the certificates issued become invalid. Therefore, protecting the root CA’s keys is highly crucial. Intermediate CAs are CAs issued and signed by the root CA. These CAs will issue the end entity certificates. The main purpose for this separation is to physically and digitally protect the root CA’s keys by taking it offline and off the network. If an intermediate CA is compromised it can be resigned without affecting the entire infrastructure.

Types of Certification Authorities

Certification authorities(CAs) can be classified using various taxonomies. The primary of these is by hierarchy. Using this classification, certification authorities can be classified as the following:

Root CA

These CAs are self signed and usually offline. As there is no CA above these CAs, they are based on the notion of self trust. The root CA is the pen ultimate trust entity and hence trusts itself.

Subordinate CA

A subordinate CA (sub CA) is an entity that is trusted by the root. A sub CA is usually created for organisational, functional, security or other commercial and non commercial reasons. While it may be functionally possible to issue all possible certificates from a single CA, this may not be desirable for security and organisational reasons. For examples, a Qualified CA(QC) is one that issues certificates for digital signatures that have the equivalence of normal digitally binding signatures. The compliance requirements of these certification authorities require that a dedicated CA be used for issuing qualified certificates. Sub CAs may be created on a functional basis. For example:

  • Authentication CA
  • Signing CA
  • Encryption CA

Alternatively, sub CAs may be created on an organisational basis:

  • Human resources CA
  • Finance CA
  • Document Verifier CA

Sub CAs can also be created in a hybrid fashion:

  • Finance Signing CA
  • Finance Authentication CA

Electronic travel documents have a clearly documented acceptable hierarchy. The ICAO standard for travel documents stipulates the following hierarchy:

  • Country Signing Certification Authority (CSCA) that issues Document Signer Certificates

For second generation electronic documents, the following certification authority hierarchy applies:

  • Country Verifier Certification Authority(CVCA)
  • Document Verifier Certification Authority (DVCA)

Certification authorities can also be classified based on the format of certificates issued:

  • X.509 CA based on the X.509standard
  • CVC CA based on the card verifiable standards