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

[Andrew Fan]

Aleksey Sanin wrote:

> Hi, Andrew!
>
> Thanks for your reply! See my comments interlaced with your answers.
>
>>> 0) After applying the patch, I have quite a lot of failures in
>>> xmlsec regression test suite. I wonder if you run the tests and know
>>> the reasons for these failures?
>>>
>> If I correct, the patch doesn't implement app* routines, which are 
>> not used at openoffice, so I don't implement it in time. Because some 
>> APIs have changed or added to the kernel, so it is necessary to 
>> adjust the app* programs. However, I think Channdler and Michael may 
>> be in the implementing process.
>
> Hm.. I don't see any changes to core xmlsec code except the big numbers
> routines changes that are already in xmlsec 1.2.7. May be test errors
> were caused by the new AppliedKeyManager that does not implement all
> of the necessary callbacks?
>
Yes, that's what I mean. Not only the AppliedKeyManager in mscrypto 
engine, but also include some callbacks for nss engine.

>
>>> 1) xmlsec/include/xmlsec/mscrypto/akmngr.c, 
>>> xmlsec/src/mscrypto/akmngr.c
>>> Why do you need "AppliedKeyManager"? How is it different from the
>>> "DefaultKeyManager" and do you think it would be easier to just
>>> merge the two?
>>>
>> The AppliedKeyManager enable user specify their preferred key store 
>> and certificate store. It would be a good idea just simply support 
>> both of the two manager.
>>
> I would really love to merge these two guys together. May be we can just
> add functions to set prefered key/certs store to the DefaultKeysManager
> and provide reasonable defaults as we do now. I believe this way we can
> avoid un-necessary code duplication (see item 0) too).
>
It's a little harder, but definitely better. :-)

>
>>> 2) xmlsec/src/mscrypto/certkeys.c
>>> I understand that you are using refcounting for HCRYPTKEY and
>>> HCRYPTPROV instead of system "duplicate" functionality to support
>>> NT 4.0. However, it seems a little bit dangerouse to me to re-use
>>> the same key handler from multiple threads. Do you know if MS
>>> documentation says anything about this? Did you do any tests in
>>> multithreading environment?
>>>
>> Good suggest, we will do tests on multithreads. Or add some syn 
>> mechanism if necessary.
>>
> Thanks!
>
>>> 3) xmlsec/src/mscrypto/x509.c,
>>> xmlSecMSCryptoKeyDataX509VerifyAndExtractKey function
>>> You commented out the code to get public key from a verified 
>>> certificate
>>> and replaced it with code that gets either public or private key.
>>> I am not sure I understand why would you need a private key for
>>> a "verify cert" operation. It seems impossible to me.
>>>
>> I don't think this function only used to verify, sometime it is also 
>> used to sign. In our cases, all of the signature/encryption process 
>> are controlled by signature/encryption template, the function is 
>> called during signning.
>
> OK, this sounds strange to me. Can you share the templates you use for
> signing and I'll try to investigate this?
>
It's a very simple template,  only including cert issuer and serial 
number. Refer to 
http://xml.openoffice.org/source/browse/xml/xmlsecurity/tools/examples/sign-0.xml?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup

Thanks,
Andrew

> Aleksey
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec