Extending the key expiration date
Thu Sep 6 17:46:01 2001
"Janusz A. Urbanowicz" <email@example.com> 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