Hi, Aleksey is right here. Currently the key or certificate can be loaded by giving it's keyname. However there are a few angles here (when I use certificate, I mean actually certificate *with* public/private keypair, since the certificate is the identifier for the keys with MS):
If more then 1 certificate is available in your certificate store with 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. I think there is a need to load the keys with other parameters as well, possibly with a (limited?) support from the command line. I think for example that the NSS Keys database also can benefit with a more generic interface in the loading of keys (for example using another then default key db)? I was thinking about a more generic approach here where some kind of 'search parameter(s)' can be set for finding keys (and possible certificates) (setKeySearchParameter(enum searchType, *value)). The type of search parameters supported by a keys manager can be different for each keys manager. This story is a bit vague probably, and interferes perhaps with the keyinfo context, but I had no clear idea yet, how this can fit in the xmlsec library. 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? Wouter > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Aleksey Sanin > Sent: Thursday, September 18, 2003 21:12 > To: Edward Shallow > Cc: [EMAIL PROTECTED] > Subject: Re: [xmlsec] XMLsec Command Line Utility and MSCrypto > > > I am not sure I clear understand what do you want to do. The > "--pkcs12", > "--privkey", etc. > just load the key from a file and put it into the keys > manager. The key > then could be refered to > by name from xml files. If I understand the MSCrypto implementation > correctly, you should > be able to refer to the exsiting key in MS Crypto store by > name w/o any > special "loading" > because default keys manager for MSCrypto does look for key > in MS Crypto > store. > > Wouter? > > 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
