Dmitry,
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
using? 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.
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:
- provinfo =
CertGetCertificateContextProperty(..,CERT_KEY_PROV_INFO_PROP_ID,...)
- CryptAcquireContext(hProvider,provInfo.pwszContainerName,
provInfo.providerNameA, provInfo.dwProvType,....)
The described algorithm is also used by Microsoft Internet Explorer ann
Microsoft Outlook. (we have verified this with the debugger).
I was not aware that the CryptAcquireCertificatePrivateKey supports
CRYPT_ACQUIRE_USE_PROV_INFO_FLAG. It might implement an algorithm similart
to the one I have described above.
To summarize: Can you describe the scenario where
CRYPT_ACQUIRE_USE_PROV_INFO_FLAG. was causing problems. We wouls like to
reproduce it in our lab.
In ideal word, it should be possible to pass addtional parameters to the
ms-crypto provider (see my enx post).
Amiler.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
xmlsec mailing list
xmlsec@aleksey.com
http://www.aleksey.com/mailman/listinfo/xmlsec
