InfoPath Signing Bug?

D

Doug Barlow

I can't seem to sign InfoPath documents unless the certificate template is
restricted to 'Signature Only'. Attempts to sign documents with a general
user certificate results in a "Key not found" error.

I can see in the debugger where InfoPath does indeed attempt to sign with
the AT_SIGNATURE key, even if the certificate information says the key
identifier should be AT_KEYEXCHANGE.

If I had a key container with both kinds of keys, presumably it would sign
with the wrong key, producing invalid signatures! Is this a known bug, and
if so, is there a Knowledge Base Article that discusses it?

Thanks,
Doug Barlow
The Soft Pedal Shop
http://www.softpedal.net
 
D

Doug Barlow

I found it myself. When using the Microsoft Software CSPs, the system
service CryptSignHash() returns NTE_BAD_KEYSET if the key doesn't exist.
Other CSPs, such as some of the smart card CSPs that ship with Windows,
return NTE_NO_KEY instead (which makes more sense in the context, but is
historically wrong).

InfoPath only checks for the NTE_BAD_KEYSET return code to see if the key
exists, and aborts on anything else. Since it checks for AT_SIGNATURE keys
first, the error code mismatch never comes up when using Signature-Only keys.

Doug Barlow
The Soft Pedal Shop
http://www.softpedal.net
 
D

Doug Barlow

I should note that it is still very likely that InfoPath has a very serious
bug in its signing code -- it shouldn't be testing for which keys are there
in a container and using the first one it finds; it should be getting the
explicit one to use from the certificate information, and ignoring any others.

For example, if a key container had both a signature key and a key exchange
key, and had a certificate for the exchange key, it appears InfoPath will
sign the document with the Signature key, resulting in the signature being
invalid for the certificate.

Doug Barlow
The Soft Pedal Shop
http://www.softpedal.net
 
Top