[xmlsec] loading crypto engines as plugins, build changes, etc.

[Igor Zlatkovic]

> It seems we have touched a nerve !!!

You haven't touched a nerve, sorry if it sounded that way. I just expressed
my opinion, that's all. That theory I hold for true, but practice holds
other traps.

At the very end, use what you will. I don't care who reads my email. Much
less do I care who reads yours ;-)

> Love your passion, but Wouter's excellent work in writing to the windows
> CAPI interface (which is simply an interface)
> puts all of us in a position to replace the underlying Crypto Service
> Provider (i.e. CSP) with for example a smartcard vendor's CSP accessing a
> secure hardware token  or smartcard, etc ...
>
> Similarly with the NSS implementation, we are now able substitute PKCS11
> providers and again leverage alternate crypto engines and
> Key storage facilities.
>
> Please tell me how that would be done in an OpenSSL environment with its
> terribly "thin" key storage management ?

Alexey did give an answer to that. And it wasn't what I was talking about.
Sure you can replace the CSP with SC-vendor's version, my question was why
should I trust the vendor's CSP, or any CSP, if I don't see the code?
Whyever, all that has nothing to do with xmlsec, sorry for straying off the
topic.

Ciao,
Igor