Re: DEADBEEF vs SHA1

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 18 February 2011 17:37 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IHb4hl084128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 10:37:04 -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 p1IHb4G1084127; Fri, 18 Feb 2011 10:37:04 -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 che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IHb3F7084120 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 10:37:03 -0700 (MST) (envelope-from dkg@fifthhorseman.net)
Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 28E2CF970; Fri, 18 Feb 2011 12:37:01 -0500 (EST)
Message-ID: <4D5EAE38.4050304@fifthhorseman.net>
Date: Fri, 18 Feb 2011 12:36:56 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7
MIME-Version: 1.0
To: Werner Koch <wk@gnupg.org>
CC: David Shaw <dshaw@jabberwocky.com>, IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Subject: Re: DEADBEEF vs SHA1
References: <D8E81788-AF18-448F-BA39-56185C1F0672@jabberwocky.com> <87aaht69bj.fsf@vigenere.g10code.de>
In-Reply-To: <87aaht69bj.fsf@vigenere.g10code.de>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB023DE46FC2756A1E5F3CDC0"
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 02/18/2011 03:22 AM, Werner Koch wrote:
> 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.

while it might be more correct to import the new keys, it introduces
dangerous ambiguity to the output of "gpg --check-sigs --with-colons",
as that command identifies certifiers by key ID.

Any tool that relies on the output of "gpg --check-sigs --with-colons"
is currently implicitly expecting only a single key per keyID in the
keyring; otherwise, the output would be ambiguous.

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

That's good to hear, thanks!

	--dkg