public keyring management practices (was: Re: GPG Recipients List)

[David Shaw]

On Wed, Dec 03, 2003 at 11:35:33PM -0500, Douglas F. Calvert wrote:
> On Wed, 2003-12-03 at 18:57, David Shaw wrote:
> > On Wed, Dec 03, 2003 at 11:04:19PM +0000, Neil Williams wrote:
> > 
> > > Lengthy trust rebuilds do slow down the email client with new keys
> > > and also slow down KGpg when it opens. However, another reason is
> > > refreshing keys - you can't be sure about a key not being revoked
> > > unless you refresh it so I refresh quite often. Certainly before I
> > > verify packages or encrypt messages to occassional contacts.
> > 
> > I've occasionally toyed with making an option to automatically do a
> > refresh before encrypting, and a different option to automatically do
> > a refresh when verifying.  I haven't done it because the load on the
> > keyservers would be brutal.  I'd be curious if someone has a different
> > take on that, or how they would want such a feature to work.
> 
> What about a keyserver that only handles revocation certificates? Does
> anyone know how many revocation certificates are on the keyservers? And
> how many get added per week?

I don't know.  Jason, do you have any ideas?

I like the idea of a revocation server, but there is a danger of using
an existing keyserver protocol in that a user could point their
revocation-keyserver to the same place as their regular
keyserver.  Since the protocols would be the same, the regular
keyserver would get hammered.

To be sure, there is only so much that can be done to protect users
from doing stupid things, but in this case, it's really more
protecting the keyserver operators from users doing stupid things :)

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 260 bytes
Desc: not available
Url : /pipermail/attachments/20031204/93f20838/attachment.bin