ietf-openpgp
[Top] [All Lists]

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

2021-06-07 09:01:52
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 <roam(_at_)ringlet(_dot_)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.

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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp