[xmlsec] mscrypto 1.2.18 key is not found

[Aleksey Sanin]

Sorry, I don't have Windows environment to play with anymore :(

Aleksey


On 6/25/11 10:10 AM, Ed Shallow wrote:
> Any ideas guys ?
>
> Ed
>
> ------------------------------------------------------------------------
> *From:* Aleksey Sanin <aleksey at aleksey.com>
> *To:* EdShallow <ed.shallow at gmail.com>
> *Cc:* Roumen Petrov <xmlsec at roumenpetrov.info>; xmlsec at aleksey.com; 
> Igor Zlatković <igor at zlatkovic.com>
> *Sent:* Wed, June 22, 2011 10:13:00 AM
> *Subject:* Re: [xmlsec] mscrypto 1.2.18 key is not found
>
> Thanks, Ed!
> Aleksey
>
> On 6/21/11 10:12 PM, EdShallow wrote:
>> PostScript ... my motive to upgrade to at least 1.2.15 is my desire 
>> to utilize the new SHA2 algorithms introduced for mscrypto.
>>
>> Thanks in advance for helping,
>> Ed
>>
>> On Wed, Jun 22, 2011 at 1:09 AM, EdShallow <ed.shallow at gmail.com 
>> <mailto:ed.shallow at gmail.com>> wrote:
>>
>>     Some updates with respect to mscrypto 1.2.18
>>
>>     The "key is not found" error with 1.2.18 is misleading. In fact
>>     what is happening is that when specifying a KeyName for a
>>     certificate associated with its private key in a key store that
>>     is not "logged in", you get the "key is not found" error.
>>
>>     If the CSP's container allows you to log in to the key store
>>     prior to usage, then XMSec mscrypto will succeed as long as the
>>     session with the private key has been logged in.
>>
>>     Now please be aware not all CSPs allow you to login in advance of
>>     searching the certificate and adopting the key. In fact most
>>     don't and prompt at first programmatic usage (i.e. adoption or
>>     context acquire).
>>
>>     The only CSP I have tried (and this is how I found the problem)
>>     is Entrust's CAPI CSP called Entrust Service Provider for Windows
>>     version 9.1. If I login to my Entrust key store before running an
>>     XMLSec sign operation, it works. If I am NOT already logged in to
>>     my Entrust key store when I executed the XMLSec command, it
>>     fails. Additionally the error message generated by XMLSec is not
>>     indicative of really what is happening.
>>
>>     The standard Microsoft Cryptographic Service Provider and the
>>     Microsoft Enhanced Cryptographic Service Provider do NOT allow
>>     this login in advance of usage. A login dialog box appears only
>>     when your CAPI code attempts to acquire the certificate context
>>     and use the key for signing. Any use of these 2 CSPs fails with
>>     XMLSec 1.2.18.
>>
>>     This "key is not found" behavior does NOT happen with 1.2.10,
>>     1.2.11, 1.2.13 all of which work fine.
>>
>>     When using these earlier versions of XMLSec, a dialog box with
>>     login prompt is presented as a result of key adoption and
>>     everything works fine after a successful password is entered. The
>>     dialog re-prompts until the correct password is provided. This is
>>     expected behavior.
>>
>>     All this testing was done with Igor's 1.2.18 Unicode=yes binaries
>>     which do not crash but do exhibit the incorrect behavior
>>     described above. I did not test much with the Unicode=no binaries
>>     as soon as I encountered the crashes.
>>
>>     I am not sure what triggers the dialog box with the key
>>     protection password prompt, but this is the error with 1.2.18.
>>     All earlier versions before 1.2.13 DO trigger this dialog box
>>     correctly.
>>
>>     Hope this helps,
>>     Ed
>>
>>
>>
>>
>>     On Tue, Jun 21, 2011 at 4:38 PM, Roumen Petrov
>>     <xmlsec at roumenpetrov.info <mailto:xmlsec at roumenpetrov.info>> wrote:
>>
>>         EdShallow wrote:
>>
>>             OK guys, here is the story with mscrypto:
>>
>>             [SNIP]
>>
>>             throughout the above tests. it is clear that the mscrypto
>>             code somewhere
>>             after 1.2.13 has introduced the error.
>>
>>         [SNIP]
>>         One change , if i remember well , is CP_ACP -> CP_UTF8 . It
>>         is based on request posted to the list.
>>         I don't have environment to test. Probably this could be
>>         issue, but you report ascii(latin1) names and I'm not sure
>>         that this modification is reason for failure.
>>
>>         If "Shallow, Ed" and "Adam Grossman" work fine with 1.2.13
>>         there is not reason to fail if CP_ACP -> CP_UTF8.
>>
>>         Also I'm afraid with report like "openssl sign with .p12 -
>>         crash". I don't know what to say .
>>
>>
>>         Roumen
>>
>>
>>
>>
>>     -- 
>>     Ed's Contact Information:
>>     Mobile Phone: 613-852-6410
>>     Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
>>     VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
>>     VOIP DID#: 613-458-5004
>>     Skype ID: edward.shallow
>>     Home Phone: 613-482-2090
>>
>>
>>
>>
>> -- 
>> Ed's Contact Information:
>> Mobile Phone: 613-852-6410
>> Gmail: ed.shallow at gmail.com <mailto:ed.shallow at gmail.com>
>> VOIP Address: 107529 at sip.ca1.voip.ms <mailto:107529 at sip.ca1.voip.ms>
>> VOIP DID#: 613-458-5004
>> Skype ID: edward.shallow
>> Home Phone: 613-482-2090
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20110625/a4981aa0/attachment.html>