best practice for pgp mail service, revoking keys

[Daniel Kahn Gillmor]

On 04/23/2014 06:13 PM, tim at piratemail.se wrote:

> This is a tiny bit philosophical. Perhaps a little off-topic. I think this is probably the best list to ask never-the-less.
> 
> So I've been working on this pgp base web based mail service.
> https://github.com/timprepscius/mv
> 
> Here is the problem I hope eventually to be confronted with:
> 
> 1. User registers name "decker at piratemail.se," user auto-magically generates a pgp pub/priv key. The pub key is registered on the pgp key servers.
> 2. User goes away. Account is closed.
> 3. User still has "decker at piratemail.se" registered on the pgp key servers.
> 4. Another person wants to use "decker at piratemail.se."  He would generate a brand new pgp key with a later creation date, but still that old one seems like a liability.
> 
> What should I do?
> 
> A few options I can see:
> 1. email addresses are used only once.
> 2. email addresses are used more than once, but with a warning, "there already exists an unrevoked pgp key for this address."
> 3. user gives me a revocation certification when he generates his pgp key, I can revoke accounts which close.
> 4. user generates pgp keys which expire after a year
> 5. ?
> 
> I would like to do #3. But perhaps this is not the way to go. I'm not sure if #4 is possible with the javascript pgp lib I'm using atm.
> 
> Any thoughts?


I'm glad you're thinking about these key and account lifecycle questions
in your design.

note that with expiring keys (option 4) you can always extend the
expiration date if the account is still in use as the expiration date
draws near.

You could make each key with a 1-year expiration date, and if the
account is in use with less than 3 months until the expiration, it could
move the expiration out another year.

Combine this with a policy that a terminated e-mail account's address
can't be re-used within a year (this sort of "fallow" period is a good
idea for other, non-crypto-related reasons too), and it would seem like
you're in pretty good shape.

Please also recognize that *anyone* can put a public key with a given
User ID on the public keyservers.  So while you're taking reasonable
steps to try to limit the confusion that your own system causes for your
users, you probably can't prevent other people from create a key with a
matching User ID and uploading it anyway if they want.

This is why your users ultimately want to rely on strong identity
certifications, and not just the presence of a key on the public keyservers.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140424/75ecf972/attachment.sig>