WKS: discussion, attach pubkey always?
bernhard at intevation.de
Wed Sep 14 16:59:15 CEST 2016
I'm making an effort to write down why some aspects in the
web key service are proposed as they are.
Here are new sections, in which I am trying to catch the thinking.
Werner, did I get this right?
@all, am I missing important aspects?
== Less attractive alternatives/documenting the design process
TODO documenting main disregarded alternatives and the design process
=== Only using email exchanges (and no lookup)
Possible advantages are
* Discovery of the pubkey to an email address is
more difficult. It would depend on the user replying, thus the user
can decide with whom to pick up encrypted communications.
* There is no need to choose an MSP that support WKS.
* Attack by the MSP as man-in-the middle there is no real advantage.
Of course it is slightly easier to just send out a wrong pubkey via HTTPS,
but this can also be done via email, as all emails goes through the MSP
anyway. On the other hand it is a little harder to anonymously check that
the MSP is serving the same pubkey
for you that you also hold. By email, the MSP just filters this for a number
of recipients, for HTTPS you could just go to a different network connection
which is harder to detect by the MSP.
Considered less attractive because:
* Lot of (first) emails would go unencrypted that could easily be encrypted.
Think of confirmation emails to web purchases or when replying
to all that have received an email.
* Drawbacks for always attaching a pubkey (see below).
=== Attaching a pubkey to all emails
The idea is to always attach one pubkey to all emails the user sends out.
This could help with
* No pubkey-server lookup necessary,
in case of users without WKS supporting MSP.
Considered less attractive because:
* size, some pubkeys are quite large (1 Mebibyte)
and we want to continue using the existing trust information in addition.
* a pubkeyserver lookup is strongly recommended anyway looking for
=== Managing by HTTPS
It would be possible to manage the uploading of pubkeys to the
mailserver-provider via an authenticated HT~TPS connection.
This is **considered less attractive than handling by email
because it is estimated to be harder to implement overall**.
* Early examinations by expert hint towards that
it is easier to get into the mail processing chain for ~MUAs
than to be able to reuse or resent the authentication credentials
for TLS connections. The send, receiving the raw-mail itself is a task
of the MUA that will also need to have hooks for crypto to work
on the mail-structure itself. The TLS credentials used for IMAPS and SMTPS
may be hidden in a different module and probably cannot
just be reused by extensions, to protect them against less carefully written
The experts are [[Werner Koch]] (e.g. has implemented significant code for
mutt, GpgOL Outlook, gnus and Thunderbird)
and [[Andre Heinecke]] (e.g. has implemented significant code for KMail,
GpgOL Outlook and Thunderbird).
* An email implementation makes it easier to support offline systems
(carrying over the emails over by other means). Email is already
asynchronous. Doing a challenge response method that allows disconnections
with HTTPS is possible, but much harder.
* Email already has build-in queue handling on server and client side.
A server module that only works one submission inbox is nicely separated
from the rest of the system.
* On server side, the HTTPS server may not have direct access to the email
credentials of the users.
The advantages of authenticated HTTPS would have been:
* faster turn-around time and better feedback until the pubkey is available
from the MSP.
Probably seconds as opposed to minutes.
* No need to intercept emails on client side.
* No need for email crypto processing on server side, if the authentication is
considered sufficient. (Someone who can authenticate towards the MSP as
user, is always able to request and confirm a different pubkey to be
=== Resorting to a central fallback server
In case if the MSP does not support a pubkey service,
it was proposed to use a central fallback server.
The main advantage:
* Users can use crypto, starting with the first email
The main drawbacks:
* A single point of failure (or attack surface)
* Takes away some incentive for MSP to offer a pubkey service.
Overall an email exchange as fallback method
is prefered because it is close to a natural way users build up trust
in first email exchanges and comes without the drawbacks of the central
See more discussion at [[/FallbackServer]].
=== Using classic (pub)"key" servers
Our **unattended use for sending the email would not work** in many cases.
It would be by pure chance that only one public user id will be found on the
public servers ("discovery") and that it carries a signature from a cert that
I already "trust" to sign others ("validation"). Anyone can upload a pubkey
with a speficia email address. Our choice is to offer the user the chance to
go to a more complex full-blown certificate management handling or to offer
hints to contact the communication partner to adopt the scheme proposed here.
However asking cert servers can be a good idea to sometimes find revocation
certificates for certs I already know. This is important if the earlier
stages fail which is always a possibility in the near future. So a
cert-server check is part of our proposed steps.
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: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel