WKD vs VV and VVV
bernhard at intevation.de
Wed Apr 25 08:49:54 CEST 2018
Since 2-3 years there is a struggle about distributing public keys
to enable a better user experience with end-to-end crypto.
As you may know, https://wiki.gnupg.org/WKD
is the approach that g10code and Intevation have chosen May 2016
and which is fully implemented in GnuPG 2.2.
I've briefly looked at two other initiatives in Germany, which basically ran
in parallel or a little later than the contract that resulted in WKD.
link to a number of papers describing the approaches and results
of https://volksverschluesselung.de/ (VV)
and Vertrauenswürdige Verteilung von Verschlüsselungsschlüsseln (VVV).
All in German.
* [VV] is a central distribution of pubkeys and wants to strongly associate
pubkey to person, thus does not have anonymity on its goals.
* VVV papers criticise that a DNS record per email-address
would not scale with DNS.
That aligns with one of our arguments against using DNS.
* VVV uses DNS SRV records to point to a special HKP server
for each email provider. [BVVV] put forth arguments against WKD/WKS,
remarks to some:
** inconsistency because pubkey management via policy file HTTPS and later
SMTP but lookup with HTTPS
They did not comment on the rationale that this management
way may possibly be more easily implemented with email clients and fit
an asynchronus email workflow better.
** No revoke, no requirements for keys like length,
no anti-brute-force-strategy specified.
Comment: WKD was aimed for being a "lean" spec, where the main problem
is solved first, and less important ones refined later with more
experience in the wild. I'm not sure what they would want the
"anti-brute-force-strategy" for as WKD is not "walkable" and you need to
know the email-address before you request a pubkey.
** no distribution of old pubkeys for old signatures.
This may be a valid use case once the main use cases are solved.
** Email provider needs "full control" about the webserver of the same
We point out this problem as well, though WKD does not need "full" access
as an internal proxing or a https redirect also works. (Right now this is
a point of discussion about evolving WKD as v05 offers DNS SRV records
that some clients cannot easily implement. My personal stand is to use
HTTPS and one of the redirection methods if necessary until this is
a broader consensus.)
** No definition of how the HTTPS service is secured.
For larger email providers, they have a valid interest to keep their
domain secured, so that is not worth mentioning. But for people with
their own webside or smaller prodivers without weblogin on the email
domain this could be an addition to WKD to give some hints about how to
secure the main domain.
** Because no authentication is needed when submitting a pubkey via SMTP,
it shall be possible to use this management servive as
This is something I don't understand as WKD is not walkable.
* The VVV procedure requires DNS records, and thus cannot be implemented by
an external helper, either on the operating system side with native
messaging or on the server. This is an implementation drawback.
Anotherone is that many folks do not have access or are very conservative
about their DNS records. And that use DNSSEC cannot be reliable checked
from a client.
Those implementation difficulties lead us to using HTTPS for the lookup
* A legal paper [R] makes a point that a service handing out public keys
with some metadata like the name is like a phone book service and thus
would be subject to data privacy directives that would require the
user to be informed and thoroughly asked before publishing something.
Of course this goes against the goal of doing encryption mostly in the
background and it a major hurdle for designing a good user experience
The WKD style of only allowing the email address to be present as metadata
in the pubkey has the advantage that (in my very limited legal
understanding) it is not a personal data record in a phone book like
service, as you already have to know the email address before you can
ask a WKD service of the provider for the pubkey. So there is no
"publication" of personal data going on and if really necessary
email providers could put a remark in their terms of service.
Overall WKD should allow to implement a better user experience in the
* I haven't easily found source code for the prototype implementation
of [VVV] on the webpage. GnuPG 2.2 is out there, KMail, Enigmail, GpgOL
implement a good part of WKD with still more user experience work on
[BVVV] Beschreibung der VVV-Lösung
Peter Fischer, Ulrich Waldmann, Jan 2017
[R] Rechtliche Problemstellungen der Ende-zu-Ende-Verschlüsselung:
Anforderungen des künftigen europäischen Datenschutzrechts an die
vertrauenswürdige Verteilung von Verschlüsselungsschlüsseln
Stephan Blazy, Susan Gonscherowski, Annika Selzer, Sept 2017
[VVV] Verfahren zur vertrauenswürdigen Verteilung von
Peter Fischer, Thomas Kunz, Katharina Lorenz, Ulrich Waldmann, July 2017
[VV] Die Volksverschlüsselung: Förderung vertrauenswürdiger
Ende-zu-Ende-Verschlüsselung durch benutzerfreundliches Schlüssel- und
Dominik Spychalski, Levona Eckstein, Michael Herfert, Daniel Trick, Tatjana
Rubinstein, Jun 2017
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel