fdo#87030: Make PDF signing using Windows API work

This is a squash of four commits that incrementally add Windows-specific code
for PDF signing and make it work properly.

1)

Remove noise SAL_WARNs that were not warnings, just informative messages

SAL_DEBUG is what should be used for stuff like that (and not committed).

2)

Started writing a Windows version of PDFWriterImpl::finalizeSignature(). The
certificate we get from the selection dialog (in xmlsecurity) is from the
Windows built-in store anyway, so it is pointless to try to use it with
NSS. (See bug for longer discussion.)

So far it was pretty straightforward. The WinCrypt API seems clean and easy to
use. But for some reason the CryptSignHash() call fails with "Keyset does not
exist" (NTE_BAD_KEYSET). What am I missing?

Anyway, comitting this now as it does compile and doesn't make things worse.

3)

Prevent PDF signing using Windows API from failing

There was one details that I had missed in my initial coding:
CryptAcquireContext() doesn't give you a HCRYPTPROV key container that
would contain the private key of a public key certificate. For that
you need to use CryptAcquireCertificatePrivateKey(). When the hash has
been created using such a HCRYPTPROV, the CryptSignHash() call
succeeds.

The certificate in DER encoding that is passed in from the caller,
obtained in the certificate chooser (in xmlsecurity), is possibly not
good enough to be used for the other things. So look the same (?)
certificate up in the user's key store instead. At least more
properties are present in the certificate when looked up like that.

Add more SAL_INFO logging, with cleartext dumping of certificate
context property names and list of algorithms supported by the CSP.

Unfortunately, even if all the WinCrypt API calls now succeed, the
signatures we produce still are not good enough for Adobe Reader... A
lot of information must be missing, they are quite short, just 256
bytes.

4)

Generate a proper PKCS#7 signature

The signature should be in DER-encoded PKCS#7 format and what CryptSignHash()
produces is nothing like that. Luckily CryptSignMessage() is actually almost
easier to use and is capable of doing what we need. This also means that we
won't need any HCRYPTPROV or HCRYPTHASH after all so all the code related to
that can be removed. CryptSignMessage() handles both calculating the hash and
signing it.

One less than ideal issue with CryptSignMessage() is that it needs all the
data to be hashed and signed at the same time, so we need to keep both buffers
around for signing.

It also turns out that we don't need to look up the certificate anew from the
user's certificate store after all.

Now Adobe Reader doesn't complain any longer about the signature's format and
contents.

Change-Id: I4674805cca2fa9342860e635cb07cbdfddfdb08c
Reviewed-on: https://gerrit.libreoffice.org/13434
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>