= Pubkey Distribution Concept

** Status: Document should show the state of discussion, feedback wanted! ** (e.g. use gnupg-devel@).

<<TableOfContents(3)>>

== Proposed solution

Given an email-address an email client should:
# Check its local cache
# Ask the mail service provider via ~H~TTPS, as specified in https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service
# Ask the mail service prodiver via ~DNS(SEC), as specified in https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey
# Consult a classic pubkey server (to see if there is a single match)
# Resort to a fallback method using an initial email exchange.

=== Ask the mail service provider (MSP)

See [[https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service|WKD draft spec 01]] 

TODO outline draft.

For DNS(SEC) see [[https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey|DANE]].

=== Manage pubkey by email

See [[https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service|draft spec 01]] 

== Design goals and constrains

According to user story T1 in [[EasyGpg2016/VisionAndStories]] we want to find a single
certificate for a given email address even if there has not been previous email exchange. 
It has to work without user interaction (to the extend possible).
In T2 and T3 we think about what happens if the communication partner is not ready for this communication.

Assuming both partners have already been set up, we have to solve the following problems 
reliably without user interaction:
# How can I get the cert for the email address? ("Discovery", "cert distribution")
# How can I gain some basic level of trust that this is the current cert of the owner with the email address he wants me to use ("building trust" or "validation").

Within the ~EasyGpg-contract we are attempting a solution that is comparatively easy to implement
to raise chances that it will actually widen the user base. It shall also be designed in a way that it can
be introduced step by step together with existing and coming solutions ("lean" introduction).
The main design idea is to use the already existing relation of an email address owner to his or her mail service provider (MSP).
It is an inherit common interest of both parties to actually provide a verified relationship so that 
only the owner can connect to their email storage. 

The drawback of this design idea is that an man-in-the-middle attack by the MSP is a lot easier 
compared to the web of trust approach where several external parties are involved and users must explicitly
argument about trust relations. The idea is that users with a higher security interest (like Annika or Bob) will build additional
trust using advanced methods, like a mutual check of the fingerprints of their public keys. 
The tracked communication history also allows to detect indications of an ESP trying to attack its users.

TODO Terminology: the OpenPGP community uses the term 'key' or 'public key'. 
Some draft text sections here try how "certificate" or "cert" for the same thing will read, coming from an idea with the ~Gpg4win Compendium
to have a distinction between public and secret key-pair-element, unify the concept with the CMS world and be more friendly towards
readers-without-crypto-experience.


== (Old) discussion

TODO extract current proposal and move alternatives to section below.

=== Mail Service Provider

An email account owner has already trusted their email service provider 
to accept, deliver and possibly store her communication. 
Technically the connection will be done with ~TLS secured protocol variants of
something like ~IMAP (receiving, access to storage), ~SMTP (outbound sending) or ~HTTP in case of a web application.
In each case the user will have to authenticate to use the service.

All we need to use this trust relation is to find 
# a protocol to ask the ~MSP for the certificate of a specific email address
# a way for email applications to give, update, request deletion of their cert from the ~MSP.
  [ There is no need for deletion - if the mail address is taken out of service the key will vanish anyway. -- [[Werner Koch]] <<DateTime(2016-05-04T16:12:19Z)>> ]
    [ What if someone does not want to get encrypted emails anymore? Usually action should be undoable, this holds for activating this service. -- [[bernhard]] <<DateTime(2016-05-06T15:25:43Z)>> ]

Some design criteria:
* they are easy to implement for a mail service provider,
especially the larger it gets. Because that raises the chance of adoption.
* In addition they should not reveal the existence of email-addresses
  [ You can't avoid that [[Werner Koch]] ] [ Why not? An encrypted HTTPS request for one email-address to a mail service provider will not publish this address as opposed if I go to a public cert/key server. -- [[bernhard]] <<DateTime(2016-05-06T15:25:43Z)>> ].
* They are better if they are revealing less about who want to communicate with whom.

~GnuPG 2.1.12 has experimental support for an upcoming draft "Web Key Directory key
   location service" based on the ~HTTPS query idea.

==== Query
The first design idea in the 2011 [[https://g10code.com/steed.html|STEED]] paper was to use DNS 
records and later profit from ~DNSSEC.

https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/?include_text=1

Drawbacks of ~DNS are:
* ~DNSSEC ist not fully deployed everywhere 
* It is unclear if ~DNS can really handle millions of email addresses
  [ Nope: DNS can handle arbitrary amounts of data; the size of a data item is limited but not their numbers. -- [[Werner Koch]] <<DateTime(2016-05-04T16:12:19Z)>> ] [ In theory it is, but are DNS servers and caches ready for the request pattern with millions of emails and more frequent changes in practice? -- [[bernhard]] <<DateTime(2016-05-06T15:25:43Z)>> ]
* The decentral nature of ~DNS may leak more information than necessary. (Question could I protect email addresses with ~DNS?)

An advantage of ~DNS is that there already exist implementations (~GnuPG 2.1) and some real world deployments.

The 2016 design idea is to use a well-known ~URL via an ~HTTPS request.
{{{  https://example.org/.well-known/openpgpkey/hu/XXXXX }}}

Advantages for HTTPS are:
* well understood how to scale high
* no time-out delays
* request details protected by TLS connection, only leaks the information that user may want to communicate with some user of this domain.
* can also be used on the potential fallback server.
* (expected:) adding one more URL to a webservice can be technically separated nicely from other service, DNS may be couple more deeply. 
So it may be easier to convince MSP to try the HTTPS for a while than to add a very dynamic system to their DNS service which will be mission critical.

Open question:
* If we use ~WKD to query with TLS, should be do an DNS request if the TLS request fails or at all?
  The problem is that if we do an DNS request all the time, it will lose the informaiton about the 
  requested email address to people listening during transport.

==== Management

Two ideas exist here, which need to be discussed and decided in finer detail:
# also use an ~HTTPS interface together with authentification 
# use an email submission interface

Implementation ease on the server site probably depends on how easy it is to couple
mail service credentials to the ~HTTPS or ~SMTPS service or insert some crypto processing for incoming emails.
On client side the email handling interface also means the crypto component has to be able to send and 
intercept handling emails. [ Given that the whole thing is for MUAs, this is not a problem at all. -- [[Werner Koch]] <<DateTime(2016-05-04T16:12:19Z)>> ]

~HTTPS may provide a faster feedback if my crypto setup is ready because of the online connection.
 [ Nope: Email verification requires sending and receiving of emails - regardless how it was initially triggered.  -- [[Werner Koch]] <<DateTime(2016-05-04T16:12:19Z)>> ] [ I tend to disagree: Having the credential to access the email service for a specific user is equal to the ability to receive and send email over that address. -- [[bernhard]] <<DateTime(2016-05-06T15:25:43Z)>> ]

TODO further discussion.

== Less attractive alternatives/documenting the design process

TODO documenting main disregarded alternatives and the design process

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

=== Classic "key" (aka cert) servers
If we are back to this point, our of course this means our unattended use 
for sending the email will not work. 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").
Our choice is to offer the user the change 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.

== Related work

* https://keys.mailvelope.com announced in June 2016 as //It's a very simple key server that borrows from Signal to allow ~T~OFU m/automatic key lookup. No key transparency included//.

=== Future other services?

It is possible that other cert distribution concepts will be proposed and implemented
that solve the same problems in a better way. There already are some concepts
of how a decentralized directory can be kept honest in public.

If an email service provider offers a different service for a very large fraction
of users, GnuPG may for practical reasons adopt this method for this particular
MSP.

There is a list of some known other approaches below that may become more relevant in the future.
The goal of the EasyGpg2016 contract is to implement and deploy 
something simple in 2016 as proposed in this concept. 
The other approaches seems to adhere to an improved cert validation via the public
and seem to require more players to join to be more useful than the model proposed here.


TODO , e.g. 
* https://github.com/google/end-to-end/wiki/Key-Distribution
* https://wiki.gnupg.org/OpenPGPEmailSummit201512?highlight=Transparent%20Keyservers

* https://coniks.cs.princeton.edu/
* https://github.com/yahoo/coname 
* https://www.certificate-transparency.org/

* A research project about the legal angle of pub-key distribution (2016-01 to 2017-12 in de_DE): https://www.uni-kassel.de/fb07/institute/iwr/personen-fachgebiete/rossnagel-prof-dr/forschung/provet/vertrauenswuerdige-verteilung-von-verschluesselungsschluesseln.html linked from http://www.heise.de/newsticker/meldung/Bund-gibt-Foerdermittel-fuer-Selbstdatenschutz-frei-3224514.html