[xmlsec] XMLsec Command Line Utility and MSCrypto

[Wouter]

> 
> >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.

You're absolutely right here, and it must be changed, but let me explain
how it's done with MS:
Since the keys are identified by certificates, the actual search is to
find a certificate. Now MS has thought of a way to give the certificate
a so called 'friendly name', which is nothing more then the CN of the
subject name of the certificate (possibly replaced with some other name
of the certificate, when that is not available). It's easy to search the
cert for, but not unique. The other search option you can think of here
are the same as for 'common' certificates, like full subject DN,
issuer/serial, etc.

> 
> >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.

I didn't know this (oops). I'll look into this. I think it is very
usefull for mscrypto indeed.

> 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.

Ok, I wasn't sure myself if the idea had valid grounds or not. But
regarding the finding of a key through finding the cert: How do you
think we can solve the issue when for example a serial number and issuer
dn as the certificate name should be given (that will *allways* uniquely
identify a certificate). If not braking the current interface, one can
give as the keyname these values seperated by a seperator, like
semicolumn or something. What do you think?

> >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.

This is what I meant, just like it is now already from file, but then
from memory.

Wouter