diff -r 48780e181b38 -r 578be2adaf3e Symbian3/PDK/Source/GUID-0F4DE9E0-4A98-5914-9AB1-DD6CE1A5A1F3.dita --- a/Symbian3/PDK/Source/GUID-0F4DE9E0-4A98-5914-9AB1-DD6CE1A5A1F3.dita Tue Jul 20 12:00:49 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-0F4DE9E0-4A98-5914-9AB1-DD6CE1A5A1F3.dita Fri Aug 13 16:47:46 2010 +0100 @@ -1,80 +1,80 @@ - - - - - -Unified -Stores Overview -

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.

-
Programming with the Certificate Store and the Key - Store

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); -
-
APIs

The following table provides information on -the APIs for the unified certificate store and the unified key store.

- - - -API -Description - - - - -

CUnifiedCertStore

-

This class provides a unified view of all the certificate store -implementations in the device.

-
- -

CUnifiedKeyStore

-

This class provides a unified view of all the certificate store -implementations in the device.

-
- - -
+ + + + + +Unified +Stores Overview +

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.

+
Programming with the Certificate Store and the Key + Store

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); +
+
APIs

The following table provides information on +the APIs for the unified certificate store and the unified key store.

+ + + +API +Description + + + + +

CUnifiedCertStore

+

This class provides a unified view of all the certificate store +implementations in the device.

+
+ +

CUnifiedKeyStore

+

This class provides a unified view of all the certificate store +implementations in the device.

+
+ + +
\ No newline at end of file