Hi, It's very interesting that you got this far. It's on my list to test this out sometime in the future. Didn't you get problems with the default CSP that is selected with the MS CryptoAPI implementation? I can remember from earlier tests (not with xmlsec lib) that you explicitly had to select a certain provider here, and that is not configurable at this moment with xmlsec lib (+ mscrypto).
About the CryptDuplicateKey problem, you're right, it is not really needed. However the problem that might occur when you just copy the reference is that on destroying 1 key context, the key might be rendered invalid in the other context (was that the problem with encryption?). A solution here could be to create some kind of reference count for this context (I didn't find any evidence that ms crypto api supported refcounts for keys). I think it can be done via the _xmlSecMSCryptoKeyDataCtx struct. This refcount must be shared between the different key contexts. My only question right now would be: Do we need to synchronize access to this context (I think not)? Wouter > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, March 31, 2004 18:24 > To: [EMAIL PROTECTED] > Subject: [xmlsec] Microsoft CAPI support with hardware token > > > How much testing has been done of xmlsec with hardware token > in the Microsoft CAPI ? > > Can some people on the list report case of success/failure > they have seen ? > > I tried to use it with an USB ActiveCard smart card reader, > unfortunately not > successfully. > The problem is caused by the fact the ActiveCard CSP does not > support the > CryptDuplicateKey call that is made inside > xmlSecMSCryptoKeyDataDuplicate. > This causes problems for both signature and encryption. > > I wonder how really required the call is. > > The Microsoft doc seems to imply that this function is only > really required to > be able to change with CryptSetKeyParam the parameters of the > copy of a session > key, and then be able to use the same key with two different > set of parameters. > > There should be no need of a session key for signature part, > and a test hack of > just copying the key handle instead of duplicating the key > was quite successful > for the signature, but still leaves some problems for the encryption. > _______________________________________________ > xmlsec mailing list > [EMAIL PROTECTED] > http://www.aleksey.com/mailman/listinfo/xmlsec > _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
