Extending the key expiration date

[Florian Weimer]

"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