WKS: discussion, attach pubkey always?

[Bernhard Reiter]

On https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept
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?

Best,
Bernhard

== 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.

Neutral:
* 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
  revocations.


=== 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
  add-on code.
  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
  uploaded.)

=== 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 
fallback server.

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...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160914/b07d83fe/attachment.sig>