Mailing List Archive

Web Key Directory: refreshing keys
Hello,

I would like to ask about the potential ability to refresh keys using
Web Key Directory protocol.

As far as I know WKD can be used to locate keys (via --locate-key et al.
and when verifying signatures with signer's UID embedded) but the keys
retrieved via WKD are refreshed using keyservers only, never their
original location.

Technically that would be possible (as the key origin is preserved).

The disadvantage would be that WKD server operator would see when people
refresh keys within their domain.

I see also some advantages: there are less bytes to download (because
binary, and because keyservers allow anyone to bloat the keys [0] [1])
and that it could allow managing keys without keyservers at all [2] (for
example in case of a hypothetical GDPR-apocalypse).

Would refresh via WKD be a good idea?

Thanks for your input!

Kind regards,
Wiktor


[0]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57

[1]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/60

[2]: Of course someone else can put the keys in keyservers anyway but I
mean providing authoritative key updates on WKD host.

--
*/metacode/*
Re: Web Key Directory: refreshing keys [ In reply to ]
On 25/06/18 12:03, Wiktor Kwapisiewicz via Gnupg-devel wrote:
> Would refresh via WKD be a good idea?

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.

--
Andrew Gallagher
Re: Web Key Directory: refreshing keys [ In reply to ]
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@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