GnuPG master has now the tools for this build option to enable them is --enable-wks-tools. We have a running test service at test.gnupg.org.

To see the workflow:

• Generate a test key:

export GNUPGHOME=$(mktemp -d)
gpg2 --quick-gen-key testuser1@test.gnupg.org

Will show the fingerprint after creation. Then you create the publishing request with:

./tools/gpg-wks-client --create EE6C1A19183EB3FA59551A304A409D7B27CBC05B testuser1@test.gnupg.org > /tmp/request.mbox

Where EE... is the fingerprint.
In

sendmail -f testuser1@test.gnupg.org -t key-submission@test.gnupg.org < /tmp/request.mbox

test.gnupg.org will then reply with a

./tools/gpg-wks-client --receive < /tmp/response.mbox > /tmp/confirm.mbox

To handle the response the Passphrase is needed as it will be encrypted so this step should be manually triggered by the user.

After sending the confirmation mail there is no other mail sent by the server. Some time later the key should show up in the WKD and can be retrieved through a KeyForMailboxJob or on command line:

GNUPGHOME=$(mktemp -d) gpg2 --auto-key-locate wkd --locate-keys testuser1@test.gnupg.org

The API I plan for this in qgpgme are two Jobs.
Something like:

/** Create a WKS Publish request or check if publishing is available for this mailbox.
 *
 * key: The key to publish.
 * mailbox: The mailbox of the UserID to publish.
 */
GpgME::Result WKSPublishJob::start(GpgME::Key key, const QString &mailbox);


Q_SIGNALS:
  /* The result signal with the generated mail and the usual cruft */
  void result(const GpgME::Error &result, const QByteArray &mail, const QString &auditLogAsHtml = QString(), const GpgME::Error &auditLogError = GpgME::Error());

Similarly:

GpgME::Error WKSConfirmJob::start(const QByteArray &response);

With the result containing the mail.

In KMail we only need to handle the sending of the mails then. And probably
a nice mime-type handler to show a pretty button and some info when looking
at the confirmation mail.

All the handling which service to use how something should be formatted etc.
will be handled in GnuPG. We have to add installation of wks-client in gnupg though and add gpgme api to call the tools first. (yay layers)

I've added a corresponding QGpgMEJob to GpgME-1.7.0 gpgme.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/qt/src/wkspublishjob.h

There is also a test for it in lang/qt/tests/t-wkspublish.cpp

This needs GnuPG 2.1.16 (meaning master as 2.1.16 is unreleased) because we just added "--supported" as an action to the wks tools so that we can check if a Web Key Service is offered for a Mail.

As I would not like to backport / duplicate it in libkleo's qgpgme because we also use a new feature from gpgconf / gpgme to find the install directory of the wks-tools at runtime.

So I guess this a bit blocked by T3158 :-/

There is now also an explanation how to set this up on the server side: https://wiki.gnupg.org/WKS

There will be a new draft of the protocol soon, Werner changed the spec a small bit (not yet written but already implemented in gnupg-master) so that the response.mbox will look differently. It will be a multipart mail with a text part that explains what this mail is and how it should be used (We can probably hide that in KMail as we handle it ourself) And an attachment with the WKS Content-Type. The idea is to make it easier to use a Web Key Service if a MUA does not support it directly. So instead of having to export the mbox file you can just open the attachment with an external tool.

Kleopatra will probably get support for this so that it can be used (albeit uncomfortably) on Windows.

The new tools are not yet installed on test.gnupg.org so I can't easily create an example.

Here is the new draft: https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-02.txt

In D3214#59883, @dvratil wrote:

In D3214#59860, @aheinecke wrote:

I would like improve it some more to do the publishing check before the checkbox is shown so that we can show different messages or offer to publish the key on the normal keyservers but as a first version I think it would be fine to commit this.

Do you mean something like automatically switching to publishing on PKS instead of WKD when it's not available?

Let's discuss some Improvements I wish here. I'm adding Björn, too because these wishes are mostly about usability.
This is the first time the user encounters crypto in KMail so we have a high risk of loosing them here already.

This is also where e use Public / Private Key for the first time.
And public / private keys are a difficult concept.

• The goal is to have little user interaction.
• Set up crypto even if the user does not know about OpenPGP / GnuPG, so less technically scary words.
• A minor explanation whats going on when publishing.

From the wording I think we should describe WKS as "Registering your Key with your Provider" as that is what it does and also this follows the "Confirm your Registration" pattern.

From this page I think the "Security: Always sign and encrypt outgoing mails" can be removed as we now have a dedicated "Secure your communication page" so it's better if all security options are together.
Once editing is finished on the mail address we can start the check if WKS publishing is supported.

Here I would add a checkbox for "Secure outgoing mails, if possible." To replace the "Security:" Combobox from the first page. I think it's better if we only provide the one option here.

A possible tooltip:

When sending mails KMail automatically looks for encryption keys of your recipients and secures the mail when keys for each recipient can be found. It also signs your mails cryptographically so that it can be verified that your messages have not been tampered with.

This checkbox is disabled when "No key" is selected. But checked by default.

The publish key automatically I would like to see as "Find provider settings on the Internet" on the first page. In a frame with some text that is enabled / disabled. The checkbox should also be disabled if No key is selected.

For publishing I see the two cases: WKS Supported, WKS not supported.

1. WKS supported:

checkbox label: "Register this key with your Mailprovider."

long text we could put there would be:

Your Mailprovider supports a service to provide your public key so that others can find it.
This means that your public key can be queried from your Mailprovider and others can then use it to secure their mails with you.

Default state: checked

2. WKS unsupported:

checkbox label: "Publish this key on Public Keyservers"

I'm very unsure about the long text here.
What I want to say is:

• Your MSP does not support WKS, this is bad. Others are better.
• There is an alterative but this alternative is not good because:
  • It can easily be searched / indexed, might lead to spam.
  • Is an add only system so you can never remove the key only revoke it.
• But publishing on a Keyserver is better then no publishing at all.

Your Mailprovider does not support to register your public key with it.
Checking this will publish your key on a public keyserver and add it to the dataset of all published keys.

(The rationale being that "Something from me is added to a dataset, that sounds scary, I don't want that" for users that are so concerned about data protection that they don't want to publish their key on the public keyserver.)

Default state: unchecked

For the first Paragraph, maybe, (suggestions welcome):

Protect yourself against surveillance by encrypting your Mails with GnuPG. By generating or selecting a public / private key pair now mails can be encrypted using the public key while only you can decrypt them with your private key.