best practice for pgp mail service, revoking keys

[tim at piratemail.se]

Thank you for your responses. I'm still mulling over what to do. Your input has been revealing.

I think I'm leaning towards the 1 year key, with a 1 year "fallow" time. For the reasons implied by Daniel, (which I interpolated). I would not want another user grabbing an e-mail account and posing as a previous user.

But at the same time, when a user renews a key, will the existing WoT signatures become invalid? If they do, perhaps it would be better to instead have the designated revoker (me) as described by David. If the co-signers don't become invalid, this seems strange to me.

--

I have also been thinking about how this works into the WoT. Because, as Daniel and one other expressed, anyone can upload a key for a user. How to differentiate.

I'm thinking to do this:
1. User registers, automagically creates pub/priv key. 
Tells me about pub key. 
I sign the pub key with the site key. 
All keys from the e-mail site will be self-signed and as well have the signature of the e-mail site key.

2. Users can "trust", or "be-friend" another email+key. 
When this happens they will sign the other's key, and will also mark that key as the prefered encryption key. 
Maybe that e-mail address will as well be placed on a white list of some sort.

3. The algorithm which picks the "best & default encryption key" for an address, will, instead of picking the key with the latest date (which it does now), will pick the key with the most number of co-signers. (and of course which isn't revoked, or expired)

Does this sound about right?


In existing gpg mail programs, when evaluating the trust level a key, does gpg see if there is a path between yourself and that key, "I didn't sign it, but this other key which I already trust, signed this other key, which signed the key I'm looking at." Or do you count signatures. Or both? 

-tim