[xmlsec] xmlSecMSCryptoKeyDataAdoptCert

Amiler Scumba amiler_scumba at hotmail.com
Mon Feb 13 14:36:17 PST 2006


>I've found out it's necessary to call CryptAcquireCertificatePrivateKey
>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 = 
- 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).


Express yourself instantly with MSN Messenger! Download today it's FREE! 

More information about the xmlsec mailing list