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

Ian G <iang@iang.org> Fri, 21 January 2011 10:52 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (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 owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0LAqw1x003684; Fri, 21 Jan 2011 03:52:58 -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 fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0LAqvIg003679 for <ietf-openpgp@imc.org>; Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from iang@iang.org)
Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id 8D2E0406C2; Fri, 21 Jan 2011 10:52:55 +0000 (UTC)
Message-ID: <4D396586.5020700@iang.org>
Date: Fri, 21 Jan 2011 21:52:54 +1100
From: Ian G <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Jon Callas <jon@callas.org>
CC: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
References: <E1Pf1WI-0007aL-EN@login01.fos.auckland.ac.nz> <CFCF61BD-9281-4F09-AD31-C5AAC38315FE@callas.org> <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org>
In-Reply-To: <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 21/01/11 3:00 AM, Jon Callas wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.



iang