S_InitializeDefaultCSP2 initializes this service provider for PKCS #11 support, in addition to all the functionality supported by S_InitializeDefaultCSP .

To initialize or register the Cert-C Default Cryptographic service provider, call the C_InitializeCertC or C_RegisterService function. Both functions take SERVICE_HANDLER and a POINTER to a parameters structure. The Initialize member in SERVICE_HANDLER points to the S_InitializeDefaultCSP function or to the S_InitializeDefaultCSP2 function. Also, the corresponding POINTER should either point to a CRYPTO_PARAMS structure or NULL_PTR when using the S_InitializeDefaultCSP function, or to a PKCS11_CRYPTO_PARAMS structure when using the S_InitializeDefaultCSP2 function. It also can be NULL_PTR. The S_InitializeDefaultCSP function with a NULL_PTR uses the default seeding algorithm.

Both the initialization functions initialize the Cert-C Default Cryptographic service provider’s implementation of the cryptographic service provider's functions. They each store pointers to them in the crypto member in SERVICE_FUNCS, which is a CRYPTO_FUNCS structure. Never call S_InitializeDefaultCSP or S_InitializeDefaultCSP2 directly.

Crypto-C API and CryptoAPI Initialization

Use the S_InitializeDefaultCSP function to initialize the Cert-C Default Cryptographic service provider when the application should access Crypto-C APIs and Microsoft's CryptoAPI cryptographic service provider's functionality, to support client cryptographic function calls. S_InitializeDefaultCSP takes initialization information, which is passed through CRYPTO_PARAMS. When using this service provider, or when performing any cryptographic operations that involve it, be sure to link in the crypt32.lib library from Microsoft.

The application will not be able to access any PKCS #11 functionality when the Cert-C Default Cryptographic service provider is initialized using S_InitializeDefaultCSP.

The Microsoft CryptoAPI cryptographic service provider is integrated using the BHAPI interface. The certificate features of CryptoAPI are integrated through the Cert-C CryptoAPI Database service provider.

The integration of CryptoAPI into Cert-C allows direct support for the RSA Keon Desktop with its virtual or physical smart cards. It also supports access to other keys created using CryptoAPI by applications such as Microsoft Outlook Express. The keys and cryptographic processing can also reside on any smart card (for example, GemPlus) that supports the Windows 2000 smart card interface to CryptoAPI.

Public-key information is always exportable from the CryptoAPI key containers, because it is translated into an equivalent Crypto-C key object; all public-key operations are implemented with the Crypto-C software. If the CryptoAPI private key can be exported from its key container, it too is implemented by Crypto-C. However, if the private key is not exportable (for example, if it resides on a smart card that does not allow the key to be exported), then the Cert-C functions convert the key into a Crypto-C KI_Token key object that has the information necessary to identify the CryptoAPI key container.

Cert-C sets up the session chooser for Crypto-C so that operations involving these token keys will be handed off to a BHAPI module. The BHAPI module invokes the CryptoAPI functions to perform the request operation. In this way, an application that uses Cert-C and CryptoAPI does not need to know the location of the private key. Pass a Crypto-C key object and call the usual Crypto-C functions to perform signature or enveloping operations. Underneath, the BHAPI module recognizes the CryptoAPI key token and uses CryptoAPI functions to perform the desired task.

Microsoft users should note that the rsacsp.h header file also includes several definitions taken from the wincrypt.h header file. Cert-C includes these definitions so that it is not necessary to include the wincrypt.h header file when using a Microsoft platform. If the wincrypt.h header file is included, then it is necessary to allow for language extensions in the compiler. For functions specific to a Microsoft platform, see Cryptographic Functions for the Microsoft Environment

PKCS #11 Initialization

Use the S_InitializeDefaultCSP2 function to initialize the Cert-C Default Cryptographic service provider when the application should have direct access to third-party PKCS #11 libraries and tokens, and use RSA and DSA private keys on those tokens. In addition to the functionality provided through S_InitializeDefaultCSP. S_InitializeDefaultCSP2 takes application supplied library and token information which is passed through the PKCS11_CRYPTO_PARAMS structure.

RSA BSAFE Crypto-C 5.2 or higher is required to use Cert-C PKCS #11 functionality. However, PKCS #11 support for nCipher nForce on Solaris 8, Chrysalis Luna CA3 on Windows 2000 Professional and Solaris 8, and RSA SecurID 4100 Card/SecurID Passage 3.2 on Windows 2000 requires RSA BSAFE Crypto-C 6.0 or higher.

When the Cert-C Default Cryptographic service provider is initialized, an enhanced chooser is created with Crypto-C AM's that can recognize keys stored on a token, and can use the token routines to perform cryptographic operations with those keys.

PKCS #11 object-handling services (for example, finding a key or certificate) are integrated through the Cert-C PKCS #11 Database service provider. In this way, most of the PKCS #11 implementation details are hidden from the application. The application only needs to pass Crypto-C key objects, and call the usual Crypto-C routines to perform signature and enveloping operations. Underneath, Crypto-C will recognize the key as a PKCS #11 object and use the specified library and key to perform the desired task.

Currently, this service provider can be initialized to access only one token.