Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for web key directory (WKD). #24

Merged
merged 1 commit into from
Dec 11, 2017
Merged

Remove support for web key directory (WKD). #24

merged 1 commit into from
Dec 11, 2017

Conversation

lambdafu
Copy link
Collaborator

@lambdafu lambdafu commented Dec 11, 2017

The Web Key Directory and Web Key Service is a new proposal for automatic key location and retrieval for OpenPGP. It is the result of a public tender by the German Federal Office for Information Security, and was implemented by g10 Code GmbH and Intevation GmbH in GnuPG.

The basic idea is that the email provider provides an email service to register the openpgp keys for the email addresses it provides. The web server is located through SRV records in DNS, the URL is at a well known location derived from the email address.

I removed support for this because:

  • There is no standard yet for this, only a draft proposal.
  • There is so far very little adoption (posteo.de being the notable exception).
  • It requires buy-in by third-parties (email providers).
  • It is an off-line protocol where email and DNS do the heavy lifting, for something that should just be a simple web service with an email verification process.
  • It requires looking up SRV DNS records on the client side (which is not supported by all dns resolvers, for example by Tor). This means that a client supporting it might have to implement its own DNS resolution.
  • The draft proposal has already accumulated some unrelated cruft, such as DANE. This is not an argument by itself, but it is worrysome that something so simple is made more complicated than it needs to be.
  • There is no solution to malicious providers (the slides from the OpenPGP conf mark that as "future work").

In the future, NeoPG will provide an API to extend key retrieval and trust evaluation, allowing such protocols to be included in applications without tainting the core code base.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant