SCVP

<h2 id="overview">Overview</h2>
<p>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, such as the following case:
</p>
  Equifax Secure eBusiness CA-1
     ACME Co Certificate Authority
        Joe User

<p>Currently, the creation of this chain of certificates is performed by the application receiving the signed message. The process is termed "path discovery" and the resulting chain is called a "certification path". Many Windows applications, such as Outlook, use <a href="/facts/Cryptographic_Application_Programming_Interface/yTtHjHhN">Cryptographic Application Programming Interface</a> (CAPI) for path discovery.
</p><p>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, comes installed in Windows as a trusted certificate. If CAPI knows about the ACME Co 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 Co CA certificate, it has no way to verify that Joe User is trusted.
</p><p>SCVP provides us with a standards-based client-server protocol for solving this problem using <a href="/facts/Delegated_Path_Discovery/atH8ezWY">Delegated Path Discovery</a>, or 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 <a href="/facts/OCSP/0SuMER8c">OCSP</a> responses, for the certificates in the path.
</p><p>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.).  Again, this could be done locally by the client or by the SCVP server with <a href="/facts/Delegated_Path_Validation/yHF8kCx1">Delegated Path Validation</a>.
</p><p>SCVP facilitates Federated PKIs, such as one with a Bridge Certificate Authority.
</p>
<h2 id="external-links">External links</h2>
<ul><li>RFC 5055 - Server-Based Certificate Validation Protocol (SCVP) (December 2007 Proposed Standard)</li></ul>

SCVP open-in-new

SCVP