[xmlsec] mscrypto 1.2.18 key is not found
ed.shallow at gmail.com
Tue Jun 21 22:12:56 PDT 2011
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,
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,
> 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:
>>> throughout the above tests. it is clear that the mscrypto code somewhere
>>> after 1.2.13 has introduced the error.
>> 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 .
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xmlsec