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

David Shaw <> Tue, 18 January 2011 22:05 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0IM5w69061553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:05:58 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0IM5w40061552; Tue, 18 Jan 2011 15:05:58 -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 p0IM5ukI061547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Tue, 18 Jan 2011 15:05:57 -0700 (MST) (envelope-from
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id p0IM5tSI019147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Tue, 18 Jan 2011 17:05:55 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <>
In-Reply-To: <>
Date: Tue, 18 Jan 2011 17:05:55 -0500
Message-Id: <>
References: <> <> <> <> <> <>
To: IETF OpenPGP Working Group <>
X-Mailer: Apple Mail (2.1081)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id p0IM5vkH061548
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Jan 18, 2011, at 4:07 PM, Daniel Kahn Gillmor wrote:

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

I don't think we want people using other than the consensus fingerprint algorithms and methods.  I suggest we make the first byte a version field, which can be set to '4' today for the current fingerprint, '5' for v5 keys, etc.  I suppose we could skip that field and detect version based on size, but why use heuristics when we can know for sure with a version byte?