Return-Path: <jon@callas.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 1EECE12D183
 for <openpgp@ietfa.amsl.com>; Fri,  8 Apr 2016 22:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
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 8DVzCYfBUEUF for <openpgp@ietfa.amsl.com>;
 Fri,  8 Apr 2016 22:35:52 -0700 (PDT)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100])
 by ietfa.amsl.com (Postfix) with ESMTP id 61A3412D0BE
 for <openpgp@ietf.org>; Fri,  8 Apr 2016 22:35:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by mail.merrymeet.com (Postfix) with ESMTP id F12819474D0D;
 Fri,  8 Apr 2016 22:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1])
 by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gdewC2mU8zxs; Fri,  8 Apr 2016 22:35:50 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97])
 by mail.merrymeet.com (Postfix) with ESMTPSA id 7CABC9474CF9;
 Fri,  8 Apr 2016 22:35:49 -0700 (PDT)
Received: from [10.0.23.7] ([173.164.244.98])
 by keys.merrymeet.com (PGP Universal service);
 Fri, 08 Apr 2016 22:35:50 -0700
X-PGP-Universal: processed;
 by keys.merrymeet.com on Fri, 08 Apr 2016 22:35:50 -0700
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <87oa9jo5sp.fsf@alice.fifthhorseman.net>
Date: Fri, 8 Apr 2016 22:35:49 -0700
Message-Id: <9C461E78-DC60-4B9D-A0DF-170F4759A57D@callas.org>
References: <4C08CDDD-4C06-41AD-9797-7DD6F08ECD06@gmail.com>
 <2AA5B912-0AE6-4722-8BC7-66E37559C0B1@callas.org>
 <D17B23A3-633F-4E4E-BC14-69ED6060F357@gmail.com>
 <6E221A61-7AB2-4E0B-B64D-60F210A0131F@callas.org>
 <E9A5B4B3-0EEC-4E86-8CEC-6680A24BE44F@gmail.com>
 <0D7A75AB-74C6-40E9-87C5-BA6F05FCDBF7@callas.org>
 <87oa9jo5sp.fsf@alice.fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3124)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/_-JKWmALexT3H4UplPs4g9jJ28c>
Cc: openpgp@ietf.org, Jon Callas <jon@callas.org>,
 Bryan Ford <brynosaurus@gmail.com>
Subject: Re: [openpgp] Mining protection in fingerprint schemes
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 09 Apr 2016 05:35:54 -0000


> On Apr 8, 2016, at 7:49 PM, Daniel Kahn Gillmor =
<dkg@fifthhorseman.net> wrote:
>=20
> On Fri 2016-04-08 15:32:32 -0300, Jon Callas <jon@callas.org> wrote:
>>  One of the ideas we had a long time ago was that the "fingerprint"
>>  actually has two fields in it. A tag and a value. I'm still fond
>>  myself of the fingerprint that is
>>=20
>>  <algorithm-id>:<algorithm-value>
>>=20
>>  but I'm not wedded to the syntax. I like the idea; I don't care
>>  about the syntax.
>=20
> The sense i got from the group was that we wanted one (and exactly =
one)
> fingerprint for any given key.
>=20
> the proposal above means that i could compute a fingerprint for key X,
> and you could compute a fingerprint for key X, and then when we go to
> compare them they could be different (because one of us chose a
> different algorithm id than the other).  This makes fingerprint
> comparison a crapshoot, or requires one side of the comparisons to
> generate all possible fingerprints before they discover what the other
> side has done.

Noted.

I will mention that the advantage of a generic scheme is that it doesn't =
have to be revisited later when there's a new cool hash function that we =
all should use.

But the real reason for bringing that back was to give Bryan a hand. I =
see what he's wanting to do. He's wanting to create something that I =
will call the "authentication string."=20

At present, we use the key fingerprint as the authentication string. The =
mining protection he's suggesting isn't a bad thing. My raised eyebrow =
comes from conflating the two. We need to have a "DB handle" and I =
believe the DB handle needs to be easy to compute (key-canonical is an =
orthogonal issue). The fingerprint gets used all over the place, =
especially in its truncated form as key-id.

So a way to get both is to make them not the same thing. Have it so that =
the thing that you print on your business card is the authentication =
string, and the thing that the software is using a lot is the db handle.

As it is, there are "fingerprints" used all over the place that aren't =
the user-visible one anyway, because the user-visible one is the =
fingerprint of the top-level signing key.

So stepping back even further, to have our cake and eat it two, we want =
to separate the two functions.

Anything that does that seems like a win, not just generalized =
fingerprints.

	Jon=