[epoint] Re: [issue] Verifiability of transaction database correctness

From: Daniel A. Nagy <nagydani_AT_epointsystem.org>
Date: Mon, 16 Jul 2012 11:57:42 +0200

Hi,

There are no urgent action points in this email, I am just writing it
for the record so that the issue does not get forgotten.

On 07/15/2012 02:17 AM, Daniel A. Nagy wrote:
> There are two things that can be verified with gpg: the signature on
> certificates and their hash value (without the signature).

I would like to address the first part. Right now, in order to verify
the signature, one needs to either download the public key from a URL
like this one:
http://epoint.vems.hu:1111/key/A723B6BA44846FFD07E7C72519E71669D7BE1DDB
where the key id is derived from the document itself, for example the one at
http://epoint.vems.hu:1111/cert/39BFAA8C8C57A0C95EF121967D9B8F6DEDBDAF67
or after quite a bit of configuration on both ends (server and client)
use the transaction server as a HKP keyserver from which keys can be
downloaded automatically for signature verification.

There is an interesting thing in OpenPGP (RFC4880, section 5.2.3.18)
that gpg extends to document signatures as well. You can add an explicit
http url from which the public key can be fetched using the
--sig-keyserver-url option and gpg will fetch the key, when verifying
such a signature. You can try.

Unfortunately, gpg puts this into a hashed subpacket and ignores this
subpacket, if unhashed, which is actually not a very reasonable thing to
do. I have filed a bug report:
https://bugs.g10code.com/gnupg/issue1417

Including the key URL (as above) in a hashed subpacket would create a
problem similar to the one that we had with the old issuer server;
migration would become problematic. So that might not be a reasonable
thing to do.

Including an unhashed subpacket, like in the attached example, is
useless for the moment, because gpg ignores it. If, however, a new
version of gpg will start interpreting keyserver URLs in unhashed
signature subpackets, then we might want to add this feature to make
verification even more straightforward.

Cheers,

-- 
Daniel



Received on Mon Jul 16 2012 - 11:57:42 CEST

This archive was generated by hypermail 2.3.0 : Sat Sep 14 2013 - 19:00:04 CEST