[xmlsec] XMLsec Command Line Utility and MSCrypto
ed.shallow at rogers.com
Thu Sep 18 21:00:07 PDT 2003
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 ?
From: xmlsec-admin at aleksey.com [mailto:xmlsec-admin at aleksey.com] On Behalf
Of Aleksey Sanin
Sent: September 18, 2003 8:58 PM
To: xmlsec at aleksey.com
--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
"--privkey" option *does not* select the key for crypto operation.
Sorry, I don't understand
what do you want.
Edward Shallow wrote:
> 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
>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
> 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.
>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
> 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
> - 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
>Hope this make things a little bit more clear :)
xmlsec mailing list
xmlsec at aleksey.com
More information about the xmlsec