Part of the certificate lifecycle is the revocation of certificates. Revocation or deletion of certificates, prior to their expiration date, is necessary for a number of reasons: if a certificate is compromised, if user privileges change, if there is a cease of operations, among other reasons. A certificate authority manages this process through certificate revocation lists, commonly known as CRLs. A CRL contains information about the associated certificate that needs to be removed. An administrator must then regularly manage, review, and enforce the revocation of certificates on this list, to maintain a secure and up-to-date certificate environment.
A common alternative to manually reviewing CRLs is through the Online Certificate Status Protocol (OSCP). OSCP is a web-based protocol, typically used over HTTP, which helps to manage CRLs and revoke private keys and certificates in real time. OCSP addresses latency issues associated with the traditional issuing and processing of CRLs. CRLs require administrators to manually check certificates and private keys for revocation. For example, if an employee quits and needs their private keys to be invalidated, their private key would remain in place until the pre-scheduled time that the CRL is pulled and processed by an administrator. OSCP however, operates through HTTP allowing CRLs to be pulled almost instantaneously with the entire revocation process completed with almost immediate effect (or at least much quicker than traditional CRLs). OCSP responses contain less data than the typical CRL, meaning there is less data to parse through and the request can be processed much quicker because of this. Futurex’s enterprise CA offering integrates with this protocol, offering customers essential security, ease of use, and agility in their enterprise CA environment.
OSCP must communicate with a 3rd party to confirm certificate validity and unfortunately this can leave organizations exposed to attack or interference. If the OCSP server is not cryptographically protected there is no way to ensure that the HTTP server key is compromised, leaving organizations vulnerable to replay/playback attacks or other interference by malicious outside parties. Managing this process through the KMES Series 3 eliminates this concern, because instead of communicating with a 3rd party, certificate validation and processing occurs within the cryptographic boundary of the HSM.
