[xmlsec] mscrypto 1.2.18 key is not found

[Ed Shallow]

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> 
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> 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
>>VOIP Address: 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
>VOIP Address: 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/6b3f27e9/attachment.html>