Re: including the entire fingerprint of the issuer in an OpenPGP certification

Ian G <> Fri, 21 January 2011 10:52 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0LAqwBe003685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0LAqw1x003684; Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( [] (may be forged)) by (8.14.4/8.14.3) with ESMTP id p0LAqvIg003679 for <>; Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from
Received: from viento.local (localhost []) by (Postfix) with ESMTP id 8D2E0406C2; Fri, 21 Jan 2011 10:52:55 +0000 (UTC)
Message-ID: <>
Date: Fri, 21 Jan 2011 21:52:54 +1100
From: Ian G <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Jon Callas <>
CC: IETF OpenPGP Working Group <>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On 21/01/11 3:00 AM, Jon Callas wrote:
> Hash: SHA1
> A side-effect of this is something that's either an obvious extension or in the spec already.
> Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are unique."
> It's said that since 2440, for the following reason...
> In PGP1 days, Vinnie started working there and told me that he'd generated a key and gotten a certain error when putting it into the keyserver. I was thrilled, because that error was a duplicate keyid error. We'd been having debates over this ourselves. Being a software engineer, I tend to consider assuming that a database key is unique is bad form. I recognize that pseudo-random 64-bit numbers don't collide easily at all, but assuming uniqueness is something that is easily coded around. That key was my proof that engineering-wise, don't assume uniqueness.
> Sadly, he had deleted the key and just generated a new one, so that key is the Nessie of key ids. It's a crypto-cryptologist's dream, the true random collision. And we will never know if it was genuine. Sigh.
> Nonetheless, that led to that clause in 3.3, and I assert that if an implementation breaks because of a keyid collision, the implementation has a bug.

Fascinating anecdote!  Definately one to debate over beers:

I'd not go so far as to agree that the implementation has a bug.  I'd 
say this is the difference between "security culture" coding and an 
ordinary user-grade coding.

Which is to say, as long as the error is rare enough, and as long as the 
knee-jerk reaction of the code at the top of the stack is approximately 
useful, and as long as this is a standard-grade application, it's 
reasonable to kick it way up there.

In this case, the exception went all the way up the stack into the 
wetware, and Vinnie responded by re-generating the key!  Problem solved. 
  This "reboot" methodology made Bill Gates a lot of money...

OTOH, if we were engaged in building a "security culture" product we 
would want to solve this in lower layers.