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

[Daniel Kahn Gillmor <[e-mail]>]

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 <[e-mail]> 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
https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/55
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:

    https://mailarchive.ietf.org/arch/msg/openpgp/cb32QpGl5-PP02s_dYsTkl3rVK0/

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.

    --dkg