<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept xml:lang="en" id="GUID-90DF40EF-7D3F-551D-9957-A3756317A254"><title>OCSP Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>Online Certificate Status Protocol (OCSP) is an internet protocol that determines whether a given <xref href="GUID-911E9F7E-D0AD-55EC-A3F4-1D427F803780.dita">certificate</xref> or a list of certificates has been revoked, and therefore, determines whether the certificate can be trusted. The protocol is defined in <xref scope="external" href="http://www.ietf.org/rfc/rfc2560.txt">RFC2560</xref>. </p> <p>In the Symbian platform, <xref href="GUID-0AED3485-D498-57F1-9532-116EA5C8F68B.dita">Secure Software Install (SWI)</xref> uses OCSP to verify whether a certificate associated with an application to be installed has been revoked. For details of how SWI uses OCSP revocation check, see <xref href="GUID-C893C9E6-47B8-5149-9808-0274C61CF3D7.dita">OCSP SWI Integration</xref>. </p> <section><title>OCSP request and response</title> <p>OCSP primarily consists of two parts: a request and a response, each specified in the Abstract Syntax Notation One - Distinguished Encoding Rules (<xref scope="external" href="http://tools.ietf.org/html/rfc4792">ASN.1</xref> -DER) format. A client application that wants to get information on the revocation status of a certificate, forms an OCSP request and sends this to an OCSP server. In its simplest form, an OCSP request consists of one or more identifiers for the certificates whose status is in question. The request is sent to the OCSP server identified by a Uniform Resource Identifier (URI). The URI is specified either in the Authority Information Access (AIA) extension of the certificate whose revocation status is to be checked, or as a global URI with the OCSP client. AIA is defined in <xref scope="external" href="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</xref>. </p> <p>The OCSP server maintains information about the revocation of certificates. The server replies to the client with a signed OCSP response, mentioning the revocation status for each certificate. A response being signed with a key pair is trusted as authoritative by the client. Alternatively, a server can also return an error code as response (refer to <xref scope="external" href="http://www.ietf.org/rfc/rfc2560.txt">RFC2560</xref> for details of the various OCSP errors). OCSP is transport-neutral with the URI of the server indicating the required transport mechanism. Currently, only Hypertext Transfer Protocol (HTTP) is supported. </p> <p>The client, in turn, verifies whether the response is valid and is from a trusted entity. </p> </section> <section><title>OCSP client-server interaction</title> <p>The server to which the request for revocation check is sent may not actually be the server which is authoritative to answer the request, but may act as a proxy to the destination server. For information on the server to which the request actually gets routed, the client includes a <i>serviceLocator</i> extension (containing the URI) in the OCSP request. </p> <p>There may be a <i>serviceLocator</i> extension for each certificate in the request. Therefore, it is syntactically possible for the request to be split into multiple parts, with each part routed to a different OCSP responder (the server that actually responds to the OCSP request). The intermediate server collates the individual responses into one and returns this to the client. This response is signed only by the intermediate server. In such a situation, the client must trust this intermediate server. </p> <p>Three scenarios are associated with the routing of OCSP requests to the appropriate responder through intermediate servers. They are as follows: </p> <ul><li id="GUID-CD8AAEA0-AA94-58EA-978F-3C2E21A2FE9F"><p> <b>Single OCSP responder</b>  </p> <p>One OCSP server contains the revocation information for all the certificates to be checked. One request containing all the certificates is sent to the responder (in this case, the OCSP server), which replies with a single response. The following figure illustrates the interaction between the OCSP client and a single destination responder. </p> <fig id="GUID-11F6D229-29D0-510A-AB8A-64A906DC00F7"><image href="GUID-8E3F3745-7875-51A2-BDA1-AA537C7B220E_d0e367004_href.png" placement="inline"/></fig> </li> <li id="GUID-185C0C91-CC3F-5198-8EAB-BB1BF748A3D0"><p> <b>Multiple OCSP responders using an intermediate OCSP server</b>  </p> <p>Multiple OCSP responders use an intermediate OCSP server to route requests to the appropriate destination responders. One request is sent to the intermediate server, which sends multiple individual requests to the destination responders. The responses are collated, and one response is sent back to the client. The following figure shows the interaction between an OCSP client and multiple destination responders by using an intermediate responder. </p> <fig id="GUID-964E18AA-E4F7-5A71-A2F3-19F3007C24C6"><image href="GUID-2EF123C9-62A2-52FF-9792-66EF41F37452_d0e367018_href.png" placement="inline"/></fig> </li> <li id="GUID-F092252F-79EF-58E2-A596-77D3FC07CC54"><p> <b>Multiple OCSP responders without an intermediate server</b>  </p> <p>The client does the work of sending each request to the appropriate responder. The client collates the responses received. The following figure shows the interaction between the client and multiple destination responders. </p> <fig id="GUID-223A3DB6-538E-5A4E-946C-87AA03449857"><image href="GUID-A6F1F6AC-5D3C-5055-AEF1-B64671941BCB_d0e367032_href.png" placement="inline"/></fig> </li> </ul> <p>The choice of the correct method of interaction between the client and the responders depends on the nature of the Public Key Infrastructure (PKI) and the availability of OCSP responders for routing requests as intermediates. </p> </section> <section><title>Revocation check results</title> <p>If the response sent by the OCSP server passes all the validation, the application that sends the OCSP request determines the outcome by applying the following rules to the certificate statuses in the response: </p> <ul><li id="GUID-124E3CDE-7F74-5960-A92C-98B101644036"><p>If any certificate is revoked, the result is <b>Revoked</b>  </p> </li> <li id="GUID-C0AF0A69-28C4-528B-9E14-1AAF13CEA497"><p>If all certificates are valid, the result is <b>Good</b>  </p> </li> <li id="GUID-7BA5DACD-19B1-55CC-9378-28F4A47AAE12"><p>Otherwise, the result is <b>Unknown</b>. </p> </li> </ul> <p> <b>Note:</b> A certificate status of <b>Good</b> does not indicate that the certificate may be trusted. It merely indicates that the certificate has not been revoked. The normal validation of that certificate (or the <xref href="GUID-A3B58436-07E4-565B-800B-86435D205461.dita">certificate chain</xref> in which it lies) must still be performed. </p> </section> </conbody><related-links><link href="GUID-C893C9E6-47B8-5149-9808-0274C61CF3D7.dita"><linktext>OCSP SWI Integration</linktext> </link> </related-links></concept>