[xmlsec] Microsoft CAPI support with hardware token

[Wouter]

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: xmlsec-admin at aleksey.com 
> [mailto:xmlsec-admin at aleksey.com] On Behalf Of xs04.jmdesp at free.fr
> Sent: Wednesday, March 31, 2004 18:24
> To: xmlsec at aleksey.com
> 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
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>