About Validation Responder

The ActivID Validation Suite provides an infrastructure for validating the revocation status of digital certificates using Online Certificate Status Protocol (OCSP) and Server-based Certificate Validation Protocol (SCVP). The suite includes two infrastructure components. The ActivID Validation Authority (VA) component ensures the accuracy of the certificate status information. The ActivID Validation Responder (VR) component ensures the timeliness and availability of certificate status information.

The core operational tasks of the ActivID Validation Suite are:

• To maintain accurate certificate status information, and

• To distribute accurate certificate status information in a timely fashion to relying party applications and remote subscribers.

OCSP Validation

OCSP is an internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is an alternative to certificate revocation lists (CRL). It addresses certain problems associated with deploying CRLs in large PKI environments.

Comparing to CRLs, an OCSP response contains less information. It creates fewer burdens on network and client resources. There is also less data to parse, the client-side libraries that handle it can be less complex than those that handle CRLs.

OCSP can support more than one level of Certificate Authorities (CA). OCSP requests may be chained between peer responders to query the issuing CA appropriate for the subject certificate, with responders validating each other's responses against the root CA using their own OCSP requests.

Distributed Certificate Validation Technology

The HID Global distributed certificate validation approach is based on the design principle of separating security sensitive data and trusted operations from the delivery process of providing certificate status to relying party applications. This approach eliminates the scalability and availability problems associated with the alternative validation approaches of CRLs and Online Validation.

A single, centralized ActivID Validation Authority (VA) manages validation information for a set of certificate issuers (Certificate Authorities, or CA). Validation Authority periodically creates and publishes OCSP response lists for these issuers.

The distributed ActivID Validation Responders (VRs) periodically retrieve the new OCSP response lists when they become available. Validation Responders are available as software, as an appliance, or as a virtual appliance.

The relying parties are OCSP Clients. They can be using ActivID Validation Client or other third-party OCSP clients. ActivID Validation Client may be installed on either workstations or servers. Note that some ActivID Validation Client versions are named Desktop Validation Client (when installed on workstations) and SerVE – for Server Validation Extension (when installed on servers; different models exist for different server types: Windows Domain Controller, IIS web server, Exchange server with OWA).

The relying party application validates a user’s certificate through the following steps:

1. Receives the user’s certificate.

2. Verifies the integrity of the certificate (by checking its digital signature, expiration date, and so on).

3. Checks associated authentication factors (PIN, public key challenge, biometrics, and so on).

4. Requests an OCSP response from a Validation Responder.

5. Receives the OCSP response for the user’s credential.

6. Verifies the integrity of the OCSP response.

7. Processes or denies the requested transaction based on the information received from the Responder.

This process performs authentication and validation of the user’s credentials. As long as the relying party can receive a current OCSP response, it can perform all of these operations without making a real-time connection to a central, trusted authority.

OCSP responses are public, verifiable, and tamper-evident, so they can be published widely. Since the Validation Responders only return responses that were pre-generated by a Validation Authority, Validation Responders do not have to be individually trusted or tightly secured. A relying party can accept an OCSP response coming from any Validation Responder, regardless of the location of that specific Responder or who is administering it.

Distributed OCSP Responses

The ActivID Validation Suite delivers a complete certificate validation solution that includes ActivID Validation Authority and ActivID Validation Responders.

Distributed OCSP responses provided by Validation Authority are:

• Pre-generated—Created and published periodically, not based on specific requests.

• Individual—Each response corresponds to a single certificate or a small number of certificates.

• Small—Typically no more than a few hundred bytes per response.

• Verifiable—The use of digital signing means that forged or tampered responses can be distinguished from real responses.

• Bounded—Usable for a specific period of time.

The OCSP response format is structured as a set of status assertions that are digitally signed using the private signature key of Validation Authority. The body of the response includes information about its starting and ending times as well as the certificate’s revocation status. The digital signature is based on standard digital signature algorithms.

The following figure illustrates the contents of a hypothetical digitally signed response.

Validation Authority publishes OCSP responses to provide validation for digital certificates. The exact format of these responses is specified in the OCSP standard published by the IETF as RFC 6960. A response of this format is typically between 150 and 350 bytes in size and is compatible with all existing X.509 certificates. A relying party can trust this type of response based on the integrity of the digital signature. ActivID Distributed OCSP responses are fully compatible with any relying party that uses the OCSP standard for performing validation. However, ActivID Distributed OCSP responses maintain the distinct advantages of availability, scalability, and security which traditional OCSP and CRL-based implementations lack. This enables OCSP to be used to manage millions of certificates over a global physical environment.

MiniCRL Model

HID Global also offers an alternate model designed to address environments with limited bandwidth. In this case, Validation Authority can generate OCSP responses in MiniCRL format (HID Global proprietary format), a compressed data format.

Additional Validation Authorities, referred to as "Tactical Validation Authorities" (TVAs), can be deployed in the field, and import these MiniCRLs, in order to provide standard OCSP responses to the Validation Responders.

This model is well suited for large distributed environments with limited bandwidth.

Non-Distributed Operations

You can configure Validation Authority to offer OCSP service directly to relying party applications, thus providing individual signed responses to OCSP requests. Typically, this direct OCSP interface is used when a request contains one of the following conditions:

• When an OCSP request contains a nonce—This request cannot be serviced by distributed Validation Responders because Validation Responders cannot perform cryptographic operations,

• When a distributed OCSP Responder does not have revocation status information for a certificate issued by a known certificate issuer,

• When configurations do not make use of distributed OCSP Responders.

Upon receipt of a request, the direct OCSP interface verifies the revocation status of the certificate in the request, creates a digitally-signed response, and returns the response to the relying party.

Administrators must exercise caution when making use of the Validation Authority direct OCSP interface. This response process becomes more resource-intensive as the volume of OCSP requests increases. The number of responses that Validation Authority can create is limited by the capability of an HSM to generate digital signatures. Also, to be able to receive requests, relying parties must have access to Validation Authority from the external network.

• For information about configuring the direct OCSP interface, refer to the ActivID Validation Authority Management Console User Guide.

• For information about configuring Responders to relay requests to the direct OCSP interface, refer to the ActivID Validation Responder Administration Guide.

• For information about configuring OCSP request options and OCSP response acceptance parameters, refer to the documentation supplied with your relying party applications.

SCVP Validation

The Online Certificate Status Protocol (OCSP) technology, designed to provide the real-time status of certificates, can be complemented by the Server-based Certificate Validation Protocol (SCVP) technology, which helps determine the certificate path.

SCVP is an Internet protocol for determining the path between a X.509 digital certificate and a trusted root (Delegated Path Discovery—DPD) and the validation of that path (Delegated Path Validation—DPV) according to a particular validation policy. When a relying party receives a digital certificate and needs to decide whether to trust the certificate, it first needs to determine whether the certificate can be linked to a trusted certificate. This process may involve chaining the certificate back through several issuers.

SCVP provides a standards-based client-server protocol for solving this problem using DPD. When using DPD, a relying party asks a server for a certification path that meets its needs. The SCVP client's request contains the certificate that it is attempting to trust and a set of trusted certificates. The SCVP server's response contains a set of certificates making up a valid path between the certificate in question and one of the trusted certificates. The response may also contain proof of revocation status, such as OCSP responses, for the certificates in the path.

Once a certification path has been constructed, it needs to be validated. An algorithm for validating certification paths is defined in RFC 5280 section 6 (signatures, expiration, name constraints, policy constraints, basic constraints, etc.). This can be done locally by the client or by the SCVP server with DPV.

The ActivID Validation Suite provides a server infrastructure for validating the status of digital certificates using SCVP. SCVP requests can take one of the following two basic forms:

Certificate validation is complex. Certificate handling can be widely deployed in a variety of applications and environments. Before an application can accept a certificate, the amount of processing the application needs to perform must be reduced. There are a variety of applications that can make use of public key certificates. However, these applications are burdened with the overhead of constructing and validating the certification paths. SCVP reduces this overhead for the following two classes of certificate-using application:

• The first class of applications has two functions—Confirming that the public key belongs to the identity named in the certificate and the public key can be used for the intended purpose. Such clients can completely delegate certification path construction and validation to the SCVP server. This is often referred to as DPV.

• The second class of applications can perform certification path validation, but they lack a reliable or efficient method of constructing a valid certification path. Such clients delegate certification path construction to the SCVP server, but not validation of the returned certification path. This is often referred to as DPD.

The ActivID Validation Suite is capable of servicing both DPD and DPV requests.

It is comprised of two infrastructure components:

• ActivID Validation Authority provides all security functions and stores all security-sensitive data, and is capable of responding to both DPD and DPV requests. All deployments include at least one Validation Authority.

• ActivID Validation Responder retrieves certification path data from one or more Validation Authorities and uses this information to respond to DPD requests. Responder does not perform any security-sensitive functions nor store any sensitive data. It is not capable of responding to DPV requests. A DPD deployment typically includes one or more Validation Responders.

Certification Path Validation

The Validation Suite delivers a complete certificate validation solution that includes the Validation Authority, Validation Responder, and relying party applications.

When a relying party application receives a digital certificate, it must first determine whether the certificate can be linked to a trusted root certificate before it can decide whether or not to trust the certificate. This process involves chaining the certificate back through several issuers, as in the following example:

Name: William Braun

CA: ACME Rockets Certificate Authority

Root CA: Equifax Secure eBusiness CA-1

Typically, the application receiving the signed message or document creates this chain of certificates. The process is termed "path discovery" and the resulting chain is called a "certification path."

Many Windows applications, such as Microsoft Outlook, use the Microsoft Cryptographic API (CAPI) to perform path discovery. CAPI is capable of building certification paths using any certificates that are installed in Windows certificate stores or provided by the relying party application. The Equifax CA certificate, for example, is preconfigured in Windows as a trusted certificate. In this example, if CAPI knows about the ACME Rockets Certificate Authority (CA) certificate or if it is included in a signed email and made available to CAPI by Outlook, CAPI can create the certification path above. However, if CAPI cannot find the ACME Rockets CA certificate, it has no way to verify that William Braun is trusted.

In a more complicated example, a user application might be required to validate a certificate that was issued by a CA in a completely different PKI deployment. This can happen, for example, in bridged environments, such as among government agencies or in B2B relationships in which each entity has its own root CA. To be assured that the certificate is valid, the application needs a method of confirming that a trust path exists between the root CAs in the different PKI deployments. In addition to this requirement, some CAs may have policies that constrain the uses (for example, email or digitally signing a document) for which a given certificate in the trust path may be used. There can also be constraints about the names used in a certificate. When any of these conditions apply, the user application must also be assured that each certificate in the trust path is valid for the purpose for which it was supplied, has not expired, and complies with all relevant constraints. Since CAPI is unlikely to have the necessary information about at least some of the certificates needed to form the complete trust path, it will be unable to validate a certificate received by the user application.

ActivID Validation Authority uses SCVP to solve these problems using Delegated Path Discovery (DPD) for relying parties that validate certification paths locally and Delegated Path Validation (DPV) for relying parties that require an external authority to perform this validation for them.

Delegated Path Discovery

When using DPD, a relying party asks a server for a certification path that meets its requirements. The client's request contains the certificate that it is attempting to trust and a set of trusted root certificates. The server response contains a set of certificates making up one or more paths between the certificate in question and one of the trusted certificates. The response can also contain proof of revocation status, such as OCSP responses created by Validation Authority, for the certificates in the path.

After a client has received a certification path using SCVP, it must validate the path using its own set of trusted certificates to ensure that none of the certificates in the path are expired or revoked and that each certificate meets required certification policy and name constraints. Because the data received in the SCVP response is already digitally signed, the client does not need to place any trust in Validation Authority that generated the certification path data.

Validation Authority periodically publishes a set of paths to Responders, which then respond to relying party requests. Because the Responder does not need to search for path data when the request is received, requests can be serviced extremely quickly.

Delegated Path Validation

When using DPV, a relying party asks the Direct SCVP Interface in Validation Authority to verify whether a certificate is valid. Validation Authority uses certificates that it trusts to construct a certification path and validates the path to ensure that each certificate in the path is not expired or revoked and that each certificate in the path meets required certification policy and name constraints. Validation Authority returns the result of the validation to the relying party. The SCVP response to the relying party contains a digitally signed answer indicating whether the certificate that the relying party asked about is valid or not valid.

In DPD configurations, Validation Authority performs path discovery and the client validates the certification path. In DPV configurations, Validation Authority must use its resources for path discovery and to validate the certification path and digitally sign the SCVP response for each certificate validation request. As such, DPV server implementations handle a lower volume of transactions than DPD servers.

Functional Architecture and Concept of Operations

You can use the ActivID Validation Suite to offer OCSP (direct or distributed) and SCVP (DPD and DPV) services, or a just a subset of these services. The architecture will vary depending on the services you want to offer.

Simple Distributed OCSP and SCVP (DPD) Deployment

The following figure illustrates how Validation Authority can be integrated into a simple deployment to offer Distributed OCSP and SCVP (DPD) services.

Prior to system operation, the Validation Authority must be configured with the certificate issuers that it will support. Issuers are registered with the Authority manually or using LDAP queries. New certificate issuers can be registered as required during operation. Authority dynamically discovers new certificate issuers from all configured LDAP and HTTP data sources.

• Certificate issuers (CAs) publish Certificate Revocation Lists which Validation Authority uses to track certificates that are revoked or suspended. CRLs are digitally signed by the certificate issuer.

• Certificate issuers publish end-entity certificates which Validation Authority retrieves. In most cases, Validation Authority does not require the end-entity certificates when generating OCSP responses. Certificates are digitally signed by the certificate issuer.

• Validation Authority periodically creates and publishes lists containing current OCSP responses for an issuer’s certificates. Validation Authority also periodically precomputes and publishes lists containing current certification paths (PDP). Each response is digitally signed by Validation Authority.

• Subscribers request services or access from a relying party application.

• Relying party applications query Validation Responders for the status of a certificate. Validation Responder returns the appropriate OCSP response. Relying party applications also query Validation Responders for a certification path. Validation Responder returns one or more previously published certification paths to the relying party.

• Relying party applications grant or deny a subscriber's service request based on the response received from Validation Responder.

• The Validation Suite components (Validation Authority and Validation Responder) are deployed as standalone programs that can be integrated easily into existing infrastructures and business processes.

In this example, the subscriber represents an entity that requests access to a service, data, or physical location by presenting his or her certificate to a relying party (RP) application.

Certificates are generated by the CA upon receipt of an authorized request from a Registration Authority (RA). The relying party grants or denies access based on the integrity and validity of the presented certificate.

Simple Direct OCSP and SCVP (DPV) Deployment

• Validation Authority responds to direct OCSP requests coming from relying party applications. Validation Authority also computes certification paths and status information and services DPV requests from relying party applications. Each response is digitally signed by Validation Authority.

• Relying party applications query the Authority’s Direct SCVP Interface for validity status information about a certificate. The Authority returns a “Valid” or “Not Valid” status to the relying party.

• Relying party applications grant or deny a subscriber's service request based on the response received from the Authority, but only after validating the Authority’s signature on the SCVP response.

Validation Suite Components

Component 1: ActivID Validation Authority—This component periodically generates and makes available OCSP response lists and certification paths (DPD). It also services direct OCSP requests and certification paths (DPV) requests.

• Smart Data Bridge is an optional component provided together with ActivID Validation Authority. It enables outside applications to push revocation status for individual certificates to a Validation Authority. For more information, see the ActivID Smart Data Bridge Installation and Configuration Guide.

Component 2: ActivID Validation Responder—This component retrieves lists of pre-generated OCSP responses and certification paths (DPD) from one or more Validation Authorities and provides individual certificate validation information to relying party applications.

Validation System Components Not Supplied by the Validation Suite

Component 1: Hardware Security Module (HSM)

This component provides the following cryptographic support to Validation Authority:

• Key generation,

• Signing of OCSP response lists,

• Signing of individual OCSP responses, and

• Destruction of signing keys when they are outdated.

• Verify CRL and certificate signatures,

• Sign audit data,

• Establish secure SSL communications,

• Generate random numbers,

• Encrypt security-sensitive data for local storage (for example, passwords and keys), and

• Perform one-way hashing.

Component 2: File Distribution Mechanism

This component serves as a repository for OCSP response lists and public certification path data, and provides a way to make the data available at a public URL. This mechanism can be implemented using a variety of hardware and software combinations (for example, a static web server; a file server that supports NFS, FTP, or HTTP; or a combination of a file server that stores the response lists and a separate HTTP server that requests these lists from the file server and distributes them to responders). Validation Authority writes the lists to the File Distribution Mechanism, but there is no information flow from the File Distribution Mechanism to Validation Authority (that is, no upstream communication).

Other PKI Components Required

• Component 1: Certificate/CRL Publishing Service

  This component is a service that provides connections to import and export certificates and certificate revocation lists (CRLs). For example, an LDAP directory serves as the data retrieval interface between the CA and Validation Authority. The CA posts both certificates and Certificate Revocation Lists (CRLs) to the LDAP directory from which Validation Authority retrieves them.

• Component 2: Certificate Authority (CA)

  This component signs and publishes certificates and CRLs based on information provided by an issuer or Registration Authority.

• Component 3: Registration Authority (RA)

  This component receives and validates user requests for certificates, constructs certificate requests and then forwards the requests to a CA for signing, and sends revocation requests to the CA for inclusion in CRLs.

• Component 4: Subscribers

  These are certificate holders who request services or access.

• Component 5: Relying Party Applications

  These are client applications that request validation of certificates that are contained in digitally-signed documents, email messages, or web pages.

Topics on this page