Chandler Peng wrote:
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 :)
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
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 ;
}
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.
Thanks,
-Andrew
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 :)
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.
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
