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

Ian G <iang@iang.org> Thu, 20 January 2011 10:21 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KALrpf043769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 03:21:54 -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 p0KALrdu043768; Thu, 20 Jan 2011 03:21:53 -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 p0KALrCN043763 for <ietf-openpgp@imc.org>; Thu, 20 Jan 2011 03:21:53 -0700 (MST) (envelope-from iang@iang.org)
Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id AEC82406C2; Thu, 20 Jan 2011 10:21:51 +0000 (UTC)
Message-ID: <4D380CBF.7080905@iang.org>
Date: Thu, 20 Jan 2011 21:21:51 +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: 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>
In-Reply-To: <4D36010A.30205@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8; 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 19/01/11 8:07 AM, 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).


The style of OpenPGP v5++ has been algorithm agility, and getting away 
from that is likely to take time, and/or bravery.

Which leads me to agree that the fingerprint should include the leading 
algorithm Id, because that's how we do message digests.  And in text, we 
browbeat the developers to stick to the "the one."

(In which, the one will be two, SHA1 then SHA3, until we can ditch the 
other "one".)

On the other hand, there is that hanging question:  do we want algorithm 
agility in the future?  What did we ever win by it?  Did it ever meet 
its promise?

If the answer is in the negative, I'd be inclined to ignore the whole 
packet question and start thinking instead about a completely new layout 
generation that simplified the coding requirements back to something ... 
PGP 2.3 like.

iang



PS: at least, that's my question & hobby horse.  Others have other 
questions and hobby horses.