Re: [openpgp] New fingerprint: to v5 or not to v5

Werner Koch <> Tue, 06 October 2015 08:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 387BE1B3B46 for <>; Tue, 6 Oct 2015 01:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wa2FDTWUBTUN for <>; Tue, 6 Oct 2015 01:06:04 -0700 (PDT)
Received: from ( [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADD881B3B43 for <>; Tue, 6 Oct 2015 01:06:04 -0700 (PDT)
Received: from uucp by with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjNG6-0000lF-R8 for <>; Tue, 06 Oct 2015 10:06:02 +0200
Received: from wk by with local (Exim 4.84 #3 (Debian)) id 1ZjNBM-0001qA-LY; Tue, 06 Oct 2015 10:01:08 +0200
From: Werner Koch <>
To: Peter Gutmann <>
References: <> <> <> <> <> <> <> <> <>
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=F2AD85AC1E42B367;
Mail-Followup-To: Peter Gutmann <>, Watson Ladd <>, Phillip Hallam-Baker <>, Daniel Kahn Gillmor <>, IETF OpenPGP <>
Date: Tue, 06 Oct 2015 10:01:08 +0200
In-Reply-To: <> (Peter Gutmann's message of "Mon, 5 Oct 2015 11:44:39 +0000")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <>
Cc: Watson Ladd <>, Phillip Hallam-Baker <>, Daniel Kahn Gillmor <>, IETF OpenPGP <>
Subject: Re: [openpgp] New fingerprint: to v5 or not to v5
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Oct 2015 08:06:06 -0000

On Mon,  5 Oct 2015 13:44, said:

> Either leave it out or, much better, use an explicit ID stored with the key
> rather than one that's implicitly calculated from various bits and pieces

That explicit ID sounds pretty much like a issuer+serialno or one of the
other X.509 methods to identify a key.  It is not a fingerprint as we
know it and it can't be used as a secure identification of the key.

> surrounding the key.  That's how PKCS #15 and (ugh) PKCS #12 do it, it makes
> key lookup much less of a pain and avoids the current lost-key problem where
> you can't match up a key to a signature even though it's present and

Lost key?  Do you mean missing Issuer subpacket ( or one
pointing two keys with duplicated long keyids?  I have never seen the
former and in any case I would consider this a corrupted message.  To
fix the latter we will certainly define the use of a fingerprint.

> I can't see anything in the charter that would exclude it, it says the work
> items "include, but are not limited to ...", and specifically allows for work
> that won't unduly delay things and that has support from the WG.

Changing the entire packet structure is not an easy thing and definitely
would delay the listed goals.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.