Werner Koch <> Fri, 18 February 2011 08:25 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p1I8PBnI059057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 01:25:11 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p1I8PB7d059056; Fri, 18 Feb 2011 01:25:11 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p1I8P9WI059043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <>; Fri, 18 Feb 2011 01:25:11 -0700 (MST) (envelope-from
Received: from uucp by with local-rmail (Exim 4.69 #1 (Debian)) id 1PqLeH-0001Ho-7f for <>; Fri, 18 Feb 2011 09:25:09 +0100
Received: from wk by with local (Exim 4.72 #1 (Debian)) id 1PqLbs-0000Yf-Us; Fri, 18 Feb 2011 09:22:40 +0100
From: Werner Koch <>
To: David Shaw <>
Cc: IETF OpenPGP Working Group <>
Subject: Re: DEADBEEF vs SHA1
References: <>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2;
Date: Fri, 18 Feb 2011 09:22:40 +0100
In-Reply-To: <> (David Shaw's message of "Thu, 17 Feb 2011 14:12:20 -0500")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Thu, 17 Feb 2011 20:12, said:

> import the other one without explicitly deleting the first.  When
> trying to import the second key, GPG fails with "key 689E2211 doesn't
> match our copy".  PGP silently ignores the new key.  Not allowing a
> new key to replace an old one does make some sense (after all, how

Actual this message is here due to my laziness.  A proper implementation
would fallen back to insert that key as a new key.  That would be easy.

The part which requires more work is to change all code looking for a
keyid to iterate over all keyids in the database until it succeeds.  We
do this for example for wildcard keyids.  It turned out that this is
sometimes pretty annoying because the user is forced to enter the
passphrases for all of his keys.  For the case you describe we won't
have this problem but it is nevertheless a lot of work to try all
keyids.  It would be more correct, though.

Disabling v3 import and an option to enable such imports seems to be
justified and is easy to implement.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.