[xmlsec] XMLsec Command Line Utility and MSCrypto

[Edward Shallow]

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>
  <KeyName>Ed Shallow</KeyName>
</KeyInfo> 



-----Original Message-----
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
*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
>
>
>
>
>
>
>
>
>
>
>  
>

_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com
http://www.aleksey.com/mailman/listinfo/xmlsec