PGP bet practices when key expires?

[vab at MIT.EDU (V. Alex Brennen)]

On Fri, 2006-08-11 at 13:29 -0400, John Abreau wrote:

> I just noticed that my GnuPG key expired today. I ran "gpg
> --edit-key", extended the expiration date another year, and
> then pushed it out to the keyserver at subkeys.pgp.net.
> 
> Is this the correct way to update a key?

Yes.  However, it would have been best practice to generate a new key 
pair before the old key pair expired.  Then, to use the old key pair
to sign the new key pair there by linking it into the web of trust.

After doing that, you could have mailed all of the people who signed 
your old key in the past requesting that they sign the new key.  Upon
receiving a note with a signature from a key that they explicitly trust,
or with a signature from a key signed by a key that they explicitly 
trust, they should be willing to trust the new key enough to sign it.

There is nothing inherently wrong with extending the key's expiration
date. But, I think that before some one does that they should
themselves - "What has changed about the threat model that I now trust
this key to be valid for a longer period of time than I did when I first
generated  it?"  Historically, cryptographic algorithms, protocols, and 
systems have always gotten easier to break over time. 

Additionally, it's beneficial to change keys every few years because
if a key is ever compromised only the signatures for a limited amount
of time are compromised.  The compromise is limited to the amount of
time that you had used that specific compromised key, rather than
every signature that you've ever made.

Finally, if an attacker managed to get someone to sign an invalid 
key and every one expired their keys regularly, that key would
eventually fall out of the currently unexpired web of trust.


> Are there any issues I need to address, that might arise because
> the key had expired before I extended its expiration date?

No.

The only possibility of concern is that an expired copy of
your public key is still circulating out there.  Perhaps, on
another Key Server network.  But, that  shouldn't cause you 
any significant problems.

In regards to the key material itself:

In Version 3, the expiration date of the key is coded into the
public key material.  The self signature by the secret key on
the public key material validates the expiration date.  The
OpenPGP standard does not allow for a public key to include
multiple key expiration date packets.  So, once someone receives
the copy of your public key with the updated expiration date, no
history of the old expiration date will have been maintained.  But,
You should no longer use a Version 3 key due to technical weaknesses
in the design of PGP Version 3.

In Version 4, the expiration date of the key is coded into the 
a signature subpacket of the self signature made on the key. A
signature contaning multiple signature expiration time subpackets
is not valid.  A correctly working OpenPGP compliant PGP 
implementation would respect the self signature with the latest 
creation time as authoritative.  If you wanted to, you could 
delete the older self signature with GnuPG using the --edit-key
command line option.


   - VAB
-
V. Alex Brennen                   vab at MIT.EDU
UNIX Systems Administrator
MIT Libraries       http://libraries.mit.edu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.blu.org/pipermail/discuss/attachments/20060901/b3b0a1f2/attachment.sig>