[xmlsec] loading crypto engines as plugins, build changes, etc.
ed.shallow at rogers.com
Mon Sep 22 06:39:30 PDT 2003
That is fine Igor. Your reputation precedes you and your comments are always
enthusiastically welcome (at least by me) no matter how far off topic they
might be. Keep up the excellent work. By the way I could not find a specfic
link at the openssl.org site referring to SC or driver vendors with SC/token
support for OpenSSL. I would like to follow this potential path, mainly
because I respect your collective opinions, and I believe there is a valid
point you make.
From: xmlsec-admin at aleksey.com [mailto:xmlsec-admin at aleksey.com] On Behalf
Of Igor Zlatkovic
Sent: September 21, 2003 10:19 AM
To: xmlsec at aleksey.com
> 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
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
xmlsec mailing list
xmlsec at aleksey.com
More information about the xmlsec