Difficulty of fixing reconciliation

Andrew Gallagher andrewg at andrewg.com
Wed Aug 14 12:09:17 CEST 2019

On 14/08/2019 10:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong.  It must be possible to delete errors.

Indeed, but that condition is fundamentally incompatible with
decentralised reconciliation - because deletion without permissions
management is an open door, and permissions have to be enforced by an

>> Now we have a deadlock. There is no following step that would
>> fulfill the monotonicity requirement as well as make any progress.
>> The only way to fulfill the monotonicity requirement is when server
>> A keeps the signatures A1 and A2, and server B keeps B1 and B2. But
>> the progression has halted and the process never finishes.
> The illegal sig shall be deleted from both servers.

There are three signatures. Which one is illegal? You can't base your
decision on the contents of any of the signatures, because they're
third-party and therefore untrustworthy. Timestamps can be backdated,
for example.

> I'm no expert, but it seems to me that 3rd party signatures should not
> be allowed.  All signing party recipes provide for /exchanging/ sigs,
> but then rely on the fact that Alice can sign Bob's sig before Bob has
> signed Alice's and without Bob's authorization.  That is, the
> semantics is good, but it's not algorithmically enforced.

There's nothing intrinsically wrong with third-party signatures. The
problem is caused by keyservers allowing a global search on the target
id to include all the third party signatures on it, whether the target
consents or not. Unless you use a maximum trust path length of 1, you
must have some way of searching for intermediates.

> Hm... if your sig is signed by a suspect, you become suspect too?  In
> fact, SKS servers with lots of countersigned sigs is manna from heaven
> for police.

A third-party signature is just a statement by someone saying "I know
this person". Sure, that may make you a suspect by association, but so
does mentioning your name in public, or sending you an unsolicited postcard.

Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190814/3340a7b3/attachment-0001.sig>

More information about the Gnupg-users mailing list