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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 18 January 2011 22:35 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMZPMI062592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:35:25 -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 p0IMZPA8062591; Tue, 18 Jan 2011 15:35:25 -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 p0IMZOhl062586 for <ietf-openpgp@imc.org>; Tue, 18 Jan 2011 15:35:24 -0700 (MST) (envelope-from dkg@fifthhorseman.net)
Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 428C2F987 for <ietf-openpgp@imc.org>; Tue, 18 Jan 2011 17:35:23 -0500 (EST)
Message-ID: <4D3615A5.1050700@fifthhorseman.net>
Date: Tue, 18 Jan 2011 17:35:17 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Reply-To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
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: 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>
In-Reply-To: <4D360E46.1080208@epointsystem.org>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD6BE80802367B5C059290AE7"
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 01/18/2011 05:03 PM, Daniel A. Nagy wrote:
> There are specific use cases that I am interested in, where including the
> creation date in the fingerprint hash causes problems. If anyone is interested,
> I can describe them in necessary detail.

I'd like to read about (or be pointed to) the necessary detail.

> I believe you mis-interpreted Jon's suggestion. He was suggesting to treat the
> fingerprint field as a free-form string within the signature subpacket. Nothing
> more and nothing less.

i'm pretty sure that's not what he suggested, actually.  But clearly it
wasn't successfully communicated to everyone, since we appear to have
different interpretations.  Jon, can you clarify what you meant?

> Key servers must also eventually treat
> fingerprints as (possibly limited-length, but by no means fixed-length) strings.

Why?  Shouldn't keyservers be responsible for calculating the
fingerprints themselves?  treating fingerprinting as a total black box
seems like it loses several of the really useful properties of fingerprints.

> I think that there must be only ONE string called THE fingerprint of a certain
> public key.

why?  we currently have three strings that are frequently used to
identify keys with varying levels of assurance of "uniqueness" -- the
32-bit keyID (no guarantee at all, trivially spoofable), the 64-bit
keyID (more difficult to spoof), and the 160-bit SHA1-based fingerprint
(believed to be invulnerable to preimage attacks given the state of
knowledge of math and available computer hardware).  I'm aware that
these are derivable from each other, but it doesn't seem to change the
fact that we're using them in a comparable way right now.

What significant problems will we encounter by adding a 4th identifying
shorthand variant (hopefully with stronger guarantees of "uniqueness"
than the existing three) that people can use if they want the stronger
guarantees?

	--dkg