[xmlsec] XMLsec Command Line Utility and MSCrypto

[Aleksey Sanin]

--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:aleksey at aleksey.com] 
>Sent: September 18, 2003 3:24 PM
>To: Edward Shallow
>Cc: 'Wouter'; xmlsec at aleksey.com
>
>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
>
>
>
>
>
>
>
>
>
>
>  
>