[xmlsec] XMLsec Command Line Utility and MSCrypto
Aleksey Sanin
aleksey at aleksey.com
Thu Sep 18 12:57:21 PDT 2003
>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 might be wrong here but I believe that in a crypto system you have to
have only one key for
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,
>possibly with a (limited?) support from the command line.
>
Hm.. what kind of parameters? There is already a parameter called
"--crypto-config". In NSS
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.
>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?
>
Well, I see two options in your questions. Not sure which one you meant
so I'll discuss both:
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
More information about the xmlsec
mailing list