CSP

Our CSP translates all certificates to unique containers, where the key type will be set based on the certificate key usage. Some applications have a problem understanding the use of key types and require the use of a specific key type instead of checking the certificate. This parameter allows both key types to be used and will return the same key.

The CSP supports all algorithms available from the PKCS#11 by default, but you can limit this list.

The CSP allows all certificates by default, but there are scenarios when some certificates should be ignored. This parameter specifies the matching condition to be fulfilled to allow a certificate.

An application can ask the CSP for certificates using the memory store. The default behavior is to return success with an empty store, but it can also return an error when no certificates are found.

When calling CryptGetProvParam with the parameters PP_ROOT_CERTSTORE or PP_USER_CERTSTORE, this parameter controls the behavior when no certificates are available.

Our CSP can create and generate new containers. This behavior is not very well documented. Thus, management applications have based their implementation on a specific CSP and expect the same behavior from other CSPs. This parameter was added to avoid the creation of unwanted soft tokens. Usually, the management software is only for smart cards.

The CSP allows all tokens by default, but there are scenarios when some tokens should be ignored. The AllowToken parameter specifies the matching condition.

During token management, there can be an eternal loop because of the behavior of the underlying security system. This parameter is added to avoid this loop.

There is no update detection included in the CSP specifications. Thus, we added a parameter that at least will read the current update counter to detect failures during diagnostics.

The remote/virtual CSP will need to detect which desktop session is using a specific certificate. This is done automatically for processes running within a desktop, but it is not possible for the processes running as services.

The ComponentDisable and ComponentEnable parameters allow the use of conditions to blacklist and whitelist an applications' use of the CSP.

The container name is usually generated from the certificate. But there are applications that have specific requirements on the container name format, so some container name modes are added.

Some applications require a default certificate. Use a matching condition to control the selection.

For diagnostic purposes, you can specify a default PIN value. This value is used instead of opening a PIN dialog.

Some token management applications forget that smart cards have a limited store of potential private keys. This parameter always deletes an existing key before trying to generate a new key.

There are situations when a calling application expects to use a smart card in a smart card reader, but the smart card is not present. Our CSP can show an insert smart card dialog or fail immediately.

Earlier versions of Windows were able to speed up the logging on operations if the CSP did not provide any random values. The CSP can still disable the random generation but fill no purpose.

The CRYPT_SILENT flag tells the CSP not to open any dialogs. But sometimes, the calling application has forgotten that a PIN dialog is needed, so a parameter is added to ignore this flag.

The friendly name is the description that sometimes is used to represent the certificate. This parameter is used to specify the format of this text.

Set KeepConnected to 1 to always keep the PKCS11 component loaded.

The LoadMyself flag is used to load our library one extra time to avoid unloading. This was once recommended by Microsoft for performance reasons but is no longer recommended.

This parameter ignores all internal container names and only uses the default container name. This was needed for some long-forgotten applications.

This parameter identifies the stores to use to read certificates that are not connected with the current user. That is when encrypting to other people.

The provider name parameter specifies the name of the CSP.

This parameter tells the provider type. There are some supported values according to CryptoAPI. We have been using RSA_FULL since the beginning, but we could also use RSA_AES.

The register card prefix tells the prefix to use when registering the supported smart cards.

A calling application can send the PIN to the CSP by using CryptSetProvParam. Normally each attempt will result in a call to the smart card. This parameter can be used to avoid the locking of the PIN. The last failed attempt with a specific PIN value and container will be remembered, and the call will return failed without an attempt to the smart card.

The certificate can be sorted before it is returned to the calling application. This allows some kind of default certificate control but should probably not be used any longer since it only tells in what sequence the CSP will return certificates. The intended purpose is to control the sequence of certificates for a certificate selection dialog, but there are too many layers of interfaces to predict the outcome. For example, the order can be updated by CryptoAPI or the certificate selection dialog.

The StoreContainerName parameter controls the token management application. The used container name can be stored and used later, or it can be ignored and only use the internal format.

A container name is used when opening a context towards the CSP (CryptAcquireContext). It is also possible to get the container name from the CSP (CryptGetProvParam) as either PP_CONTAINER or PP_UNIQUE_CONTAINER. This parameter allows for updating of the retrieved container name.

The UseCritical parameter adds a critical section for each CSP call. It blocks multi-threaded access and makes sure that each call is atomic.

The VerifySignature parameter verifies each created signature. It allows failed verifications but adds a warning message to the trace.