Re: [openpgp] Fingerprints

Christoph Anton Mitterer <calestyo@scientia.net> Wed, 15 April 2015 20:04 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 890E41A1A24 for <openpgp@ietfa.amsl.com>; Wed, 15 Apr 2015 13:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sxWJxs951ZJI for <openpgp@ietfa.amsl.com>; Wed, 15 Apr 2015 13:04:27 -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 60F2F1A1A22 for <openpgp@ietf.org>; Wed, 15 Apr 2015 13:04:27 -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 633E95FB70 for <openpgp@ietf.org>; Wed, 15 Apr 2015 20:04:25 +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 13ZapjRKQWvb for <openpgp@ietf.org>; Wed, 15 Apr 2015 20:04:23 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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>; Wed, 15 Apr 2015 20:04:23 +0000 (UTC)
Message-ID: <1429128262.1702.41.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: "openpgp@ietf.org" <openpgp@ietf.org>
Date: Wed, 15 Apr 2015 22:04:22 +0200
In-Reply-To: <FE2717DC-3950-4536-B83D-BD005D2F26A6@callas.org>
References: <CAMm+LwhbB+-MnGRBCvprgAGOuu+5CJ2rgod7EBGOQR5UNVrspQ@mail.gmail.com> <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <FE2717DC-3950-4536-B83D-BD005D2F26A6@callas.org>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-RgT/b3kjLPu5Wxc1g+V5"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/AISUptopfvwgR2C8XV64-I_RW7g>
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: Wed, 15 Apr 2015 20:04:29 -0000

On Wed, 2015-04-15 at 12:11 -0700, Jon Callas wrote:
> There was a proposal that floated around that defined an extended
> fingerprint to be an algorithm number followed by the actual bits.
> For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary
> representation. There's an obvious way to truncate that as well --
> just decide if you truncate little-endian or big. (Personally, despite
> being a little-endian bigot, this is a place where network byte order
> is even to me the obvious win.)
> The major advantage of this is that you can define it and then you
> never have to change it again. We don't have to have any arguments
> over what hash function is proper to use, etc. An implementation can
> decide to support or not support whatever.
+1

But shouldn't one define better the number to be either a string?
Sure a one byte number with 255 possible future algorithms seem plenty
enough, but people also once thought that about 32bit IPv4 addresses,
two digit year numbers and so on.

:-)

Cheers,
Chris.