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

Jon Callas <jon@callas.org> Thu, 20 January 2011 16:00 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KG09Bk059526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 09:00:09 -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 p0KG09bR059525; Thu, 20 Jan 2011 09:00:09 -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 merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KG08YK059520 for <ietf-openpgp@imc.org>; Thu, 20 Jan 2011 09:00:08 -0700 (MST) (envelope-from jon@callas.org)
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 265952E0E6 for <ietf-openpgp@imc.org>; Thu, 20 Jan 2011 08:00:11 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13368-05 for <ietf-openpgp@imc.org>; Thu, 20 Jan 2011 08:00:08 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id DC8D02E0D0 for <ietf-openpgp@imc.org>; Thu, 20 Jan 2011 08:00:08 -0800 (PST)
Received: from [10.58.48.195] ([12.180.86.130]) by keys.merrymeet.com (PGP Universal service); Thu, 20 Jan 2011 08:00:06 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 20 Jan 2011 08:00:06 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Jon Callas <jon@callas.org>
In-Reply-To: <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org>
Date: Thu, 20 Jan 2011 08:00:04 -0800
Message-Id: <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org>
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>
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.1082)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p0KG09YK059521
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>

-----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.

So you can consider a keyid to just be a database key. The way we do it now (truncating a fingerprint) is a fine way to do it, but the underlying principle is that an implementor really needs to code around the eventuality that there will be a collision and do some right thing.

Yeah, I know it's easier said than done, but that doesn't make it false.

I forget what Terry Pratchett novel has it, but in one of them he has a discussion that anything that is a million-to-one against is a certainty. The million-to-one thing *will* happen. Cryptographers need to keep that principle in the back of their head, too.

	Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFNOFwGsTedWZOD3gYRAtyVAJ40VCHrrUkG2Dc+Bi7fKQA5VZlCeQCfRQVc
Xs4TmguHftMh9uE/+b5Lqfw=
=B98X
-----END PGP SIGNATURE-----