Key expires at ... 1971

[David Shaw]

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 [1], 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
subpackets.

David