best practice for pgp mail service, revoking keys

[Ingo Klöcker]

On Thursday 24 April 2014 21:07:54 tim at piratemail.se wrote:
> 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.

I would not allow re-usage of email addresses because even a 1 year 
"fallow" time might be too short, e.g. for some services you might get 
an invoice once a year and, since you are obviously concerned about 
privacy, you surely wouldn't want this message to be sent to the wrong 
person. IMHO used email addresses are burned for all eternity (unless, 
some time in the future, there will be other mechanisms, e.g. ubiquitous 
end-to-end encryption, that prevent the disclosure of private 
information in emails that have gone astray).


> But at the same time, when a user renews a key, will the existing WoT
> signatures become invalid?

No. Each signature has an individual expiration date (or none). When you 
sign a user id which has an expiration date then gpg proposes to use the 
same expiration date for your signature, but you are free to set another 
expiration date (including no expiration) for your signature.


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

As mentioned above you could use a 1-year-expiration for the 
certification of the user's key with the 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.

Definitely makes sense.


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

Given 2. you should always take the prefered key first. If there's no 
prefered key, then I'd follow gpg's practise and take the newest valid 
key (and ask the user whether he is okay with the choice).


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

KMail relies on gpg to make the best choice. I suggest to do the same. I 
see no reason to invent a new trust-scheme.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140426/6e125626/attachment-0001.sig>