Re: [openpgp] v5 in the crypto-refresh draft

Daniel Kahn Gillmor <> Mon, 07 June 2021 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBE033A1776 for <>; Mon, 7 Jun 2021 07:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=GECb1M8f; dkim=pass (2048-bit key) header.b=pBc9iEvq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 78ygnAxvufae for <>; Mon, 7 Jun 2021 07:01:23 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A84B3A177A for <>; Mon, 7 Jun 2021 07:01:23 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1623074481; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VwT1JYg4rD+EoPb9pSbRQ+m/SGZ0o1CpISe5w3jl2gQ=; b=GECb1M8fGI2GRpMjYkSfldzCSNCCwiZN7nyY1lX4L5AIfGgeSj+gEbfGroM6LGV4sMBc4 zs/remUsQCIkpcsAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1623074481; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VwT1JYg4rD+EoPb9pSbRQ+m/SGZ0o1CpISe5w3jl2gQ=; b=pBc9iEvqY6jQUj99E/1zMDmyEviYyUtL5S+8Kyjc+ePURipruvnRIPK/BxdMYA7jBoWnK PwpAXpXFZMuDL9zfYOvO+7juexJBibAtWChBaimKTwpJ6GVMU0jtoTdb9uWyU7c/DMjED4j Hyu6NiZJGAJBAKeRiFFgP+RE6IElFDXPM4DWre107oUwNm5LTKJjYOb+BPOL53PTiiplhH8 MXnNsIaase7kG7GwsOFUpkG81s8/UQhyNilSeemJh61Nv9rSNxuS/U85CV7AG1JVZPxC380 33PCRGNacv+tqx4vlFqlrPoUKU+wb4x6pz4Lv+2eYwfWjyOlM+Qchl1bIGvA==
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 6EF55F9A6 for <>; Mon, 7 Jun 2021 10:01:21 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 004FE2049A; Mon, 7 Jun 2021 09:46:23 -0400 (EDT)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <> <> <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Mon, 07 Jun 2021 09:46:20 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jun 2021 14:01:29 -0000

On Mon 2021-06-07 14:46:11 +0300, Peter Pentchev wrote:
> On Mon, Jun 07, 2021 at 11:33:54AM +0000, Peter Gutmann wrote:
>> Peter Pentchev <> writes:
>> >Obviously not speaking for any of the people who actually work on this, but
>> >you need to keep in mind that the time field is defined as an *unsigned* 32-
>> >bit number, so we'll have another 68 years after the year 2038 to take care
>> >of that.
>> Except that time_t is signed so it's going to cause breakage if you just
>> assign a 32-bit OpenPGP time to a 32-bit time_t.  Making it 64 bits would both
>> prevent this and signal to 32-bit time_t users that they need to take special
>> care with time values.
> Well, if any implementation still uses a signed 32-bit time_t C type in
> the year 2038, it will not be able to do anything anyway. ICBW, but is
> the point of the standard not to define the wire format, and not
> implementation-specific details? An unsigned 32-bit value for the wire
> format should be fine for this century.

The standard is good until 2106, barring implementation failures like
what you describe.

I've opened
to suggest some possible tests that would try to identify such
implementation failures.

> But maybe I'll just shut up and let the people who have already
> discussed modifications to the standard (like you, so yeah, sorry)
> say whether anybody has ever raised this before and whether it has been
> discussed.

this came up back in 2016 here:

At that time, there was no clear consensus, and (different) reasonable
people advocated for:

 - leaving the timestamps in the standard untouched
 - using a 40-bit timestamp (measured in seconds since the epoch)
 - using a signed 64-bit timestamp (measured in seconds since the epoch)
 - using a signed 64-bit timestamp (measured in 100ns units since the epoch)
 - using ISO 8601 timestamp representations

I'd prefer to not focus on that question right now: aside from not
having consensus, i'd argue it's outside the scope of our current
charter, which is for cryptographic refresh, and we're behind on getting
the crypto refresh done.