** Work in progress **

According to user story T1 in [[EasyGpg2016/VisionAndStories]] we want to find one
certificate for a given email address for there has not been previous email exchange which works without user interaction.
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 I can gain I gain some basic level of trust that this is the current cert the owner of the email address 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. 
The 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.

== How to find the cert?

We propose the following steps 

# Ask the mail service provider for the recipient email address.
# If the MSP does not support the request: Ask a central fallback server for all email addresses.
# If the fallback server fails, we may resort to trying a classic web of trust "cert server" (aka "key server"). 

Some discussion:

=== Asking the MSP

=== Central fallback server

=== classic "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 distance future. So a cert-server check is part of our proposed steps.

=== Future other services?