If more then 1 certificate is available in your certificate store withI might be wrong here but I believe that in a crypto system you have to have only one key for
the same name (I think it's even quite a big change that will happen),
only the first found will be loaded.
If you look for a certificate that does not reside in your personal
local default store, it will not be found.
a given key name (this includes one certificate too). I really don't like the idea of something like:
try first key, if it does not work, try second key, if it does not work, try third key, ... until correct
key is found. Not to mention performance issues around that.
I think there is a need to load the keys with other parameters as well,Hm.. what kind of parameters? There is already a parameter called "--crypto-config". In NSS
possibly with a (limited?) support from the command line.
keys this parameter determines the path to NSS keys and certs DB files. Probably it should
be generalized and, for example, in MSCrypto case this could be certs store name.
Internaly, application might initialize or set parameters in crypto specific keys manager (keys store)
object to search, say, in particular MS Crypto certs store. But it's crypto specific again and
I don't think there is any generalization possible.
Well, I see two options in your questions. Not sure which one you meant so I'll discuss both:Another (a bit related) thing I ran into is the lack of support for loading keys from memory. I know OpenSSL crypto implementation supports this feature, but it isn't propagated in the generic interface. Are there plans into this direction?
1) load key in xmlsec from memory blob with a key in PKCS12, PKCS8, etc.
I have no problems with this. I am not sure that NSS allows this (Tej?) but probably we can
file an RFE against it and have this functionality unsupported by NSS meantime.
2) load key in xmlsec from crypto key representation
There is a problem: this is a crypto engine specific stuff. Each crypto engine stores
keys in memory in its own format. The only way I can think of doing this is to use void* pointer
in xmlSecCrypto* function. But when one decides to use s/he would have to write crypto specific
code anyway. Thus s/he might use specific xmlSecMSCrypto* or xmlSecOpenSSL* function as well.
And void* hides the type information from compiler thus it's a good way to make a mistake.
Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
