Re: [openpgp] Fingerprints

Christoph Anton Mitterer <calestyo@scientia.net> Fri, 10 April 2015 21:37 UTC

Return-Path: <calestyo@scientia.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDE1A8AA9 for <openpgp@ietfa.amsl.com>; Fri, 10 Apr 2015 14:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB8USW01iU-Q for <openpgp@ietfa.amsl.com>; Fri, 10 Apr 2015 14:37:22 -0700 (PDT)
Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278A21A8A89 for <openpgp@ietf.org>; Fri, 10 Apr 2015 14:37:22 -0700 (PDT)
Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 9FF755FB49 for <openpgp@ietf.org>; Fri, 10 Apr 2015 21:37:20 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net
Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id YwmamIsu0BIw for <openpgp@ietf.org>; Fri, 10 Apr 2015 21:37:18 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for <openpgp@ietf.org>; Fri, 10 Apr 2015 21:37:18 +0000 (UTC)
Message-ID: <1428701837.6212.145.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: openpgp@ietf.org
Date: Fri, 10 Apr 2015 23:37:17 +0200
In-Reply-To: <87y4m0ozlt.fsf@vigenere.g10code.de>
References: <CAMm+LwhbB+-MnGRBCvprgAGOuu+5CJ2rgod7EBGOQR5UNVrspQ@mail.gmail.com> <87y4m0ozlt.fsf@vigenere.g10code.de>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-IYjSwb8PjFP0nWGrJuIt"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/QEDO9BVn26pBAIwz6l_oeGzUwdY>
Subject: Re: [openpgp] Fingerprints
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: <http://www.ietf.org/mail-archive/web/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: Fri, 10 Apr 2015 21:37:24 -0000

On Fri, 2015-04-10 at 15:57 +0200, Werner Koch wrote: 
> > There is no need to have an algorithm field, a version field is
> > sufficient because we should only be using one algorithm at a given
> Right.
Why? Isn't that exactly what the past has taught us? That using one
fixed fingerprint algo leads into all kinds of troubles?
And not just from the engineering side (i.e. that applications simply
take it for granted that the data will be SHA1, e.g. when parsing output
of programs).
Looking at other areas (e.g. SSH) tendency seems to be rather to support
multiple fingerprint algos, and people can chose what they want.

And from the crypto side, we also see how bad it was/is, to have fixed
algos,... first with MD5 now with SHA1.
It's simply naive to believe that current or future algos won't meet the
same fate ultimately.


> It is often useful to have a keyid to quickly (but insecure) refer to a
> key.
And it caused also issues, when people *did* assume they'd be secure.


> I think that should be discussed in the context of the new default hash
> algorithm.
SHA2 and Keccak?


Cheers.