A Symbian platform device may contain zero or more individual certificate stores, and zero or more key stores. Software implementations for both of these are supplied, and device creators may add their own, perhaps using special hardware on the device - for example, using a WIM. The certificate store and key store classes act as central interfaces for certificate and key management, so that application writers do not need to know details of the specific implementations present. These classes automatically discover all implementations of the relevant interface on the device using the crypto token framework.
The certificate and key stores centralize and amalgamate the individual certstore and keystore implementations. The stores are unified in the sense that client requests, which relate to all store implementations (such as "list keys" or "list certificates"), are passed to every implementation in turn, and the results collated. Requests that relate to a specific store are routed to the correct implementation.
Clients should only use the certificate store and key store classes to access certificates and keys. There is no need to use the crypto token framework directly, and although this is possible, it is not recommended.
The ctframework component provides the interfaces for key store and certificate store implementations, and the unified stores themselves are implemented in Certificate Management's (certman's) certstore component. Programs wishing to use the unified stores should therefore be linked against both certstore.lib and ctframework.lib. Note that certstore.lib provides both the unified certificate store and the unified key store.
The software certificate store implementation supplied with the Symbian platform is provided by filecertstore.dll, and this runs entirely in the client application. The software key store runs in a separate server process - this is implemented by fstokenserver.exe, and the client side part that communicates with the server is provided by fstokencli.dll. The unified stores use the ECom framework to load these DLLs automatically, so there is no need to link against them in client applications.
Within the header files for the Unified Certificate Store and the Unified Key Store, most of the functions are asynchronous and this means that clients need to be implemented as active objects to work. All calls to asynchronous functions must be called from the context of active objects - the active scheduler will call the client's RunL() function when the asynchronous function completes.
This means that the following code will not work:
// Broken! TRequestStatus status; certStore->DoSomething(parameters, status); User::WaitForRequest(&status);
The following table provides information on the APIs for the unified certificate store and the unified key store.