Re: [openpgp] v5 in the crypto-refresh draft
Peter Pentchev <roam@ringlet.net> Mon, 07 June 2021 11:46 UTC
Return-Path: <roam@ringlet.net>
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 1FC5B3A3D35 for <openpgp@ietfa.amsl.com>; Mon, 7 Jun 2021 04:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 v9IIB-CkdxFy for <openpgp@ietfa.amsl.com>; Mon, 7 Jun 2021 04:46:15 -0700 (PDT)
Received: from osse.kmail.bg (mx.kmail.bg [37.157.165.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD8E3A3253 for <openpgp@ietf.org>; Mon, 7 Jun 2021 04:46:15 -0700 (PDT)
Received: from straylight.m.ringlet.net (unknown [93.152.132.21]) by osse.kmail.bg (Postfix) with ESMTPSA id 1F098125 for <openpgp@ietf.org>; Mon, 7 Jun 2021 14:46:12 +0300 (EEST)
Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 6200e2 by straylight.m.ringlet.net (DragonFly Mail Agent v0.13); Mon, 07 Jun 2021 14:46:11 +0300
Date: Mon, 07 Jun 2021 14:46:11 +0300
From: Peter Pentchev <roam@ringlet.net>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <YL4HA3rtb1UrKnV8@straylight.m.ringlet.net>
References: <87lf7q6sh0.fsf@fifthhorseman.net> <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> <YL3zYBwALUh8oEed@straylight.m.ringlet.net> <SY4PR01MB6251662F63A66E10F08F6588EE389@SY4PR01MB6251.ausprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="6eGISLx4tBDKXnbz"
Content-Disposition: inline
In-Reply-To: <SY4PR01MB6251662F63A66E10F08F6588EE389@SY4PR01MB6251.ausprd01.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/B30CHd4J3HPenOb8TLNwAKQezcQ>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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, 07 Jun 2021 11:46:30 -0000
On Mon, Jun 07, 2021 at 11:33:54AM +0000, Peter Gutmann wrote: > Peter Pentchev <roam@ringlet.net> 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. 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. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
- [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Huigens
- Re: [openpgp] v5 in the crypto-refresh draft Michael Richardson
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Paul Wouters
- Re: [openpgp] v5 in the crypto-refresh draft Michael Richardson
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Paul Wouters
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Nickolay Olshevsky
- Re: [openpgp] v5 in the crypto-refresh draft Peter Pentchev
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Peter Pentchev
- Re: [openpgp] v5 in the crypto-refresh draft Michael Richardson
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Paul Wouters
- Re: [openpgp] v5 in the crypto-refresh draft Justus Winter
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor
- Re: [openpgp] v5 in the crypto-refresh draft Peter Gutmann
- Re: [openpgp] v5 in the crypto-refresh draft Daniel Kahn Gillmor