[xmlsec] Big patch to xmlsec in recent OpenOffice.org sources

[Andrew Fan]

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
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec