Re: DEADBEEF vs SHA1

Werner Koch <wk@gnupg.org> Fri, 18 February 2011 08:25 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (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 owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p1I8PB7d059056; Fri, 18 Feb 2011 01:25:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1I8P9WI059043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 01:25:11 -0700 (MST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.69 #1 (Debian)) id 1PqLeH-0001Ho-7f for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 09:25:09 +0100
Received: from wk by vigenere.g10code.de with local (Exim 4.72 #1 (Debian)) id 1PqLbs-0000Yf-Us; Fri, 18 Feb 2011 09:22:40 +0100
From: Werner Koch <wk@gnupg.org>
To: David Shaw <dshaw@jabberwocky.com>
Cc: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Subject: Re: DEADBEEF vs SHA1
References: <D8E81788-AF18-448F-BA39-56185C1F0672@jabberwocky.com>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Fri, 18 Feb 2011 09:22:40 +0100
In-Reply-To: <D8E81788-AF18-448F-BA39-56185C1F0672@jabberwocky.com> (David Shaw's message of "Thu, 17 Feb 2011 14:12:20 -0500")
Message-ID: <87aaht69bj.fsf@vigenere.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 17 Feb 2011 20:12, dshaw@jabberwocky.com 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.
 

Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.