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.
Wouter
_______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
