Re: including the entire fingerprint of the issuer in an OpenPGP certification
"Daniel A. Nagy" <nagydani@epointsystem.org> Tue, 18 January 2011 22:03 UTC
Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IM3u1t061466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:03:57 -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 p0IM3uD1061465; Tue, 18 Jan 2011 15:03:56 -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 mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IM3tui061458 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <ietf-openpgp@imc.org>; Tue, 18 Jan 2011 15:03:56 -0700 (MST) (envelope-from nagydani@epointsystem.org)
Received: by fxm18 with SMTP id 18so143251fxm.16 for <ietf-openpgp@imc.org>; Tue, 18 Jan 2011 14:03:54 -0800 (PST)
Received: by 10.223.98.204 with SMTP id r12mr6777013fan.102.1295388234210; Tue, 18 Jan 2011 14:03:54 -0800 (PST)
Received: from [192.168.3.151] (catv-89-132-111-180.catv.broadband.hu [89.132.111.180]) by mx.google.com with ESMTPS id a25sm2335885fak.44.2011.01.18.14.03.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 14:03:53 -0800 (PST)
Message-ID: <4D360E46.1080208@epointsystem.org>
Date: Tue, 18 Jan 2011 23:03:50 +0100
From: "Daniel A. Nagy" <nagydani@epointsystem.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
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>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig5089CC478F8BBF2264BA3852"
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>
Hello, 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. 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. > 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. 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. This makes the change future-proof without any of the problems that you mention above. Key servers must also eventually treat fingerprints as (possibly limited-length, but by no means fixed-length) strings. On the other hand, one can argue that there is no reason to move from 160-bit fingerprints, even if we change the algorithm of their calculation for v5 keys. Even if a different hash function is used. This would make transition a bit less painful, without any real compromises on security. > 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 think that there must be only ONE string called THE fingerprint of a certain public key. Even if the algorithm is included, it should be either included in the key itself indicating that for that particular key this particular algorithm must be used or even mandated by the standard for all keys until further revisions. I see no benefit in explicitly including any details of the algorithm used to obtain it into the fingerprint itself, though. Cheers, -- Daniel
- Re: including the entire fingerprint of the issue… Ian G
- Re: including the entire fingerprint of the issue… Avi
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Peter Pentchev
- Re: including the entire fingerprint of the issue… Avi
- Re: including the entire fingerprint of the issue… Jon Callas
- Re: including the entire fingerprint of the issue… Jon Callas
- Re: including the entire fingerprint of the issue… Ian G
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Daniel A. Nagy
- Re: including the entire fingerprint of the issue… Werner Koch
- Re: including the entire fingerprint of the issue… Daniel Kahn Gillmor
- Re: including the entire fingerprint of the issue… Peter Gutmann
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Daniel Kahn Gillmor
- Re: including the entire fingerprint of the issue… Daniel Kahn Gillmor
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Daniel A. Nagy
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Daniel Kahn Gillmor
- Re: including the entire fingerprint of the issue… Jon Callas
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Daniel A. Nagy
- Re: including the entire fingerprint of the issue… Werner Koch
- Re: including the entire fingerprint of the issue… Ian G
- Re: including the entire fingerprint of the issue… Jon Callas
- Re: including the entire fingerprint of the issue… Daniel Kahn Gillmor
- Re: including the entire fingerprint of the issue… David Shaw
- Re: including the entire fingerprint of the issue… Daniel Kahn Gillmor
- Re: including the entire fingerprint of the issue… Peter Gutmann
- Re: including the entire fingerprint of the issue… Jon Callas
- including the entire fingerprint of the issuer in… Daniel Kahn Gillmor