Auto Key Refresh

Neil Williams
Thu Jul 10 01:24:02 2003

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 09 Jul 2003 9:47 pm, CL Gilbert wrote:
> | And this leads to a problem I see with using GnuPG, which is a general
> | problem but more acute when using the product for business:  key update=
> | I know I can refetch a key whenever I feel the need, but I don't recall
> | seeing any way to automagically check for revocations.  I would probably
> | refresh a key manually whenever I'm about to communicate something
> | critical, but in financial transactions that means "every time".
> Auto key refresh, their is a nice idea.  I opt for that.  However, if
> you think the keyservers suck now, just u wait :)

Would it be that much extra work? It would be needed when I select to encry=
an email - that key could be auto-retrieved and an alert generated if revok=
=2D but that's only one key refresh per message.

When I --refresh-keys on one of my public rings, some 300 keys pass by!=20
Depending on my connection, it doesn't seem that I get any delays at the=20
keyserver end.=20

The keyserver would still receive updates at the usual rate and if the bank=
operates a local keyserver for their own keys, it means that the lag time t=
other keyservers is also eliminated. That does require something that was=20
discussed here a little while ago - intelligent fallbacks when using multip=
keyservers in the gpg.conf file. The bank keyserver is hardly going to want=
to keep keys of non-customers/employees so it needs to be the default for=20
those keys that it does hold but gpg needs some way to know not to use it f=
other keys. Could be fun to devise!


Neil Williams

Content-Type: application/pgp-signature
Content-Description: signature

Version: GnuPG v1.2.1 (GNU/Linux)