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

Jonathan McDowell <> Sat, 10 October 2015 10:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0CE8B1A8788 for <>; Sat, 10 Oct 2015 03:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.112
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id duq7ZEpKkBok for <>; Sat, 10 Oct 2015 03:35:51 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 8F8891A873B for <>; Sat, 10 Oct 2015 03:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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 with local (Exim 4.84) (envelope-from <>) id 1ZkrVF-0000U4-D4 for; Sat, 10 Oct 2015 11:35:49 +0100
Date: Sat, 10 Oct 2015 11:35:49 +0100
From: Jonathan McDowell <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [openpgp] New fingerprint: to v5 or not to v5
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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


Friends are God's apology for relations.