|
1 /** |
|
2 @page mainpage_certman Certificate Management |
|
3 \n |
|
4 |
|
5 The certificate management component comprises: |
|
6 |
|
7 @li @ref UnifiedStores |
|
8 @li @ref certman_certstore_index |
|
9 @li @ref overview_OCSP |
|
10 @li @ref overview_WTLS Certificate Validation |
|
11 @li @ref Certman_X509_Certificate_Validation (and PKIX) |
|
12 @li @ref crypto_DLL_overview |
|
13 |
|
14 <hr> |
|
15 |
|
16 @section Overview |
|
17 |
|
18 The main purpose of certificate management is to provide validation services according to the @ref PKIX @ref certificate and |
|
19 @ref CRL profile for public keys given the following: a set of one or more @ref EE "End Entity" (EE) and intermediate |
|
20 @ref CA_certificate "Certification Authority certificates" supplied by an EE, and a local store of |
|
21 @ref CA certificates which are directly trusted by the user (@ref root_certificate "'root' certificates"). |
|
22 |
|
23 Services provided by Certificate Management include: |
|
24 @li Storage and retrieval of certificates |
|
25 @li Assignment of trust status to certificates on an application by application basis |
|
26 @li Certificate chain construction and validation |
|
27 @li On-line certificate revocation checking. |
|
28 |
|
29 |
|
30 A subsidiary role of certificate management is to enable users to add and delete @ref root_certificate "root certificates", |
|
31 and edit their trust settings. |
|
32 |
|
33 |
|
34 |
|
35 Public key certificates are a way to bind a public key to an entity, such as a person or a server. The certificate |
|
36 management module provides the following services: |
|
37 @li Assignment of trust status to a certificate on an application by application basis |
|
38 @li Certificate chain construction and validation. |
|
39 |
|
40 Both X.509v3 and WTLS format certificates are supported. The architecture allows for other certificate formats and |
|
41 profiles to be added in the future. |
|
42 |
|
43 <hr> |
|
44 @section certman_cert_storage Certificate Storage |
|
45 |
|
46 Certificate storage uses the cryptographic token framework. It comprises the following components: |
|
47 |
|
48 @section certman_cert_storage_scc security/certman/certstore |
|
49 |
|
50 This is an existing component (in both v7.0 and v7.0s) that provides a unified certificate store. |
|
51 The unified certificate store unifies all the available implementations of the certificate storage interface. If a product |
|
52 manufacturer implements one of the certificate storage interfaces using, for example, WIM, then it will automatically be |
|
53 picked up by the unified certificate store. |
|
54 |
|
55 @section certman_cert_storage_scf security/certman/filecertstore |
|
56 |
|
57 This is an existing component (in both v7.0 and v7.0s) that provides an implementation of the certificate storage interface. |
|
58 |
|
59 The file-based certificate store implementation of the writable interface is entirely in software. It uses the device |
|
60 memory to store certificates: this supports user and CA, X.509 and WTLS certificates, and certificate URLs. |
|
61 Multiple concurrent users of the filecertstore are allowed. It is possible for one application to have read/write access |
|
62 to the interface when other applications have read-only access, thus access to database is rarely blocked. |
|
63 |
|
64 @section certman_cert_storage_scw security/certman/wapcertstore |
|
65 |
|
66 This was a component (in both v7.0 and v7.0s) that provided an implementation of the certificate storage interface. This |
|
67 implementation of the read-only interface provided access to the store of WTLS certificates used by the WAP Stack in |
|
68 Symbian OS. This component will be removed in Zephyr |
|
69 |
|
70 @section certman_cert_storage_xcv X509 Certificate Validation |
|
71 |
|
72 X509 certificate validation is supported according to the PKIX certificate profile [PKIX]. Since all objects defined in |
|
73 PKIX are specified using ASN.1, the certificate management component includes functionality that translates between ASN.1 |
|
74 and native Symbian OS data types. |
|
75 The component also provides services for the handling of X500 distinguished names. |
|
76 |
|
77 The following functionality is supported: |
|
78 -# Ability to parse a set of X.509 certificates sent from their binary encoded form into a form in which they are useful, |
|
79 and in which client code can extract interesting information (e.g. name information). |
|
80 -# Use of these certificates to construct a chain back to a locally stored trusted root certificate. |
|
81 -# Validation of this chain. |
|
82 |
|
83 The certificate validation algorithm processes the following X.509 extensions: |
|
84 -# Basic Constraints |
|
85 -# Subject Alt Name |
|
86 -# Issuer Alt Name |
|
87 -# Key Usage |
|
88 -# Name Constraints |
|
89 -# Policy Constraints |
|
90 -# Certificate Policies |
|
91 -# Policy Mapping |
|
92 -# Authority Key Id |
|
93 -# Subject Key Id |
|
94 -# Extended Key Usage |
|
95 |
|
96 This is existing functionality (in both v7.0 and v7.0s) that is provided by the combination of the following three |
|
97 components. As these components are not new for Zephyr, they will be documented within the new functional specification |
|
98 template later. |
|
99 |
|
100 <hr> |
|
101 @section certman_ocsp OCSP |
|
102 This is an existing component (in both v7.0 and v7.0s) that enables application code to check the revocation status of a certificate using the Online Certificate Status Protocol [OCSP]. |
|
103 Although it is currently only used by Software Install, it is a generic OCSP client. It is transport-agnostic, but the only transport supplied by default is HTTP. |
|
104 |
|
105 |
|
106 @section certman_ocsp_auth_info_access Authority Info Access |
|
107 |
|
108 @code |
|
109 <security>/<ocsp>/001.001 |
|
110 TITLE AuthorityInfoAccess |
|
111 PARENT REQ <8.0>/<1890> |
|
112 STATUS Implemented |
|
113 DESCRIPTION The ocsp module supports the X509 certificate extension "AuthorityInfoAccess", which allows the location of an |
|
114 OCSP responder to be specified in a certificate. |
|
115 @endcode |
|
116 |
|
117 The ocsp module supports the AuthorityInfoAccess extension. When an ocsp check is made, there is an option to use this extension, if present, to determine the OCSP server to contact. |
|
118 |
|
119 This functionality is implemented in v7.0s but not in v7.0. |
|
120 |
|
121 @section certman_ocsp_indiv_ocsp_req Individual OCSP Requests |
|
122 |
|
123 @code |
|
124 <security>/<ocsp>/001.002 |
|
125 TITLE Individual OCSP Requests |
|
126 PARENT REQ <8.0>/<2174> |
|
127 STATUS Implemented |
|
128 DESCRIPTION The ocsp module uses individual ocsp requests for each certificate in a multi-certificate chain. |
|
129 @endcode |
|
130 |
|
131 The ocsp module makes individual requests for the status of each certificate when checking a certificate chain. A summary |
|
132 result is made available to the client, as well as the results of the individual transactions. |
|
133 |
|
134 This functionality is implemented in 7.0s but not in 7.0. |
|
135 |
|
136 |
|
137 */ |