Extending the key expiration date

Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE
Thu Sep 6 17:46:01 2001

"Janusz A. Urbanowicz" <alex@bofh.torun.pl> writes:

> I repeat myself - this is what CRLs and revocations are for. If a key has to
> have imposed hard limit, you generate a key with revocation and release the
> revocation after the time limit is up.
CRLs whose length is monotonically increasing are a problem. If there is a general consensus that keys are invalid after their expiration, it is not necessary to include expired keys in CRLs by default.
> > I don't see how your approach differs from not setting a key
> > expiration time at all.
> If key has no limit, it will be valid forever until the revocation is
> released. If a key expired and had expiration date reset to new time limit,
> it means that its owner believes it to be not compromised and prolongs its
> use for next validity period.
An attacker who has obtained access to the private key can do the same, and someone else cannot tell the difference.
> Your method of generating new and new keys has two deficiencies - is prone
> to man in the middle attack,
Yours has the more severe problems. The man in the middle attack problem is solved by the requirement of recertification.
> and pollutes the keyrings.
That's a problem, admittedly. But your approach is insecure. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898