Extending the key expiration date (fwd)

[JanuszA.Urbanowicz]

--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_--