Web Key Directory: refreshing keys

Andre Heinecke aheinecke at intevation.de
Mon Jun 25 16:41:39 CEST 2018


Hi,

On Monday, June 25, 2018 1:15:17 PM CEST Andrew Gallagher wrote:
> On 25/06/18 12:03, Wiktor Kwapisiewicz via Gnupg-devel wrote:
> > Would refresh via WKD be a good idea?

Yes. Especially regarding expiry this is neccessary. We have a default expiry 
nowadays and that needs to be extended automatically through WKD.

There is a task for that:

https://dev.gnupg.org/T2917

You can "force" a WKD update through:

gpg --auto-key-locate clear,nodefault,wkd --locate-key aheinecke at intevation.de

> It might be a good idea if used in addition to keyserver refresh. I
> would be worried that relying on WKD alone would prevent the propagation
> of revocations. At the moment, if you want to block revocation
> distribution you have to take down the entire keyserver network
> (although that's looking more plausible these days!). With WKD you only
> have to block or fake one DNS server.
> 
> The WKD server operator would typically be the same person/organisation
> as the email server operator - so leaking relationship data may not
> necessarily lead to them learning anything more than they already can.

Yes ideally both should be combined. I'm still in favor of having dirmngr 
handle refresh through WKD or Keyservers randomly in the background. But we 
probably need the planned keyring controller process to control that.

Currently I guess it's the response of the client (MUA) to trigger refreshs.

Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180625/eb0d6dea/attachment.sig>


More information about the Gnupg-devel mailing list