Using OCSP, LDAP & HTTP for Certificate Checking

Certificate Checking Options

When digital signature is being validated there will be a (trust) chain of certificates from the local trust anchor to the certificate of the entity being validated. A key capability of PKI certificates is that the CA may revoke them if, for example, the private key is compromised or the user is no longer valid. This means that when a digital signature is being checked, certificate validity also needs to be checked. This is particularly important for the certificate associated with the entity being validated, but should also be done for all of the other certificates in the trust chain. Various options for checking certificates are now described.

Directory

PKI is specified in X.509 and the original X.509 was closely coupled with the X.500 directory. The names of entities represented in a certificate are “Directory Names” and the model is that all entities have entries in a directory that is used in support of the PKI. In particular, there are entries for all Certification Authorities (CAs).

When a certificate is revoked, it is added to a Certificate Revocation List (CRL) which is digitally signed by the CA or by an entity authorized by the CA. This CRL is then placed into the CA’s entry in the directory. When a certificate is being checked, the Relying Party (RP), which is the entity checking the certificate, will read the CRL to see if the certificate being checked has been revoked. In a distributed environment, directory replication would ensure that the CA’s entry and the CRL are available locally to the RP.

This is a coherent model fully supported by the Isode product set.

CA-Centric Checking

The original model of PKI that relied on directory to distribute certificate revocation information evolved to enable operation without a fully interconnected “global directory”. The key change was inclusion of CRL Distribution Point (CRLDP) in a certificate, which enables the CA issuing the certificate to include information on where to obtain a CRL from. This enables a CA to publish CRLs using a choice of mechanisms which are described in subsequent sections.

A consequence of this architectural shift is that the location of certificate checking information is controlled by the CA and will generally be at a location convenient to the CA, which may not be ideal for the RP. The consequences of this are reviewed later.

LDAP

The first type of CRLDP is Lightweight Directory Access Protocol (LDAP). This is superficially similar to the directory approach. The distinction is clarified here:

• With directory based access, which is still likely to use the LDAP protocol, only the name of the directory entry is specified. This means that the RP can use a local directory server, which gives efficient high performance access. To achieve this, the local directory server needs to be connected to other directory servers participating in the PKI.
• With an LDAP CRLDP, the LDAP server is explicitly specified. This means that all RPs need to connect to the same LDAP server. In some environments this works well, but it can lead to scaling problems or performance issues when the RP is not close to the LDAP server. This can be mitigated to some extent by use of multiple LDAP CRLDP values.

A key benefit of LDAP CRLDP is that most CAs support LDAP CRL publishing, so this integrates cleanly.

HTTP

The second type of CRLDP is HTTP. Essentially, this is using a Web server to publish CRL information. Superficially, this seems similar to use of LDAP, but uses a more general protocol. It has a number of functional advantages over LDAP:

• Operational experience suggests that timeouts work better, which is important when network access is poor.
• HTTP works better than LDAP when Firewalls and other network boundaries are involved.
• In large scale deployments HTTP can feed into Content Distribution Networks (CDNs). This gives effective wide area replication of the data and mitigates the issues of central access.

OCSP

The LDAP and HTTP CRLDP mechanisms both work by sharing CRL information. There are two key problems with this:

1. CRLs can get large. This is not an issue for a server that is checking lots of certificates. However, where the RP is an end user checking the occasional certificate, retrieving the CRL can cause performance problems, particularly if the client is connected over a constrained link.
2. CRLs contain “next update” information, which enables an RP to detect if a CRL is out of date (and so a new CRL needs to be retrieved). The difficulty with this is that most RPs will use the cached CRL until “next update” time. Certificates are often revoked for reasons where quick response to the revocation is highly desirable.

OCSP (Online Certificate Status Protocol) was designed to address this, by providing a client/server protocol that enables an RP to check the status of a certificate. An OCSP server is indicated by a special certificate extension.

Problems to Solve

PKI provides a number of mechanisms to check certificate status. These all work well in some situations. We now look at some of the issues arising in more complex environments:

1. Large scale deployments with complex connectivity and large numbers of CAs and users.
2. Constrained networks, where some participants in the PKI have access through slow or otherwise disadvantaged networks.

Although some of these points are relevant to open Internet style PKI with well-known public CAs, this paper is mainly considering military and government style PKI with single trust anchor and typically complex trust chains.

Large Scale Network Problems

In a large network there will be many RPs checking certificates, so scaling of the solution to support large numbers of certificate checks is important.

• OCSP. This is limited by scaling of the OCSP server in handling OCSP requests. Because OCSP is based on HTTP, an OCSP server following RFC 5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments will enable use of Web caching. The downside is that this will cause OCSP results to be cached until “next update time”, which will remove the OCSP benefit of providing currently accurate information.
• LDAP. This is limited by scaling of the LDAP server to retrieve CRLs. If CRLs are large, this may impact scaling. Multiple CRLDP values could be used to enable multiple LDAP servers, but they are processed in order and so this only helps for reliability and does not improve scaling.
• Directory. Because the directory service may be highly replicated, replication may be used to increase scaling and to provide local access for RPs.
• HTTP. Architecturally, this has scaling similar to LDAP. In practice Web caching and use of Content Distribution Networks means that this approach scales well.

OCSP is specifically designed to ensure that certificate checking is up to date. Where an OCSP server accesses a CRL, it is clearly important that this server ensures that it always has the latest CRL. Any RP can check to see if there is a new CRL (which it can do without downloading the CRL unless it has changed), which will ensure the current revocation information is used, at the expense of increased network traffic which may impact service scaling. Where HTTP is used, caching may lead to the RP not being able to detect an update.

This trade-off of characteristics between the mechanisms means that CAs will often choose to use multiple publication mechanisms.

The M-Vault Solution

The following diagram shows how a CA would typically provide LDAP, HTTP and OCSP access for certificate checking. CAs will invariably provide a mechanism for LDAP publishing of CRLs to a directory server that provides LDAP access. Although some CAs provide an integrated OCSP server, most OCSP servers work by LDAP retrieval of CRL. HTTP publishing is usually handled by use of a standard Web server and use of custom scripts to publish the CRL.

M-Vault supports direct HTTP and OCSP access, as shown below and described in more detail in the following sections. An immediate advantage is that the number of components needed is significantly reduced.

LDAP, Replication and Publishing

M-Vault is a directory server supporting LDAP and X.500 protocols. A CA will be able to publish CRLs directly into M-Vault, which can serve LDAP and Directory CRLs.

M-Vault can support replication using X.500 DISP (the only open standard for directory replication) or synchronization with LDAP directories using Sodium Sync. This can be important for distributing CRLs in a large scale environment.

HTTP Publishing

M-Vault has built in HTTP publication of CRLs. The URL served can be configured as a directory attribute in the entry holding the CRL. The CRL can then be served over HTTP, as shown below:

HTTP/1.1 200 OK
Content-Type: application/pkix-crl
Content-Length: 538
Content-disposition: attachment; filename="foobar.crl"
Etag: "ddfa3bd3d0da544b079b581e5505a37b047371a1"
Last-Modified: Thu, 24 Oct 2013 08:34:05 GMT
Expires: Fri, 25 Oct 2013 02:33:05 GMT
Cache-Control: max-age=0
Server: M-Vault/16.1
Date: Fri, 29 Nov 2013 12:22:29 GMT
Accept-Ranges: none
Connection: close

Note that the expiry date of the HTTP response is derived from the “next update” time of the CRL. This means that conformant Web caches and Content Distribution Networks will not hold CRLs beyond this time, and so Web access should always provide a current CRL.

Although HTTP publishing is most important for CRLs, it can also be useful for path discovery when this is done without LDAP access. Path discovery is where a trust chain is built between a certificate being verified and a trust anchor. To do this, CA cross-certificates need to be examined, in order to find a trust path. With LDAP, the list of cross-certificate pairs for a CA is simply read over LDAP. The X.509 AIA mechanism enables this information to be read over HTTP. This is done by a pair of certificate lists (one for each half of the cross certificate pairs) which can be retrieved over HTTP. For many CAs, configuration of this is not straightforward. M-Vault will derive the certificate lists from the cross certificate pairs held in the directory, which makes this publication straightforward.

OCSP Publishing

OCSP is a straightforward protocol, where an RP (OCSP client) presents a certificate to be checked and the OCSP server returns a result, indicating whether or not the certificate is currently valid. The result is signed by the OCSP server, which is important for security. The client needs to trust the OCSP server, as it clearly does not make sense to use the OCSP server to check the OCSP server certificate. OCSP servers in normal mode will usually have a special certificate that is marked as an OCSP server certificate, and signed by the same CA that issued the Certificate being checked. Trusted responder mode is discussed later.

In M-Vault, multiple OCSP responders can be configured with associated private keys and certificates. An OCSP responder will usually handle a specific CRL, but can also be configured to handle multiple CRLs for trusted responder mode.

Benefits of the M-Vault Solution

The M-Vault approach which provides all of the certificate verification methods from a single server has a number of advantages:

1. It reduces the number of components needed for a deployment, which will lead to increased resilience and reduced management cost.
2. For HTTP CRLDPs it can often remove the needs for custom scripting needed to publish.
3. It simplifies HTTP publication of cross-certificate pairs.
4. Because OCSP and HTTP work directly off the CRLs pushed by the CA, there is no delay associated with these mechanisms.

Supporting Constrained Networks

The above diagram shows a typical issue associated with constrained networks, showing systems on a ship using PKI information associated with a variety of components. The CAs associated with many remote (and possibly some local) entities are not on the ship and accessed over a constrained network. Whenever a system (RP) on the ship verifies a certificate, this will lead to network access to verify certificates using one of the mechanisms described above. Only the directory option has potential to prevent this access. This type of network access can be problematic because:

• Inefficient use of constrained network bandwidth.
• Does not support disconnected working in the event of network failures.
• Can lead to poor performance of clients (RPs) due to network delays.

A better approach is needed. The following diagram shows the proposed solution. CAs will publish CRLs to a directory. This will get replicated to an M-Vault server on the ship. This will “push” the CRL, so that update is timely and efficient and the M-Vault server will always have the latest CRL. For very slow links this transfer can be highly optimized, as described in [Directory Replication by Email and over ‘Air Gap’].

This will enable M-Vault to provide local certificate checking using OCSP, so that local relying parties do not need to connect over the network.

For this to work, the RPs need to use OCSP in what is known as “Trusted Responder” mode. Essentially, the RP will ignore certificate checking information held in the certificate (which would lead to remote network access) and will instead access a configured local OCSP service. The RP will be configured to trust this local service. This local OCSP service provided by M-Vault will enable certificate checking to be performed on the current CRL, without remote network access.

Delta CRLs

The architecture shown above will work well in many situations. One issue that may arise is that CRLs can be large and if updated frequently, even this single CRL transfer could have a performance issue. Some vendors have addressed this using compact CRL formats (e.g., “miniCRL” and “compactCRL”). This reduces the network load to some extent, but is not ideal.

Isode’s recommended approach is to use delta CRLs. In this mode, the CA publishes a delta relative to the latest complete CRL. At any one time there is a current CRL and a current delta. Essentially the CA issues delta CRLs, when it would previously have issued a full CRL. At much longer issues, a CA will typically issue a new CRL. This will be done when the delta CRLs have grown to a size that performance is best optimized by issuing a complete CRL which will enable much smaller deltas.

A clear attraction of this approach is that it follows open standards, and does not require any proprietary mechanisms. It is architecturally superior, as most of the time it will lead to delta information being transferred (and not just a compressed full CRL).

Management Tools

Isode provides full GUI configuration of these capabilities. This section shows some aspects of this, to illustrate the capabilities. The following screenshots show configuration of the HTTP resource (so you can control the URLs on which CRL and Cross Certificate Pair is published), configuration of the HTTP listener and configuration of an OCSP service, with the CA being handled and the OCSP signing configuration. Multiple services can be set up to support OCSP for a number of CAs in one M-Vault server. The first two screenshots are of Isode’s M-Vault Console (MVC) management GUI, the third of Isode’s Sodium CA.

Sodium CA is Isode’s CA product. When setting up a CA it enables the user to choose the certificate status mechanisms. This information gets published into the certificates generated, and Sodium CA facilitates clean setup of a matching M-Vault configuration.

Conclusions

By integrating OCSP and HTTP lookup of CRLs into M-Vault, a simplified solution for certificate checking can be provided, with fewer components and reduced need for system integration. Isode provides this functionality with easy to use and flexible GUI management. This capability can also be used to provide PKI support over constrained networks.