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

Daniel Kahn Gillmor <> Tue, 18 January 2011 21:07 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0IL7Ua4059515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 14:07:30 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0IL7UWo059514; Tue, 18 Jan 2011 14:07:30 -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 p0IL7T4P059509 for <>; Tue, 18 Jan 2011 14:07:30 -0700 (MST) (envelope-from
Received: from [] ( []) by (Postfix) with ESMTPSA id 7ABE7F987 for <>; Tue, 18 Jan 2011 16:07:28 -0500 (EST)
Message-ID: <>
Date: Tue, 18 Jan 2011 16:07:22 -0500
From: Daniel Kahn Gillmor <>
Reply-To: IETF OpenPGP Working Group <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101213 Icedove/3.1.7
MIME-Version: 1.0
To: IETF OpenPGP Working Group <>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enigCF8B6F2528F40A55F30BC234"
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On 01/18/2011 12:48 PM, Jon Callas wrote:
> If we combine it with a hash-independent fingerprint -- e.g., first byte is an algorithm ID, others are the actual hash -- then we can put it in now and then run with it.

Daniel Nagy suggests that we also change the material being hashed in
the fingerprint (he wants to leave out the creation date).  If that
proposal ends up achieving consensus then your proposal here will need
further modification.

Does anyone feel strongly about Nagy's proposal, by the way?  i'm not
sure what the tradeoffs are.

Even without that concern, if we encourage super-flexible use like this,
user agents who wanted to use it to test for the presence of a given key
in an indexed keystore would need to index their keys with every
possible digest that might be used -- that seems excessive somehow.
(and unlikely that keyserver implementations would want a half-dozen
indexes, for that matter)  Wouldn't it be better to just implement it
for today's fingerprint, and then when a new fingerprint is agreed upon,
determine (by subpacket length maybe?) whether it's the new fingerprint
or the old one.  Compliant user agents would keep the two indexes around
until the v4 fingerprint goes away, and then drop the old one.

Alternately, we could embed the algorithm ID as you suggest, and SHOULD
people into generating them using only the consensus fingerprint
algorithms so that reasonable user agents only need to create indexes
over SHA1 (now) and SHA3 (whenever that happens).