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

Werner Koch <wk@gnupg.org> Thu, 17 September 2015 18:45 UTC

Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C57A21B30F8 for <openpgp@ietfa.amsl.com>; Thu, 17 Sep 2015 11:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZMrkex0SJ0Jk for <openpgp@ietfa.amsl.com>; Thu, 17 Sep 2015 11:45:53 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814001B30D8 for <openpgp@ietf.org>; Thu, 17 Sep 2015 11:45:53 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZceBr-0005fG-PG for <openpgp@ietf.org>; Thu, 17 Sep 2015 20:45:51 +0200
Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zce84-0006Gn-J9 for <openpgp@ietf.org>; Thu, 17 Sep 2015 20:41:56 +0200
From: Werner Koch <wk@gnupg.org>
To: IETF OpenPGP <openpgp@ietf.org>
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com
Mail-Followup-To: IETF OpenPGP <openpgp@ietf.org>
Date: Thu, 17 Sep 2015 20:41:56 +0200
Message-ID: <878u84zy4r.fsf@vigenere.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/Zh1sqHZD8sVUfsW4OrMNx3dq4Ss>
Subject: [openpgp] New fingerprint: to v5 or not to v5
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 18:45:55 -0000


I'd like to get opinions on one specific aspect of a new fingerprint
format in 4880bis.

In the past we bound the fingerprint format to the key packet version:
v3 keys used MD5 and v4 keys SHA-1 fingerprints.  This gained us the
benefit of having a bijective connection between fingerprint and key.

For X.509 and ssh (OpenSSH), there has always been an uncertainty which
fingerprint to use because there is no well established standard for it.
For a long time MD5 was used but then some users switched to SHA-1, and
meanwhile SHA-256 is also seen more often.  These fingerprint formats
can easily be distinguished by their length and thus the format itself
is not a problem.  However, if you ask users to verify the fingerprint
of a certificate and you given them SHA-1 but they have only access to
the MD5 fingerprint things starts to get wrong.  Complicated (human)
reasoning about the identity of a certificate needs to be done.

With OpenPGP is is easier: The specs say that a key is described by one
and only one fingerprint.  There is no way to assign a different
fingerprint to the the same key.

If we want to introduce a, say, SHA-256 fingerprint, the straightforward
way is to define a v5 key packet format which will be identical to the
v4 format with the exception of the packet version number (and maybe
rules on what algorithms to use with a v5 key) [1].

Such a v5 format also means that it is not possible to switch to the new
fingerprint format for existing v4 keys.  The v4 keys would continue to
use SHA-1 fingerprints.

Some people claim that a SHA-1 fingerprint might soon be problematic due
to collision attacks.  If we assume that this is indeed the case, the
question is whether switching to SHA-256 for the very same key does
actually help: The mix of different fingerprints for the same key will
lead to the same confusion we have seen with X.509 and ssh.  Further, if
there is a need to switch to a stronger fingerprint format for the same
key, should the user not also assume that the use of the key has already
been compromised and it is time to create a new key?

Given that we are expecting to soon switch from RSA to ECC for improved
security and that the current base of OpenPGP implementations supporting
ECC is quite small, I would recommend not to allow a second fingerprint
format for v4 keys but to bind a new fingerprint format to a v5 key
packet version.



[1] I recently talked to the guy who asked a long time ago for a hard
expiration time in a future key packet format.  He is not anymore
interested in this and thus other technical changes to the key packet
format a not needed.

Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.