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.
- Re: DEADBEEF vs SHA1 Daniel A. Nagy
- Re: DEADBEEF vs SHA1 vedaal
- Re: DEADBEEF vs SHA1 Ian G
- Re: DEADBEEF vs SHA1 David Shaw
- Re: DEADBEEF vs SHA1 Lutz Donnerhacke
- Re: DEADBEEF vs SHA1 David Shaw
- Re: DEADBEEF vs SHA1 Jon Callas
- Re: DEADBEEF vs SHA1 Daniel Kahn Gillmor
- Re: DEADBEEF vs SHA1 Werner Koch
- Re: DEADBEEF vs SHA1 David Shaw
- Re: DEADBEEF vs SHA1 David Shaw
- Re: DEADBEEF vs SHA1 Daniel Kahn Gillmor
- DEADBEEF vs SHA1 David Shaw