|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-90DF40EF-7D3F-551D-9957-A3756317A254" xml:lang="en"><title>OCSP |
|
13 Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>Online Certificate Status Protocol (OCSP) is an internet protocol that |
|
15 determines whether a given <xref href="GUID-911E9F7E-D0AD-55EC-A3F4-1D427F803780.dita">certificate</xref> or |
|
16 a list of certificates has been revoked, and therefore, determines whether |
|
17 the certificate can be trusted. The protocol is defined in <xref href="http://www.ietf.org/rfc/rfc2560.txt" scope="external">RFC2560</xref>. </p> |
|
18 <p>On the Symbian platform, <xref href="GUID-0AED3485-D498-57F1-9532-116EA5C8F68B.dita">Secure |
|
19 Software Install (SWI)</xref> uses OCSP to verify whether a certificate associated |
|
20 with an application to be installed has been revoked. For details of how SWI |
|
21 uses OCSP revocation check, see <xref href="GUID-C893C9E6-47B8-5149-9808-0274C61CF3D7.dita">OCSP |
|
22 SWI Integration</xref>. </p> |
|
23 <section id="GUID-F07B2071-BF8B-4D22-B6F6-1282B2040376"><title>OCSP request and response</title> <p>OCSP primarily consists |
|
24 of two parts: a request and a response, each specified in the Abstract Syntax |
|
25 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 |
|
26 to get information on the revocation status of a certificate, forms an OCSP |
|
27 request and sends this to an OCSP server. In its simplest form, an OCSP request |
|
28 consists of one or more identifiers for the certificates whose status is in |
|
29 question. The request is sent to the OCSP server identified by a Uniform Resource |
|
30 Identifier (URI). The URI is specified either in the Authority Information |
|
31 Access (AIA) extension of the certificate whose revocation status is to be |
|
32 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 |
|
33 OCSP server maintains information about the revocation of certificates. The |
|
34 server replies to the client with a signed OCSP response, mentioning the revocation |
|
35 status for each certificate. A response being signed with a key pair is trusted |
|
36 as authoritative by the client. Alternatively, a server can also return an |
|
37 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 |
|
38 is transport-neutral with the URI of the server indicating the required transport |
|
39 mechanism. Currently, only Hypertext Transfer Protocol (HTTP) is supported. </p> <p>The |
|
40 client, in turn, verifies whether the response is valid and is from a trusted |
|
41 entity. </p> </section> |
|
42 <section id="GUID-B4A093DA-6968-4B17-A3A7-7FF4800DED3B"><title>OCSP client-server interaction</title> <p>The server to which |
|
43 the request for revocation check is sent may not actually be the server which |
|
44 is authoritative to answer the request, but may act as a proxy to the destination |
|
45 server. For information on the server to which the request actually gets routed, |
|
46 the client includes a <i>serviceLocator</i> extension (containing the URI) |
|
47 in the OCSP request. </p> <p>There may be a <i>serviceLocator</i> extension |
|
48 for each certificate in the request. Therefore, it is syntactically possible |
|
49 for the request to be split into multiple parts, with each part routed to |
|
50 a different OCSP responder (the server that actually responds to the OCSP |
|
51 request). The intermediate server collates the individual responses into one |
|
52 and returns this to the client. This response is signed only by the intermediate |
|
53 server. In such a situation, the client must trust this intermediate server. </p> <p>Three |
|
54 scenarios are associated with the routing of OCSP requests to the appropriate |
|
55 responder through intermediate servers. They are as follows: </p> <ul> |
|
56 <li id="GUID-CD8AAEA0-AA94-58EA-978F-3C2E21A2FE9F"><p> <b>Single OCSP responder</b> </p> <p>One |
|
57 OCSP server contains the revocation information for all the certificates to |
|
58 be checked. One request containing all the certificates is sent to the responder |
|
59 (in this case, the OCSP server), which replies with a single response. The |
|
60 following figure illustrates the interaction between the OCSP client and a |
|
61 single destination responder. </p> <fig id="GUID-11F6D229-29D0-510A-AB8A-64A906DC00F7"> |
|
62 <image href="GUID-8E3F3745-7875-51A2-BDA1-AA537C7B220E_d0e393561_href.png" placement="inline"/> |
|
63 </fig> </li> |
|
64 <li id="GUID-185C0C91-CC3F-5198-8EAB-BB1BF748A3D0"><p> <b>Multiple OCSP responders |
|
65 using an intermediate OCSP server</b> </p> <p>Multiple OCSP responders use |
|
66 an intermediate OCSP server to route requests to the appropriate destination |
|
67 responders. One request is sent to the intermediate server, which sends multiple |
|
68 individual requests to the destination responders. The responses are collated, |
|
69 and one response is sent back to the client. The following figure shows the |
|
70 interaction between an OCSP client and multiple destination responders by |
|
71 using an intermediate responder. </p> <fig id="GUID-964E18AA-E4F7-5A71-A2F3-19F3007C24C6"> |
|
72 <image href="GUID-2EF123C9-62A2-52FF-9792-66EF41F37452_d0e393577_href.png" placement="inline"/> |
|
73 </fig> </li> |
|
74 <li id="GUID-F092252F-79EF-58E2-A596-77D3FC07CC54"><p> <b>Multiple OCSP responders |
|
75 without an intermediate server</b> </p> <p>The client does the work of sending |
|
76 each request to the appropriate responder. The client collates the responses |
|
77 received. The following figure shows the interaction between the client and |
|
78 multiple destination responders. </p> <fig id="GUID-223A3DB6-538E-5A4E-946C-87AA03449857"> |
|
79 <image href="GUID-A6F1F6AC-5D3C-5055-AEF1-B64671941BCB_d0e393593_href.png" placement="inline"/> |
|
80 </fig> </li> |
|
81 </ul> <p>The choice of the correct method of interaction between the client |
|
82 and the responders depends on the nature of the Public Key Infrastructure |
|
83 (PKI) and the availability of OCSP responders for routing requests as intermediates. </p> </section> |
|
84 <section id="GUID-891303A3-070F-40D2-9382-40A1165928DE"><title>Revocation check results</title> <p>If the response sent by |
|
85 the OCSP server passes all the validation, the application that sends the |
|
86 OCSP request determines the outcome by applying the following rules to the |
|
87 certificate statuses in the response: </p> <ul> |
|
88 <li id="GUID-124E3CDE-7F74-5960-A92C-98B101644036"><p>If any certificate is |
|
89 revoked, the result is <b>Revoked</b> </p> </li> |
|
90 <li id="GUID-C0AF0A69-28C4-528B-9E14-1AAF13CEA497"><p>If all certificates |
|
91 are valid, the result is <b>Good</b> </p> </li> |
|
92 <li id="GUID-7BA5DACD-19B1-55CC-9378-28F4A47AAE12"><p>Otherwise, the result |
|
93 is <b>Unknown</b>. </p> </li> |
|
94 </ul> <p> <b>Note:</b> A certificate status of <b>Good</b> does not indicate |
|
95 that the certificate may be trusted. It merely indicates that the certificate |
|
96 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 |
|
97 which it lies) must still be performed. </p> </section> |
|
98 </conbody><related-links> |
|
99 <link href="GUID-C893C9E6-47B8-5149-9808-0274C61CF3D7.dita"><linktext>OCSP SWI |
|
100 Integration</linktext></link> |
|
101 </related-links></concept> |