Re: [openpgp] Keyholder-configurable fingerprint schemes?

ianG <iang@iang.org> Sun, 08 November 2015 11:09 UTC

Return-Path: <iang@iang.org>
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 AA8501A92F2 for <openpgp@ietfa.amsl.com>; Sun, 8 Nov 2015 03:09:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lTdqiqx3ZQ4R for <openpgp@ietfa.amsl.com>; Sun, 8 Nov 2015 03:09:12 -0800 (PST)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481271A92E7 for <openpgp@ietf.org>; Sun, 8 Nov 2015 03:09:12 -0800 (PST)
Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 8A92A6D732; Sun, 8 Nov 2015 06:09:11 -0500 (EST)
To: openpgp@ietf.org
References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com>
From: ianG <iang@iang.org>
Message-ID: <563F2D56.5050809@iang.org>
Date: Sun, 08 Nov 2015 11:09:10 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/HFpwZDEv3dheEj9YZlhAF82gXxU>
Subject: Re: [openpgp] Keyholder-configurable fingerprint schemes?
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: Sun, 08 Nov 2015 11:09:13 -0000

On 7/11/2015 03:31 am, Bryan Ford wrote:
> In the OpenPGP meeting, Christian brought up an idea that I thought was interesting and perhaps deserved further consideration.
>
> Background summary:  In the meeting a hum-poll was taken on the “single vs multiple fingerprints” question, my interpretation of whose result was that we should *not* create a system that subjects users to juggling multiple, inconsistent fingerprints for the same key (e.g., both a SHA-1 and a newer-hash-function-based fingerprint for the same user’s public key).

Definitely.  Strong hum.


> A “strong interpretation” of that position is we should pick a single new hash function for “new fingerprints”, and mandate that all keys created with “new signature schemes” (e.g., Ed448) have fingerprints computed using that new scheme, while leaving the fingerprints of old schemes (e.g., RSA/DSA keypairs) fingerprinted using the old approach to preserve consistency.

Hmm.  In both senses.

> A “weaker interpretation” of that position would be that for each new signature scheme defined for use with OpenPGP, that scheme should also define a suitable fingerprinting scheme to go along with it, but the fingerprinting scheme may (in principle) vary from one “new” keypair-type to another provided it remains consistent for any given  keypair.


That.  The author of the signature scheme has to *select* a fingerprint 
scheme.  We fully expect that in 2025 we'll be re-doing the signature 
scheme, because the old one is crufty and brittle - the same applies to 
the fingerprint scheme.  The author at the time has the responsibility 
and the knowledge to match all the components together to get a good 
security across the board.

<loud>HMMM</loud>

> I see that the precise results of this hum-poll weren’t precisely captured in Rich’s meeting minutes - understandable since the precise results (or their proper interpretation) was a bit fuzzy to me as well and I don’t feel confident either to suggest exactly how that part of the minutes should be filled in.


thanks.  And no, I don't see it as "weaker" but in fact stronger design 
principle :)

iang