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

Jonathan McDowell <noodles@earth.li> Sat, 10 October 2015 10:35 UTC

Return-Path: <noodles@earth.li>
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 0CE8B1A8788 for <openpgp@ietfa.amsl.com>; Sat, 10 Oct 2015 03:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.112
X-Spam-Level:
X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 duq7ZEpKkBok for <openpgp@ietfa.amsl.com>; Sat, 10 Oct 2015 03:35:51 -0700 (PDT)
Received: from the.earth.li (the.earth.li [IPv6:2001:41c8:10:b1f:c0ff:ee:15:900d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8891A873B for <openpgp@ietf.org>; Sat, 10 Oct 2015 03:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=JfmNWoFFhqBvxfqqenOA2n6Nf2AampSfzQHraBFSGa8=; b=oZW9zSIHkBW6bYAjipBUwxsRaHoHf3UZ0J8xH0SfYJZ2H3NsvoPaiexOIODJWwzrpBns1MQ2A2mygv4mf+oTIfKf19Wu7eeAisx4iMV02ukBJib//sBseahZ6Tt2v500ud+brqSNFqPwAMo4HVrOwqdswAcE+Z4gkeh3w9o0J/PrUQ1Rjt7aCdIItg6+y/bV759WMxWc/CpMgqMj15h7Jw8bHWKdkmIsF30W6EEnjs/UbY2QOrRW0nBjoxaqqbz8vl+yP9Fq+xGaVAe1KPO+WflIXRZv9kkPXcVvFM0TeFuwqH1v7DBJDcmaeRBYJIjhf+bsYgBulp3dEQXvsndcVg==;
Received: from noodles by the.earth.li with local (Exim 4.84) (envelope-from <noodles@earth.li>) id 1ZkrVF-0000U4-D4 for openpgp@ietf.org; Sat, 10 Oct 2015 11:35:49 +0100
Date: Sat, 10 Oct 2015 11:35:49 +0100
From: Jonathan McDowell <noodles@earth.li>
To: openpgp@ietf.org
Message-ID: <20151010103549.GZ26454@earth.li>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87wpuvx4o1.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/_Y-U5JHRZpOLALj6hbxRaQTuDiE>
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: Sat, 10 Oct 2015 10:35:53 -0000

On Fri, Oct 09, 2015 at 02:44:46PM -0400, Daniel Kahn Gillmor wrote:
>  a) don't include any key creation time at all; signatures themselves
>     have a creation time, which is sufficient.
> 
>  b) include key creation time in the material certified only for
>     self-sigs (certifications issued by the key itself).  Do not include
>     any key creation time in the material certified by third-parties.
> 
>  c) Include creation time of the certified key in the material certified
>     for all certifications -- first-party or third-party.
> 
> I'm tempted by the simplicity of (a), to be honest.
> 
> (b) sounds doable, but i don't know how useful it is to have assertions
> from the key of when the key was created, or what to do with situations
> where some self-sigs assert a different key creation time than others.
> Should we reject or ignore some of them?  if so, which ones?
> 
> (c) sounds like trouble -- you'll get self-signed assertions of key
> creation time that don't match third-party assertions of key creation
> time.  What does that mean?  how should it be represented to the user?
> I think this is the issue that Werner was hinting at.
> 
> what are the downsides of (a)?  What are the advantages of having a key
> creation time at all?  Is it simply that it provides a universally-known
> temporal boundary when to accept signatures made by that key?

I've certainly used key creation time as a separate piece of information
to "most recent self-signature". The latter indicates how recently the
key can be seen as still in use / maintained, but the former gives an
idea of how long it's been around and can help when making a decision
about which of multiple keys to use for an individual. I think having
that in the self-sig would work ok (i.e. option b). In general is the
most recent self-sig not the one that should be trusted, with perhaps a
warning if any of the previous ones have a different creation time
listed?

J.

-- 
Friends are God's apology for relations.