a Question about Key Servers

[Daniel Kahn Gillmor]

On 08/25/2011 10:04 AM, Robert J. Hansen wrote:

> Now, maybe you have thousands of keys on your keyring and it takes a
> ridiculous amount of time, but I suspect you're a bit of an outlier.

Yes, it's true, and yes, i'm an outlier.  At the moment.

> The problem for any system of automated certificate refreshment is
> making it general enough to accommodate power users with thousands of
> certificates, and yet simple enough for the 95% of users who have
> X-or-fewer certificates (where I suspect X < 50).  That's a very
> difficult problem and I'm happy for GnuPG to kick this one to the users
> and say "refreshing the keyrings is your problem."

Except that, quite clearly, most users have no idea it is their problem
and the problem remains unsolved.

Why not try to solve the problem, or at least enable users to choose one
of a pre-defined set of reasonable refresh heuristics for gpg to
implement on their behalf?

Please read https://bugs.g10code.com/gnupg/issue1235 for decent
arguments about why this is the right thing to do.

> Absent hooks in GPGME, I don't think there's much opportunity for third
> parties to write certificate refreshers.  Doing so would require support
> from GnuPG (adding a "last refreshed field" to each certificate on the
> keyring) and some way to parse the GnuPG keyring independently of
> GnuPG/GPGME, which is ... problematic.

I agree that handling it within gpg is the best option -- gpg is in the
best position to do key management.  However, tools like parcimonie show
that it's possible for a third-party to handle certificate refresh.
It's just a lot of overhead and tracking outside of gpg itself.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110825/084baf19/attachment.pgp>