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 (DPD)

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 (DPV)

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.