[xmlsec] mscrypto 1.2.18 key is not found

[EdShallow]

PostScript ...

    Really, this behavior should be paramaterized via a setter method on a
SILENT flag exactly as MS does it.

Cheers,
Ed

On Mon, Jul 11, 2011 at 10:35 PM, EdShallow <ed.shallow at gmail.com> wrote:

> OK guys, I found the source of the changed behavior in 1.2.18
>
> It is in certkeys.c and relates to the SILENT flag below ...
>
>         if (!CryptAcquireCertificatePrivateKey(pCert,
>                     CRYPT_ACQUIRE_SILENT_FLAG |
> CRYPT_ACQUIRE_COMPARE_KEY_FLAG,
>                     NULL,
>                     &hProv,
>                     &(ctx->dwKeySpec),
>                     &fCallerFreeProv)) {
>                 xmlSecError(XMLSEC_ERRORS_HERE,
>                             NULL,
>                             "CryptAcquireCertificatePrivateKey",
>                             XMLSEC_ERRORS_R_CRYPTO_FAILED,
>                             XMLSEC_ERRORS_NO_MESSAGE);
>                 return(-1);
>
> If one removes the CRYPT_ACQUIRE_SILENT_FLAG and re-compiles, then the old
> behavior can be achieved. In other words, with the removal of this flag, one
> will be prompted for the MSCRYPTO KeyName and password to login to (i.e.
> acquire) the key-pair as was the case with XMLSec 1.2.13 where this was the
> default behavior.
>
> Hope this helps those using XMLSec on the workstation as opposed to on the
> server where clearly a modal dialog prompt is not desirable.
>
> Cheers,
> 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
>
>


-- 
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...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20110711/cf1d07f5/attachment-0001.html>