Daniel Kahn Gillmor <> Fri, 18 February 2011 17:37 UTC

Received: from (localhost []) by (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
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p1IHb4G1084127; Fri, 18 Feb 2011 10:37:04 -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 p1IHb3F7084120 for <>; Fri, 18 Feb 2011 10:37:03 -0700 (MST) (envelope-from
Received: from [] ( []) by (Postfix) with ESMTPSA id 28E2CF970; Fri, 18 Feb 2011 12:37:01 -0500 (EST)
Message-ID: <>
Date: Fri, 18 Feb 2011 12:36:56 -0500
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101213 Icedove/3.1.7
MIME-Version: 1.0
To: Werner Koch <>
CC: David Shaw <>, IETF OpenPGP Working Group <>
Subject: Re: DEADBEEF vs SHA1
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB023DE46FC2756A1E5F3CDC0"
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

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!