Duplicated User IDs arisen
vedaal at hush.com
vedaal at hush.com
Wed Jun 23 00:00:11 CEST 2004
>Date: Tue, 22 Jun 2004 15:40:05 +0200
>From: Werner Koch <wk at gnupg.org>
>Subject: Re: Duplicated User IDs arisen
>To: gnupg-users at gnupg.org
>Message-ID: <87wu1z7lu2.fsf at wheatstone.g10code.de>
>Content-Type: text/plain; charset=us-ascii
>On Mon, 21 Jun 2004 08:25:28 -0400, David Shaw said:
>> This is similar to a denial of service where the attacker tries
>> prevent a user from getting a key in the first place, in hopes
>> will send a message unencrypted.
>However in the case of a revocation, the user has to no way to decide
>whether to send it unencrypted or not - he will beleive that the
>is still not revoked. Well, this is a general problem with all
>of doing revocations and there is no straight solution for it.
would a possible solution be to have key servers insist on
entering the key id and fingerprint, before executing the search ?
in any event, any key returned by the search should not be used
until confirmed with the key id number and fingerprint,
so this information is usually readily available to the searcher,
and able to be entered into the keyserver search criteria.
under such a system,
there could be 'no' duplicate id's,
and no denial of service spoofs,
(other than a 'malicious' [or 'tampered with and rendered malicious']
keyserver, that, for one reason or other, intentionally 'lists' keys
as revoked when in fact they are not.
a possible solution to this, would be to allow users to download the
'revoked' key anyway, and have the user see from the key packets themselves
that the revocation is genuine,
gnupg would warn the user from encrypting to such a revoked key,
so there would be no threat to the user.)
Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
Promote security and make money with the Hushmail Affiliate Program:
More information about the Gnupg-users