Extending the key expiration date (fwd)

JanuszA.Urbanowicz JanuszA.Urbanowicz
Thu Sep 6 21:31:02 2001


--ELM999805114-26671-0_
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit

This accidentally got sent to Werner instead to the list. Apologies.

Alex
-- 
Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary

Gdy daję biednym chleb, nazywają mnie świętym. Gdy pytam, 
dlaczego biedni nie mają chleba, nazywają mnie komunistą. - abp. Helder Camara

--ELM999805114-26671-0_
Content-Type: message/rfc822
Content-Disposition: inline
Content-Description: Forwarded message from Janusz A . Urbanowicz
Content-Transfer-Encoding: 8bit

Subject: Re: Extending the key expiration date
In-Reply-To: <87ofoop7in.fsf@alberti.gnupg.de> from Werner Koch at "Sep 6, 2001
	07:13:20 pm"
To: Werner Koch <wk@gnupg.org>
Date: Thu, 6 Sep 2001 21:15:14 +0200 (CEST)
From: Janusz A. Urbanowicz <alex@bofh.torun.pl>
X-Latin-Date: Hodie post. Non. Sep. MMDCCLIV AUC est
X-Mayan-Date: 12.19.08.09.14
X-Erisian-Date: Prickle-Prickle, Bureaucracy 30, 3167 YOLD 
X-Operating-System: Linux sword 2.2.16 i586
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit
Content-Length:  2514

Florian Weimer wrote/napisał[a]/schrieb:

> > > 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.
To quote Werner "There are 42 ways and more for root to do anything". If the attacker has your private key, and you know it, you revoke the key. If you don't know but you have set the expiration date you are prone to MITM. If you Don't want MiTM, you use one master signing key to authorize your subkeys you are prone to stealing the master secret key along with the subkeys's secret key.
> > 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.
Which is difficult to organize succesfully (have you actually TRIED to get *decent* amount of key signatures _again_an_again,_year_by_year_?). And uncertified key leads to MITM.
> > and pollutes the keyrings.
>
> That's a problem, admittedly. But your approach is insecure.
Yours is insecure in more subtle way. In perfect world it would be secure. But we live in imperfect world so they are about evenly insecure. How many keys you have certified to the point of being trusted? Do you believe in signatures made by non-fully trusted keys? With your method, this will be yet more common to believe untrusted key, because it will be a lot harder to get a key to trusted level. Moreover you refer to 'consensus of expiring private keys'. Well, its the first time I hear about such a consensus in the context of PGP keys. There is no consensus that I'm aware of. No publicly avaliable PGP guides I know of advise that. There is no such a consensus. Sidenote: Crypto revolution and PGP in particular failed spectacularly to catch in mainstream because public-key crypto is hard to learn and maintain. Think about it. Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daję biednym chleb, nazywają mnie świętym. Gdy pytam, dlaczego biedni nie mają chleba, nazywają mnie komunistą. - abp. Helder Camara --ELM999805114-26671-0_--