[newbie] How to verify gpg4win's own sigs??

I keep getting this error message:

gpg4win-2.1.0-rc2.exe.sig: Not enough information to check signature validity

Signed on 2011-02-04 12:15 by distribution-key@intevation.de (Key ID: 0xEC70B1B8).
The validity of the signature cannot be verified.

when using the command line I get this:

gpg: Good signature from “Intevation File Distribution Key distribution-key@intevation.de
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.

Trying to verify with GPGEx using right-click just opens a Kleopatra window.

Only signatures that I generate locally seem to validate with no problems.

The SHA-1 hash seems to be valid, so I’m sure that there’s nothing wrong with the downloaded exe.

I’m assuming before trying at the command line you used Kleopatra? GpgEX is a shell extension for Kleopatra, to let you access sign/verify/encrypt and other such functions from within a Windows Explorer context menu.

The command line tells the truth: the signature verified OK against the key provided. We just don’t know if we can trust the key.

Stated differently: the signature IS GOOD, but is the key really Intevation’s?

If you believe in the key, there is no need to proceed further. The gpg command line output is good enough, the package has verified.

If you want to make Kleopatra happier, so you don’t have to double-check via command line, you can indicate that you trust the key’s origins and control by certifying it in Kleopatra (also known as signing the key, in the gpg command-line environment).

If you’ve not independently verified the key yourself, you wouldn’t want to make your certification/signature public, just indicate that you “believe” in the key’s authenticity for the purposes of your own personal keyring.

In Kleopatra, you do this by: right-clicking Intevation’s key, and choosing “Certify”. Indicate you’ve verified the fingerprint (you haven’t because they’ve not published it from a trusted source), and choose “Certify only for myself” (known via the command-line as a local signature).

Now, if you repeat the verification of the gpg4win package, you’ll find that this time it verifies with the nice warm-fuzzy green result dialog!

An elaboration on what was happening: The telling bits are the last two lines from the gpg command line tool. These are telling you that the key from Intevation hasn’t been signed by a key on your keyring which you trust, nor have you yourself indicated that you trust this key. Therefore, gpg’s web-of-trust algorithm cannot give you any assurance that Intevation’s key really belongs to, and is controlled by, Intevation.

In this case, we reasonably presume that the key is in fact Intevation’s, because the website explains on the signature page that the signatures were made by this particular keyID, which we presume only Intevation-authorized personnel control.

I think this is a loose, not strictly secure presumption. For more trust, one would want them to demonstrate control of the key.

One way to do this would be to issue a challenge in the form of a secret message known only to you, encrypted with their key, and sent to them. Since they ought to control the private key, they can recover the secret and communicate it back to you (in the open, if they wish). If their report matches what you already know as the creator of the secret, then the challenge is successful.

Another way might be to see the key cross-signed by another key to whom you can issue this type of challenge, if the challenge cannot be made to the file distribution key directly.

A lower security way would be to see the key’s fingerprint, posted on the website, not just the ID, and an even lower security way (the way they provide) is just to see the key ID on the website.

In the case of just matching fingerprints or key IDs from a webpage, we presume the website publishing this data is under the control of the same people/organization as the key we’re trying to authenticate. This is safest if our connection to the website is secured with a trusted SSL certificate, to rule out tampering of the page contents by a man-in-the-middle.

----oh boy, if you’re not bored or if you are paranoid, read on----

Unfortunately, Intevation does not provide SSL for gpg4win.org. This forum, however, is under an SSL certificate, but accepting it still means you’d also have to trust Intevation implicitly, as the certificate is issued by a themselves in their capacity as a non-generally-recognized CA.

I can note that even an untrusted SSL connection (one for which we’ve had to make a temporary exception to allow our browser to accept), is better than a unsecured connection, for that at least greatly reduces (but doesn’t strictly eliminate) the possibility of a man-in-the-middle replacing data and showing us different page contents.

So given all the above, really, we can only be assured that to the extent we believe their website has not been hacked and remains under their control (and DNS hasn’t been redirected to a site under someone else’s control), the data we have downloaded from that site has not been altered or damaged.

I go to the trouble of this long-winded post because I believe that, at least, Intevation ought to provide an SSL option for their signature verification page, and publish a fingerprint for their file distribution key. Even more ideal: have their file distribution key cross-signed by the keys of at least some of the people who are authorized to use it to prepare the install packages. That way there’s a chance that the file distribution key can show up in one of the larger webs-of-trust that exist out there for OpenPGP keys.

All of that would just up the confidence factor. In a practical sense, I’m not really worried.

However, in a real sense, it is now possible for a man-in-the-middle to generate his own file distribution key, create a modified version of the package, and offer this for download along with the key he made. Inserting himself in the middle between the real Intevation website and an individual visitor, rewriting the download link and the signature verification page’s contents to reflect his own key and his own modified software package.

Where could this happen? Anyone connecting in from an ISP or service which uses proxying (espcially SSL-MITM proxying) would make an easy platform, such as inside a corporation’s offices. In that case, the only way for a user behind the proxy, as a target of the man-in-the-middle, to know his software was tampered with, would be comparison of his software with copies downloaded by others from independent networks. A simple hash-comparison would reveal that his software was different from everyone else’s. This might lead him to compare the file distribution key he obtained with the copy other’s have. Finding these different too, he’d finally realize that he’d been the victim of a man-in-the-middle when he obtained the download package.

After following the file distribution key’s signature chain a bit, I saw that the key was signed by two of Intevation’s people, and that their keys were signed by many others, including Werner Koch, who controls a key which signs GnuPG. So this key is completely righteous (of course there was never really any doubt).

I should have done that trace before my last post, which in a certain light might have been unsettling. Mea maxima culpa.

Where can I officially obtain this certificate? I want to check it before checking distribution signature.