Key expires at ... 1971
dshaw at jabberwocky.com
Thu Jun 5 19:35:59 CEST 2008
On Thu, Jun 05, 2008 at 09:08:13AM +0200, Werner Koch wrote:
> On Wed, 4 Jun 2008 23:30, dshaw at jabberwocky.com said:
> > Expiration dates in OpenPGP are calculated as the offset from the key
> > creation time, not 1970. Only the key creation time is calculated
> > from 1970. Both are 32-bit values, so the maximum expiration is
> > 4294967295 seconds + 4294967295 seconds == 272 years. Leaving out
> > leap years for simplicity, 1970 + 272 == 2242.
> Right. But with a 32 bit type it is hard to work with these values. In
> fact it is not easily possible to use a 64 bit type for computation on
> some machines at all. Recall the problems we had with TIGER/192.
> > GPG has the limitation of treating an expiration time as an absolute,
> > rather than a relative offset from the key creation time, but this is
> > not an OpenPGP issue.
> You suggest to replace the skalar value by a vector of creationtime,
> exipration? I think this is too complicated to understand and has only
> limited purpose. Given that in 2038 almost all applications using the
> Epoch scheme will suffer from major problems , another upgrade path
> should be worked on.
No, I think the current scheme is too baked into the code to make
changing it reasonable. However, we can do a lot better than
translating "99y" into a key that is instantly expired. Even
returning an error there would be an improvement.
Amusingly enough, GPG used to handle this a bit better than it does
now. A few years ago, a 99y value would at least be placed correctly
in the expiration subpacket. It would fail when *using* the key, but
at least the key on disk was sane. The current behavior stems from a
bugfix around updating existing signatures that have expiration
More information about the Gnupg-devel