This article discusses the features that should be on a highly desirable feature list when looking for an OCSP Responder product. Although the main focus of this topic is technical, there are commercial aspects that need consideration. These are summarised briefly at the end. The technical features explained here are all available and implemented in Ascertia ADSS OCSP Server, which is downloadable on trial basis.
First, you should be aware that an OCSP Responder is known by various names, such as:
- Validation authority
- Revocation server
- OCSP VA
- OCSP server
- RFC 6960 server
- Real-time certificate status server
- Validation server
It’s best to stick to either OCSP Responder or OCSP Server to avoid confusion, or for management purposes OCSP Validation Authority (or OCSP VA for short) is also a good choice.
OCSP Responder background
Interestingly, Microsoft Windows systems now provide OCSP client support. There are good reasons for this.
Downloading large Certificate Revocation Lists (CRLs), often 200KB to 20MB in size, to multiple end systems is a heavy duty activity. OCSP protocols make this a much lighter task. Typically, each request and response is around 4KB.
Embedding validating data into digital signatures is becoming more commonplace. So, embedding 4KB rather than say 200KB+ into a document signature is clearly very important.
This is all we will say about OCSP clients, since the scope of this article is about the key features that you should check when deciding which OCSP Responder technology to use. These points are regardless of whether you look at open source or commercial products.
RFC 6960 OCSP is not a complete panacea. It is important to note, CRLs have their place even if you deploy an OCSP responder.
CRLs are essential for historical certificate validation services. OCSP VA servers allow you to have another channel for disseminating certificate status information and allows more flexibility on where and when to use CRLs.
Newer protocols such as SCVP and XKMS and also OASIS DSS-X also offer historic validation and verification services. These are described elsewhere on the Ascertia web-site.
OCSP Responder support for multiple Certificate Authorities (CA)
It is a fundamental requirement for an OCSP Responder to provide certificate status information for more than one CA. It allows you to minimise hardware, software and management costs associated with running separate OCSP Responders for each CA.
Most OCSP VA servers are pretty good at this, but you need to look at how flexible and secure this multi-CA support is. For example:
- How does the key management for the OCSP Responder work when responding on behalf of different CAs? Does it use the same certificate when responding for all CAs or can a separate certificate be used when responding for each CA? Obviously the use of separate OCSP response signing certificates with properly marked EKU (Extended Key Usage) extension is better for security reason – but not all OCSP Responders follow this approach.
- How about the use of separate OCSP response signing private keys for each CA? Of course for an OCSP Service Provider servicing multiple CAs belonging to separate organisations then this becomes pretty important – generally CAs will not want the same OCSP response signing key shared with other organisations, especially competitors!
- Does the OCSP Responder provide unique methods for receiving certificate revocation information from its CAs? E.g. is it configurable whether to use HTTP/S, LDAP/S or direct feed from CA database? Is it configurable on a per CA basis how often this information is retrieved by the OCSP Responder and how it should handle errors?
- Can the freshness of a CRL be checked as it is imported into the OCSP VA server? Can the CRL be checked and copied or re-published locally for disaster recovery purposes.
- Does the OCSP Responder provide per CA transaction logging and management reporting? For example can the OCSP Responder produce graphical service usage reports on a per CA basis? Are the logs secured against change, deletion and insertion?
- Can an operator explore the OCSP request / response data to review in English the key information to quickly and easily determine the cause of an error seen by an OCSP client? From experience without this each reported problem can take hours of senior technical person’s time to resolve.
- How much flexibility does the OCSP Responder provide when configuring the validation policies on a per CA basis? Can you choose the following points on a per CA basis:
- Whether to identify the OCSP Responder to by name or by key hash
- Which secure hash algorithm to use when signing OCSP responses (SHA1, SHA256, SHA512 and other SHA-2 variants)
- Whether to include the OCSP Responder’s certificate chain in the OCSP response
- Which OCSP request extensions to expect in the OCSP request message
- Which OCSP response extensions to use in the OCSP response message
- Whether to allow OCSP relaying and the policy for handling the relayed OCSP request/response (i.e. asking another back-end OCSP for its validation data)
These are the main features to look for. Of course, having all these made available within an easy to use secure web-based interface with role based access controls is vital too.
The following screenshot shows some of the settings that can be made on a per-CA basis within ADSS OCSP Server:
CA registration in OCSP Responder
OCSP Responder Key Lengths & Algorithm Agility
Cryptographic algorithms are continually weakening as the computing power available per dollar grows and as a result of continued cryptanalysis effort by the crypto community.
It is essential that your OCSP Responder is capable of meeting future challenges. As a minimum, it means that the OCSP Responder provides flexibility when generating keys.
The current norm is 1024-bit RSA keys, but a move to 2048-bit is already underway. 4096-bit RSA keys should also be supported for future needs. ECDSA is not well supported at this time, but the supplier should be able to commit to support this if required.
Another important aspect, with regards to key management, is the principle of “key separation”.
Your OCSP Responder must be capable of using separate crypto keys for separate functions. For example:
- OCSP response signing
- OCSP request signing - when relaying OCSP requests
- SSL server key - when it is acting as the SSL server to OCSP clients
- SSL client key - when it is acting as an SSL client to a back-end OCSP Responder that communicates over SSL
Of course there are a range of other key purposes also, like log signing, operator authentication etc. Each key should be managed with its own policy.
Some organisations prefer their OCSP Responder certificate to have a short lifetime. It helps to ensure that any potential compromise of the OCSP Responder will be short lived, and also as a result allows the OCSP Responder’s own certificate to be implicitly trusted, i.e. it has a “no check” extension.
This has an advantage, since checking the OCSP Responder’s certificate can become difficult for relying parties as generally it means they have to use CRLs.
However, if you want to use short-lived OCSP Responder certificates, then ensure your OCSP Responder supports automated re-certification from your chosen CA. In this case, it will become a major burden if you were to manually re-certify the OCSP Responder on a weekly or daily or even hourly basis!
With regards to algorithm agility, the main focus of the crypto community is currently on the hash algorithms that are used in the OCSP response signing process.
SHA-1 has been used in the vast majority of implementations, but it is now recommended by FIPS that it is no longer used. It is important that your OCSP Responder supports the new SHA-2 set of algorithms (this includes SHA-256, SHA-384 and SHA-512).
OCSP responder certificate selection when generating OCSP response
OCSP Responder performance, scalability and resilience
Generally, customers are aware of the importance of performance and scalability for an online OCSP server which may be contacted by thousands of OCSP clients simultaneously. There are a few things to watch out for here:
- Does the OCSP Responder have a scalable architecture to take advantage of multiple CPUs and can multiple servers work together as a single managed system behind network load-balancers (you will not want to manage individual OCSP VAs).
- What is the speed at which CRL s can be checked and processed within the OCSP Responder? When CRLs sizes are in excess of 1MB, then the in memory processing of the CRL can become an issue. Check if your OCSP Responder can handle large CRLs using CRL streaming techniques.
- Ensuring high availability for an OCSP Responder requires the use of multiple instances of an OCSP Responder working behind a network load-balancer so that if one server fails the overall OCSP service is not impacted.
Can multiple instances be operated at different sites to ensure a disaster at one site does not take the OCSP service down? It is important to ensure that all components of the OCSP service are also replicated, such as databases and also HSMs. Also note that if keys and certificates cannot be copied then the OCSP Responder needs to support the automatic use of alternate keys and certificates per server. - When using multiple OCSP Responder instances then only one OCSP VA Server instance will download the CA CRLs containing the latest certificate status information. It is critical that this is not a single point failure.
If an OCSP server fails then another OCSP server instance in the high availability group must automatically take over this CRL management process. ADSS OCSP Server handles this using automated watch-dog process using master and slave servers to poll for CRLs. - What do OCSP performance figures really mean? When discussing OCSP Responder performance in terms of OCSP transactions per second (TPS) you really need to try and understand the underlying assumptions. There are many aspects which can affect OCSP performance and you may be getting a performance quotation which is possible under lab conditions but never in real production use. OCSP Responder performance is based on many factors:
- How many certificates are contained in the request
- Were the OCSP requests signed and was client authentication performed by the OCSP Responder.
- What other types of access control checks are performed on the OCSP request, e.g. Is the OCSP transaction being conducted over SSL/TLS session, also is client SSL authentication enabled
- How large is the OCSP response signing key
- Are the certificates being validated locally or are they being relayed to a back-end OCSP Responder
- How large is the CRL, or alternatively how large is the certificate status table within the OCSP Responder which needs to be searched
- Which database is being used and is it on the same machine as the OCSP Responder
- What is the machine specification of the OCSP Responder and the database
- Is an HSM being used and what signing speed does it offer
- Is the OCSP Client located on the same machine as the OCSP Responder or on the local network
High availability configuration in ADSS OCSP Server
OCSP Responder security
Security is critical issue for an OCSP Validation Authority. Such security cannot be bolted on and needs to part of the design.
Ascertia recognises the value of the ETSI CWA 14167-1 standard for trustworthy systems in this area and has designed ADSS Server to comply with this. Security is an often overlooked area and other technology solutions, particularly open source products, need to be reviewed with care. The major security features to look for are:
- Strong authentication of administrators together with role-based access controls for all system services.
Some operators may be authorised to just review (on a read only basis) the transaction logs so they can help customers. Some operators will be authorised to make changes to the OCSP Service or the trusted CAs or the validation policy details. - Secure and detailed transaction logging is an absolute must for an OCSP Responder. Not only is this needed for commercial OCSP service providers which want to charge for the OCSP service but the ability to review OCSP transactions is essential to resolve helpdesk issues quickly.
A transaction viewer should be provided that can show all fields within each and every OCSP request and response. This must be present in human readable form that enables you to drill down to the details. It should be possible to export and import individual OCSP transactions or a set of transactions in case of disputes.
Detailed operator logs and system event logs must also be maintained to know exactly what was changed on the system, at what date and time and by whom. To make all this logging effective, the OCSP Responder must provide a flexible search facility across all its logs, otherwise the volume of data can obfuscate the information you need. - System integrity is crucial for an OCSP VA trust authority.
The server should protect all its configurations and transaction, operator and system log records with strong cryptographic checksums ideally using SHA-2 algorithms.
Checking the system integrity should be automated, checking the system off-peak times since this can be an intensive operation. Manual checks should also be allowed. Detailed system integrity reports should be produced to ensure that nothing is overlooked. - Generally OCSP Responders in high-trust environments will be required to use a Hardware Security Module (HSM) to protect the signing and HMAC keys. PKCS#11 support ensures that the software should be able to work with variety of HSMs.
- There are many things that could potential effect the normal operation of an OCSP Responder.
These range from network problems when retrieving CRLs from the registered CAs, to CRLs not being issued when they should have been, to keys approaching their expiry date to database communication problems.
Real-time alerting for an OCSP Responder must be high on the feature list. Generally you should expect the OCSP Responder to provide more than one option for real-time alerting. ADSS OCSP Server goes further and offers a choice of email, SMS and SNMP messaging. - OCSP Client access control is an important consideration especially if you want to charge for your OCSP service. An OCSP Responder should be able to authenticate OCSP clients using a variety of techniques such as:
- OCSP request signing
- SSL client authentication
- IP address-based authentication
- Some customers need the highest levels of security and here the OCSP Responder must offer dual control functionality. For example, it can be where two operators are needed to perform any change to the system, one operator performs the action whilst the second operator (usually security officer role holder) approves or rejects the action.
The original change request should be held pending until reviewed and no action is implemented until approved by the security officer. - Easy housekeeping and administration are important aspects of an effective security management system.
Human interface complexities can lead to incorrect functioning or complete failure of the OCSP VA. An OCSP Responder should have a simple, secure web interface and policy-based engine that enables configurations to be made quickly and easily.
Administrator actions such as system integrity checking and archiving of database records to prevent database bloating should be done automatically to avoid reliability issues.
OCSP request/response viewer in ADSS OCSP Server
Auto archiving configuration in ADSS OCSP Server
Access control settings in ADSS OCSP Server
Management Reporting
As the use of OCSP clients grows within multiple systems and business applications, it is important for OCSP validation authority service providers to be able to get meaningful data on the OCSP service performance.
It is essential within a commercial OCSP service that is metered and run within a SLA. Such management reporting data may include:
- How many OCSP service transactions were received within a particular date range
- Which relying party OCSP client was making the most OCSP requests within a particular date range, and be able to group each of these transactions
- Which target certificate was checked the most by all OCSP clients within a specific data range
- Which of the registered CAs certificates were checked the most
- How many “unknown” or “revoked” responses were returned within a date range
- A monitoring tool that can tell what the minimum, average and maximum response times were is also valuable (check the Ascertia OCSP Monitor datasheet for more information)
This information should be easy to understand using pie-charts and tables. The management reports should be exportable in PDF and CSV formats, so that they can be imported into Adobe® Reader and Microsoft Excel for example.
The following screenshots show some reports and associated settings for management reporting in ADSS OCSP Server:
OCSP Responder service report
OCSP Responder usage report
OCSP Responder target CAs report
OCSP Responder commercial considerations
Commercial issues have a high priority, with sensible OCSP server pricing being highest on the list.
Occasionally you may find per OCSP transaction or usage limit charges, which can really push up the pricing for an OCSP server in the long term. Generally it should only be server-based pricing and per-user pricing, with options for unlimited users also.
Test and pre-production test OCSP servers should generally low or zero license price. Competent suppliers should also be able to provide the necessary OCSP test tools that measure OCSP performance as well as OCSP service monitoring tools.
Finally before making an investment in OCSP Responder technology check whether the vendor has the right long-term strategy for certificate validation - are they investing in future protocols such as XKMS, SCVP and OASIS DSS certification validation? Can the product be easily enhanced to support these future certificate validation protocols today on the same platform, at low cost?
OCSP Responder summary
This article describes some of the high-level must have features for an OCSP Responder. Naturally, Ascertia ADSS OCSP Server scores very highly against all these points.
