Re: [xmlsec] XMLsec Command Line Utility and MSCrypto
The xmlSecKeyInfoCtx is used to store all context information related to the key search. This includes private xmlsec data as well as application specific data. For example, an application that uses database for storing key might want to put database session handle in the xmlSecKeyInfoCtx if it uses multiple connections to database for each thread. All key requirements (key name, public or private, key size, etc.) are in the xmlSecKeyReq object. I am not sure I understand what do you mean by the KeyInfoCtc has a keyname. Aleksey Currently the implementation is not complete, since keyInfo Ctx is not used yet to search for keys in the MS Cert store, but I'm not sure if that is needed: Is there a possibility that the KeyInfoCtx has a keyname in it, while the separate keyname parameter in the function call is null? ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
RE: [xmlsec] XMLsec Command Line Utility and MSCrypto
What I mean is (or better said what I'm asking is): The function xmlSecXXXKeysStoreFindKey has the following parameters: mlSecKeyStorePtr store, const xmlChar* name, xmlSecKeyInfoCtxPtr keyInfoCtx My implementation of this function is that first an instance of the simple keysstore is called with the given parameters, then (when not key is found) only the given name is used to search a key in ms certificate store. Debugging a test session, I discovered that the simple keys store does more: First the name is used to search for a key. When that fails, the keyInfoCtx is used to search for a match of a key in the keysstore. For example if keytype and keysize are matched with a key found in the keysstore, then that key is returned. My question is should I when searching a key in the MS Certificate store follow the same process: First trying to locate a key based upon the given name, and if no name is given try to locate a key in the store that matches the data like the simple keys store does. I don't know exactly what data found in a keyInfoCtx can be used for that, and I'm even wondering if I should implement this behaviour. So in short: What behaviour is to be expected from this function? Wouter -Original Message- From: Aleksey Sanin [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 17:28 To: Wouter Cc: [EMAIL PROTECTED] Subject: Re: [xmlsec] XMLsec Command Line Utility and MSCrypto The xmlSecKeyInfoCtx is used to store all context information related to the key search. This includes private xmlsec data as well as application specific data. For example, an application that uses database for storing key might want to put database session handle in the xmlSecKeyInfoCtx if it uses multiple connections to database for each thread. All key requirements (key name, public or private, key size, etc.) are in the xmlSecKeyReq object. I am not sure I understand what do you mean by the KeyInfoCtc has a keyname. Aleksey Currently the implementation is not complete, since keyInfo Ctx is not used yet to search for keys in the MS Cert store, but I'm not sure if that is needed: Is there a possibility that the KeyInfoCtx has a keyname in it, while the separate keyname parameter in the function call is null? ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] XMLsec Command Line Utility and MSCrypto
So in short: What behaviour is to be expected from this function? Basicaly the diea was that we are trying *hard* to find a key that matches our request. I think that it's ok to stop search if the key is not found in the store by name. As I wrote before, searching key by key type, key size, etc. is not a good idea in general. The only reason why it was done for simple keys store is that some tests in the test suite do not provide key name. Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
RE: [xmlsec] XMLsec Command Line Utility and MSCrypto
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
RE: [xmlsec] XMLsec Command Line Utility and MSCrypto
I think I got the answer I was looking for, but please explain exactly how (that is with which command line sub-argument) do I identify private and public (or both) keys when doing for example a sign or an encrpyt. In other words today with OpenSSL I just say the following on the command line: sign --pkcs12 keys/EdCert.p12 --pwd 1234 . Or encrypt --pubkey-pem keys/EdPub.pem --session-key des-192 ... What do I say when referring to these keys in the MS world ? Are there subtle command line syntax differences ? Lastly, when using our XMLSec-enabled application in a real MS Crypto Store world there will be no pkcs12s lying around. Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wouter Sent: September 18, 2003 2:37 PM To: 'Aleksey Sanin'; 'Edward Shallow' Cc: [EMAIL PROTECTED] 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 ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] XMLsec Command Line Utility and MSCrypto
--privkey option loads private key in the keys manager. If you already have a key in MSCrypto store *there is no need* to load it in keys manager because in MS Crypto case, keys manager would've search MS Crypto store *anyway*. --privkey option *does not* select the key for crypto operation. Sorry, I don't understand what do you want. Aleksey Edward Shallow wrote: Understood, But isn't the presence of the keys/EdCert.p12 redundant in your example if as you say step 2) makes a formal request of the keys manager to get the cert/key from the MS Crypto Store ? This is a utility-specific question. In the MSCrypto case, I am assuming that Wouter's new implementation will search the MS Crypto Store using the name provided which in MS's case is imply the CN portion of the DN and yes there can be duplicates. But assuming there aren't any ... We are forced to refer to a pkcs12:test-key name and its associated file EdCert.p12 when in fact they will just be ignored when step 2) makes the official request to the crypto-specific keys manager. I am assuming that all keys have already been loaded into the MS Crypto Store and we are now just using the utility. My point is ... why can't we just also allow the generic xmlsec utility to simply specify a name and NOT a key file as an option ... e.g. sign --privkey:test-key --pwd 1234 something.tmpl In the absence of a key file (i.e. keys/EdCert.p12) the utility should just delegate to the default keys manager for cert/key handling. It is a very simple request to have each utility and the associated keys manager do its job based simply on a name search. Ed -Original Message- From: Aleksey Sanin [mailto:[EMAIL PROTECTED] Sent: September 18, 2003 3:24 PM To: Edward Shallow Cc: 'Wouter'; [EMAIL PROTECTED] I can explain what happens in general. Suppose there is a command line like this: sign --pkcs12:test-key keys/EdCert.p12 --pwd 1234 something.tmpl Then the following happens: 1) xmlsec loads key and certificate from keys/EdCert.p12 and puts this key in default crypto keys manager with test-key name. 2) When xmlsec singns the something.tmpl and finds out that it needs a private key with a name test-key, it requests keys manager to find such key (internaly, the request is represented in xmlSecKeyReq object). 3) Keys manager does the search and finds the key we loaded on step 1). 4) xmlsec uses returned key for signature. Note that on step 1) we used words default crypto keys manager. This means that - different crypto engines may have *different* default keys managers (for example, OpenSSL uses plain stupid list of keys; NSS uses the same plain list of keys and NSS key db; MSCrypto uses the same plain list of keys and MS Crypto store) - xmlsec command line utility uses default keys manager but application might replace it with whatever is needed (for example, one might have all keys and/or certificates in a database) Currently, xmlsec utility does not have an option that says load key and use *this* key for signature or encryption. The key selection is done inderectly thru keys manager (i.e. signature/encryption template should have a key name that references to a key in keys manager). But you can do it in your application (if needed) by setting desired siganture/encryption key in signature/encryption context. Also today you can use the --session-key option if you want to sign/encrypt something with session key (specific for this xml file). But the session key by itself would be encrypted with an indirectly selected key from keys manager. Again, in the application you can select second key from your application directly (if you want). Hope this make things a little bit more clear :) Aleksey ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
Re: [xmlsec] XMLsec Command Line Utility and MSCrypto
I am not very familiar with MS Crypto code yet but I would think so. If you have a key with a name Ed Shallow in the crypto store then xmlsec should be able to find it. The private/public is determined by the operation we are doing (encryption/verification -- public, decryption/signature -- private). And I am not sure I clear understand how certificates fit into this picture because this example does not seem to have any. I hope Wouter would correct me if I am wrong :) Aleksey For Ms Crypto, if you simply specify the following in the template, is that sufficient for all cert/key pre-requisites ? Private or public ? Sign and encrypt ? KeyInfo KeyNameEd Shallow/KeyName /KeyInfo ___ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
