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

Vincent Breitmoser <look@my.amazin.horse> Mon, 12 October 2015 12:06 UTC

Return-Path: <look@my.amazin.horse>
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 A878A1AD06D for <openpgp@ietfa.amsl.com>; Mon, 12 Oct 2015 05:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 eExf0oc3WkrT for <openpgp@ietfa.amsl.com>; Mon, 12 Oct 2015 05:06:38 -0700 (PDT)
Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5D71ACEFA for <openpgp@ietf.org>; Mon, 12 Oct 2015 05:06:38 -0700 (PDT)
Received: from localhost (D57DC892.static.ziggozakelijk.nl [213.125.200.146]) by mail.mugenguild.com (Postfix) with ESMTPSA id 63C675FDA4 for <openpgp@ietf.org>; Mon, 12 Oct 2015 14:06:35 +0200 (CEST)
References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <CACsn0c=-LKagSqTbgOV1W4Gu4u-f6vpVq82-nWSLGogjoeFKeg@mail.gmail.com> <CAMm+LwjeKDKnN2ZAisbKhWVS4kwCEm_VvcZ1MtftYzEJQpGdhg@mail.gmail.com> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> <87wpuvx4o1.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4B2EE19@uxcn10-5.UoA.auckland.ac.nz>
From: Vincent Breitmoser <look@my.amazin.horse>
To: "openpgp\@ietf.org" <openpgp@ietf.org>
Cc:
In-reply-to: <9A043F3CF02CD34C8E74AC1594475C73F4B2EE19@uxcn10-5.UoA.auckland.ac.nz>
Date: Mon, 12 Oct 2015 14:06:27 +0200
Message-ID: <87d1wkjnp8.fsf@littlepip.fritz.box>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/pIfp0blG7aufKUC9kwlyHWjZFZc>
Subject: Re: [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: Mon, 12 Oct 2015 12:06:40 -0000

The creation date in the fingerprint is used for two purposes I can
think of:

Firstly, it is commonly used by users to pick a key when a keyserver
search returns more than one result, which is made possible without
processing the full key by integrity protecting the creation date in the
fingerprint.  It is questionable whether this behavior should be
encouraged, but if there is no attacker this is often a reasonable
guess.  If there is an attacker, you are doomed no matter what you do
with an unauthenticated key.

Secondly, implementations use it as a boundary for signature validity.
I don't think this behavior is actually specified, so this is mostly
just guesswork in the trust model?

Including the key material as the only dynamic part of the fingerprint
is the most basic decision.  So the question becomes, do we have a good
reason to include anything more?  For the creation date in particular,
are the above two properties desirable and worth it?

Just for brainstorming, the other extreme would be allowing arbitrary
properties (e.g. signature subpackets) to be included in the
fingerprint, allowing an implementation to have properties which can
never change throughout the lifetime of a key, and which cannot be
suppressed by an attacker unlike irrecovable signature packets.

 - V