Aleksey ,
I think it might be a time consumer for performance to search a cert from cert store when the cert store is very large. Why not get the certain cert directly by the IssuerName and the SerialNumber? It puzzled me a long time.
Chandler.
Andrew Fan wrote:
Chandler Peng wrote:
Yes, :-) in fact, the current application still don't use this feature, one reason for that is because I find no way to import them into "xmlsecKeyStore". But I hope it should be as it supposed to be while "xmlsecKeyDataStore" also make the it work in a different way. :-P
Chandler, I think it over about the xmlSecMSCryptoAppliedKeysMngrCreate(). You can replace the functions with another wrapper or block with:
{
/* create the key mngr */
xmlSecKeysMngrPtr keyMngr = xmlSecKeysMngrCreate() ;
/* add key store to the mngr **/ xmlSecMSCryptoAppDefaultKeysMngrAdoptKeyStore*( keystore ) ;
/* add cert store to the mngr **/** xmlSecMSCryptoAppDefaultKeysMngrAdoptTrustedStore*( certstore ) ; }
This is not quite correct. As it is implemented in the OpenOffice patch you have sent to me, the xmlSecMSCryptoAppliedKeysMngrCreate function *did not* add keys or certs store passed into it as input parameters. But this might have just a bug :)
I think we're on that different way at some senses. In your codes, line 1, 3, 4, 5 have been wrapped by *xmlSecMSCryptoAppDefaultKeysMngrInit( *xmlSecKeysMngrPtr ), it would be saving call *xmlSecMSCryptoAppDefaultKeysMngrInit() after* xmlSecKeysMngrCreate(). In my cases, "keystore" and "certstore" refer to the input parameters with xmlSecMSCryptoAppliedKeysMngrCreate( HCERTSTORE keystore, HCERTSTORE certstore ). Personally, I would suggest adding the two HCERTSTOREs into key manager.OK, I will replace the function xmlSecMSCryptoAppliedKeysMngrCreate() with a block like this:
{
( line 1 ) keyStore = xmlSecKeyStoreCreate( xmlSecMSCryptoKeysStoreId ) ;
...
( line 2 ) keyMngr = xmlSecKeysMngrCreate() ;
( line 3 ) xmlSecKeysMngrAdoptKeysStore( keyMngr, keyStore ) ;
( line 4 ) xmlSecMSCryptoKeysMngrInit( keyMngr );
( line 5 ) keyMngr->getKey = xmlSecKeysMngrGetKey ; }
Thanks, -Andrew
The interfaces really give more flexible for end user specify their own keys for signature and decryption. I think is is much more useful for template driven signature/encryption, for non-template driven signature/encryption, one can directly call some interfaces to set the keys used to a certain sign/enc; but for template-auto driven, no one knows what even the template stuff, so put the raw keys into the mgr is a good automated way. I think encryption cases will show the value of those interfaces. Because openoffice signature is based on pki cert, they really have not been used. I didn't implement those interfaces in mscrypto engine( I forgot why, because of time or anything else ), but they have been implemented in nss engine.Note that all of the XXXKeyLoad functions you listed have no body at all in the patch that was sent to me thus I did not implement them in xmlsec. I can do it but I am not sure it makes much sense to me :)
Aleksey, I hope you add the interfaces for both mscrypto and nss engine if you feel valuable. :-)
OK, I added mscrypto functions (changed names slightly to follow xmlsec conventions):
xmlSecMSCryptoAppDefaultKeysMngrPrivateKeyLoad xmlSecMSCryptoAppDefaultKeysMngrPublicKeyLoad xmlSecMSCryptoAppDefaultKeysMngrSymKeyLoad
But you promise to implement them one day :)
BTW, just to repeat this to Chandler: to get full compatibility with current OpenOffice patch, one needs to compile xmlsec-mscrypto in "nt4" compatibility mode. Otherwise, you'll have same functionality but it will run only on 95/98 (with necessary SP level), Server 2003 and XP. You can find detailed instructions, reasons and more explanations here:
http://www.aleksey.com/pipermail/xmlsec/2005/002560.html
Also note that "nt4" compatibility mode *migth not* be thread safe.
Aleksey
Thanks , I will test it in openoffice(src680m80) later .
Chandler _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
