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
