[xmlsec] XMLsec Command Line Utility and MSCrypto

[Aleksey Sanin]

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

Well, selecting a unique key name is an application specific task. Would 
think that key name
can be certificate subject. In this case xmlsec-crypto might do 
following when it needs to find
a key with given name (i.e find a cert with given subject):
    - get "friendly name" from subject;
    - get all certs with this "friendly name";
    - find a cert that has the subject we are looking for.
Using this 'friendly name' as a key name does not sound like a good idea 
to me.


>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?
>  
>
Application specifc problem :) I would think that using cert subject is 
a better idea but
I don't know your environment (MSCrypto API) well enough to evaluate 
these options.

>>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.
>  
>
I have no objections. Do you need help with making changes to the crypto 
functions table?

Aleksey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20030918/5619f815/attachment.htm