beldmit at cryptocom.ru
Tue Feb 14 01:21:00 PST 2006
On Mon, 13 Feb 2006, Amiler Scumba wrote:
> > I've found out it's necessary to call CryptAcquireCertificatePrivateKey
> > with CRYPT_ACQUIRE_COMPARE_KEY_FLAG instead of
> > CRYPT_ACQUIRE_USE_PROV_INFO_FLAG. It should be done in some particular
> > cases, for example, when private key is placed in hardware token
> Can you describe the scenario you were testing. What kind of token were you
We have our own token containing private key.
The description of the scenario:
1. We created 2 different keys using 2 different tokens.
2. We formed the template passing the cert matching to the 1st key.
3. We signed the template. When the provider asked for a token, we
plugged the token contained the key non-matching to the cert.
The document was signed successfully but the signature couldn't be
verified with the cert from template.
> We have found out, that
> CryptAcquireCertificatePrivateKey(CRYPT_ACQUIRE_COMPARE_KEY_FLAG) does not
> work well when the certificate is generated on the machine, imported into the
> hardware token and then removed from the disk. (Please note, that when
> deleting the certificate trough Internet explorer, the private key still
> remains on disk!). If you later register the certificate from the hardware
> token and user CryptAcquireCertificatePrivateKey, the private key from disk
> will be used if then token is not inserted into the computer. Clearlly, this
> is not the desired ehaviour.
Which token do you use? Which CSP do you use? And why do you use disk as
intermediate storage? What do you use to bind cert whis corresponding
> To get around this problem (users complaining: Hey, how can I sign something
> if I did not insert the smart card) we had to use the following sequence on
> the certificate context:
Has the signing operation been really completed?
> In ideal word, it should be possible to pass addtional parameters to the
> ms-crypto provider (see my enx post).
I agree with you. But I didn't find a simple way to pass extra
parameters to the function.
SY, Dmitry Belyavsky (ICQ UIN 11116575)
More information about the xmlsec