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
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
