Pubkey Distribution Concept

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

See overview page.

Contents

  1. Pubkey Distribution Concept
    1. Proposed solution
      1. Ask the mail service provider (MSP)
      2. Manage pubkey by email
      3. Fallback method
    2. Design goals and constrains
    3. (Old) discussion
      1. Mail Service Provider
    4. Less attractive alternatives/documenting the design process
      1. Managing by HTTPS
      2. Resorting to a central fallback server
      3. Using classic (pub)"key" servers
    5. Related work
      1. Future other services?

Proposed solution

To find the pubkey of a given email-address an email client should:

  1. Check its local cache
  2. Ask the mail service provider via HTTPS, as specified in https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service
  3. Ask the mail service prodiver via DNS(SEC), as specified in https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey
  4. Consult a classic pubkey server (to see if there is a single match)
  5. Resort to a fallback method using an initial email exchange.

Ask the mail service provider (MSP)

See WKD draft spec 01

TODO outline draft.

TODO: describe diagram, note licences (look into the metadata, it's basically CC-BY-SA except one contained image).attachment:web-key-service-discovery.svg: image:web-key-service-discovery.svg

For DNS(SEC) see DANE.

Manage pubkey by email

See draft spec 01

Fallback method

TODO: describe fallback method with an initial email exchange via signature and pubkey servers.

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:

  1. How can I get the cert for the email address? ("Discovery", "cert distribution")
  2. 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

  1. a protocol to ask the MSP for the certificate of a specific email address
  2. 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 2016-05-04 16:12:19 ] [ What if someone does not want to get encrypted emails anymore? Usually action should be undoable, this holds for activating this service. -- bernhard 2016-05-06 15:25:43 ]

Some design criteria:

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 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:

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:

Open question:

Less attractive alternatives/documenting the design process

TODO documenting main disregarded alternatives and the design process

Managing by HTTPS

It would be possible to manage the uploading of pubkeys to the mailserver-provider via an authenticated HTTPS connection.

This is considered less attractive than handling by email because it is estimated to be harder to implement overall.

The advantages of authenticated HTTPS would have been:

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:

The main drawbacks:

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.

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.

EasyGpg2016/PubkeyDistributionConcept (last edited 2016-09-14 13:59:26 by bernhard)