[xmlsec] How to sign without an exportable key

Wouter Ketting wsh at xs4all.nl
Sat Jan 22 13:24:57 PST 2005

> I was thinking about something like this:
> 1) First I retrieve a PCERT_CONTEXT from MSCrypto
> 2) Now I call xmlSecMSCryptoCertAdopt to get a xmlSecKeyDataPtr
> 3) Third I create a new xmlSecKeyPtr by calling xmlSecKeyCreate
> 4) Now I call xmlSecKeySetValue(xmlSecKeyPtr, xmlSecKeyDataPtr)
> 5) I now create a xmlSecDSigCtx using xmlSecDSigCtxCreate
> 6) I can now assign xmlSecDSigCtx->signKey with the xmlSecKeyPtr
> 7) Last I call xmlSecDSigCtxSign

The flow you're describing here can be found in 
xmlSecMSCryptoKeysStoreFindKey. You can use this function as reference. 
You can also use xmlsec directly to load a certificate from MS cert 
store with xmlSecKeysMngrFindKey function (which implicitly calls 
xmlSecMSCryptoKeysStoreFindKey). For the name of the key you can use 
either the "friendly name" (mscrypto tries to define a short name for 
the certificate they call like this, see msdn for more info on this) or 
the complete subject dn of the certificate.

> At what stage will MSCrypto ask me to enter the password in order to 
> encrypt the document (my guess is at stage 7).

You're guessing right :) The password will be asked at the moment the 
private key will actually be used. In this case the sign action.

> If I have several documents that need signing will this method force 
> MSCrypto to prompt me for a password every time or is there a way around 
> this problem? I thought about using a keys manager but I have no idea 
> how to do this and even if it will solve my problem.

This is more or less dependent on the CSP (ms: crypto service provider) 
you're using. If you use the default provider (of ms) then with *each* 
usage of the private key the password will be requested. The only 
workaround I know of (but haven't used) is that with the win xp version 
of ms crypto you can define you're own function that asks for the 
password, and in such a function you could build a caching mechanism for 
the password.
I know of 3rd party CSP's (mainly the ones that support some kind of 
smartcard interface) that have a password caching mechanism available.


More information about the xmlsec mailing list