|
1 /** |
|
2 |
|
3 @page overview_OCSP OCSP -- Online Certificate Status Protocol |
|
4 \n |
|
5 |
|
6 @section overview_of_ocsp Overview of OCSP |
|
7 |
|
8 OCSP is a simple request/response protocol. |
|
9 |
|
10 To establish whether a given @ref certificate or list of certificates has been revoked, a client forms an OCSP request |
|
11 and sends this to an OCSP server. The server maintains revocation information in the form of, say, |
|
12 @ref CRL "Certificate Revocation Lists" (CRLs). The server replies to the client with a signed OCSP response, stating for each certificate whether the |
|
13 status is \b Good, \b Revoked, or \b Unknown. This response in turn is checked to ensure that it is valid, and that it |
|
14 is from an entity trusted for performing revocation checking. |
|
15 |
|
16 The Symbian platform provides the ability to validate and manage @ref X509_certificate "X.509 certificates". This ability is integrated into |
|
17 the software installation process to provide 'Secure Software Install' certificate checking at installation time to |
|
18 verify the identity of the software supplier. |
|
19 |
|
20 Secure Software Install (see below: @ref SWI) needs to be able to check whether certificates have been revoked. The |
|
21 rationale for this is that if a developer certificate has been revoked because it has been compromised, or used |
|
22 maliciously, we should be able to ensure that packages signed by that certificate are not accepted by the platform. |
|
23 |
|
24 This requirement is satisfied by: |
|
25 @li The implementation of the Online Certificate Status Protocol. OCSP is an Internet protocol that is defined in |
|
26 <A HREF="http://www.ietf.org/rfc/rfc2560.txt">RFC2560</A>. |
|
27 The OCSP module forms part of the @ref X509_certificate "X.509 certificate" management code |
|
28 @li The integration of revocation checking into the Secure Software Installation process. |
|
29 |
|
30 <hr> |
|
31 |
|
32 @section ocsp_protocol The OCSP Protocol |
|
33 |
|
34 The OCSP protocol comes in two parts: the request and the response, each given in @ref ASN "ASN.1" @ref DER notation. |
|
35 |
|
36 In its simplest form, an OCSP request consists of one or more identifiers for the certificates whose status is in question. |
|
37 The request is sent to a server identified by a @ref URI. |
|
38 |
|
39 In its simplest form, the response consists of a status indication for each certificate identifier in the request. The |
|
40 whole response being signed with a key pair trusted as authoritative by the client. Alternatively, an unsigned error code |
|
41 may be returned. |
|
42 |
|
43 When a response has been received, it is then validated to see if it can be trusted. |
|
44 OCSP is transport-neutral: the @ref URI of the server indicates the scheme required; currently, only HTTP is |
|
45 supported. |
|
46 |
|
47 @section locating_the_ocsp_server Locating the OCSP Server |
|
48 |
|
49 When performing revocation checking, it is necessary to know where to send a request. In addition, the server to which |
|
50 the request is sent may not actually be the server to which is authoritative to answer the request, but may act as a proxy |
|
51 client and the destination server. In an OCSP request, this behaviour is requested by adding a serviceLocator extension |
|
52 containing the @ref URI. |
|
53 |
|
54 The situation is complicated by the fact that there may be a serviceLocator extension for each @ref certificate in the request, |
|
55 and so it is syntactically possible for the request to be split into multiple parts, with each part routed to a different |
|
56 OCSP responder. The intermediate server collates the individual responses into one and returns this to the client. This |
|
57 response is signed only by the intermediate server, so it is this server the client must trust. |
|
58 There are 3 possible scenarios for the arrangement of OCSP responders: |
|
59 |
|
60 @li Single OCSP responder. |
|
61 One OCSP server contains the revocation information for all certificates that will be checked. |
|
62 One request containing all certificates to be checked is sent to the responder, which replies with a single response: \n\n |
|
63 @image html Certman_OCSP_singleserver.png |
|
64 \n\n |
|
65 |
|
66 @li Multiple OCSP responders using an intermediate OCSP server to route requests to the appropriate one. One request is |
|
67 sent to the intermediate server, which sends multiple individual requests to the destination responders. The responses |
|
68 are collated, and one response is sent back to the client: \n\n |
|
69 @image html Certman_OCSP_multiservers1.png |
|
70 \n\n |
|
71 |
|
72 @li Multiple OCSP responders without an intermediate server. The client does the work of sending each request to the |
|
73 appropriate responder. The client collates the responses received: \n\n |
|
74 @image html Certman_OCSP_multiservers2.png |
|
75 \n\n |
|
76 |
|
77 |
|
78 Which scenario is appropriate depends on the nature of the @ref PKI, and the availability of OCSP responders that will act |
|
79 as intermediates and route requests appropriately. |
|
80 |
|
81 @section outcome_result Outcome result |
|
82 |
|
83 If the response passes all validation, the outcome result is determined by applying the following rules to the certificate statuses in the response: |
|
84 @li If any certificate was 'revoked', the result is \b 'Revoked' |
|
85 @li If all certificates were 'valid', the result is \b 'Good' |
|
86 @li Otherwise, the result is \b 'Unknown'. |
|
87 |
|
88 @note |
|
89 A certificate status of 'Good' does not indicate that the @ref certificate may be trusted. It merely indicates that |
|
90 the certificate has not been revoked. The normal validation of that @ref certificate (or the chain in which it lies) must |
|
91 still be performed. |
|
92 |
|
93 |
|
94 <hr> |
|
95 |
|
96 @section SWI OCSP Integration with Secure Software Install |
|
97 |
|
98 Software Install may be configured to check revocation status of certificates or not. Software Install supplies the OCSP |
|
99 client with a default URI for the OCSP server. Both of these are controlled by a user preference. |
|
100 Currently, Software Install uses the direct authorisation scheme to validate OCSP responders, with a UID allocated for |
|
101 Software Install OCSP signing. |
|
102 |
|
103 Embedded packages are verified using the same logic as is used for the outer package. |
|
104 |
|
105 @subsection installing_software Installing software |
|
106 |
|
107 Software Install first validates the @ref certificate in the install file by using the certificate validation module. |
|
108 @li If revocation checking is switched off, a warning is displayed giving options to do revocation checking anyway, |
|
109 continue without revocation checking, or cancel installation |
|
110 @li If revocation checking is switched on, or the user requests it, all certificates in the chain except the root will |
|
111 be checked for revocation, while Software Install displays appropriate feedback to the user about the owner(s) of |
|
112 the certificate(s) being checked. |
|
113 |
|
114 Future implementations may check multiple certificates with a single OCSP request, however at present, one network access |
|
115 is made for every certificate checked; each one has the potential to generate a warning or error. |
|
116 |
|
117 @li If the OCSP client indicates that no certificates have been revoked and the operation completed successfully with |
|
118 no errors or warnings, the software can be installed |
|
119 @li If OCSP indicates that any of the certificates have been revoked, or if the signature on the OCSP response is invalid, |
|
120 a security error will be issued and the software cannot be installed |
|
121 @li If the revocation status of a certificate cannot be determined (e.g. due to lack of network access, or a OCSP responder |
|
122 error), the behaviour will be as if the software is unsigned. (That is, if unsigned software may be installed, issue a |
|
123 warning but allow installation, otherwise issue an error and do not allow installation.) |
|
124 |
|
125 @section configuration Configuration |
|
126 |
|
127 The Software Install component is responsible for storing the address of the OCSP server, and a flag indicating whether |
|
128 OCSP checking should be performed. The address of the OCSP server is a user-modifiable URL set initially from a |
|
129 localisable default. |
|
130 The InstCtrl dialog contains a 'Security' tab, as shown below. The 'Server address' line is greyed out when the |
|
131 'Enabled' checkbox is clear. |
|
132 If checking is enabled, the server address is parsed when the dialog is closed, to check that is a valid URL. A warning |
|
133 dialog is presented if it is not (text = 'Invalid revocation server URL') and focus moved to the server address field, |
|
134 ready for the user to change its contents.\n\n |
|
135 |
|
136 @image html Certman_OCSP_SoftwareInstall.png |
|
137 \n\n |
|
138 |
|
139 |
|
140 */ |