<?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 id="GUID-90DF40EF-7D3F-551D-9957-A3756317A254" xml:lang="en"><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 href="http://www.ietf.org/rfc/rfc2560.txt" scope="external">RFC2560</xref>. </p>

<p>On 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 id="GUID-F07B2071-BF8B-4D22-B6F6-1282B2040376"><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 href="http://tools.ietf.org/html/rfc4792" scope="external">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 href="http://www.ietf.org/rfc/rfc2459.txt" scope="external">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 href="http://www.ietf.org/rfc/rfc2560.txt" scope="external">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 id="GUID-B4A093DA-6968-4B17-A3A7-7FF4800DED3B"><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_d0e393399_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_d0e393415_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_d0e393431_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 id="GUID-891303A3-070F-40D2-9382-40A1165928DE"><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>