Extending the "fallback server" section.
|Deletions are marked like this.||Additions are marked like this.|
|Line 32:||Line 32:|
|=== Asking the MSP||=== Mail Service Provider
|Line 64:||Line 66:|
|=== classic "cert servers"||=== Classic "key" (aka cert) servers|
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 of 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").
Mail Service Provider
Central fallback server
What if some mail service providers are slow on the uptake of this concept?
Would our archetype users consider switching to another email provider? Bob probably would, but the others?
The idea of a fallback server is to enable users to participate in the concept without direct support of their mail service provider. This is a main advantage to provide first value quickly to many email users.
But it comes at a number of potential drawbacks:
- A central service requires extra interaction for building the connection between email owner and corresponding cert. It basically becomes some sort of 'validating keyserver' which all of its security problems.
- The more percentage of certs it holds, the more valueable it becomes making it more and more a target for attacks, a single point of failure and harder to operate.
- It may dimish the motivation of MSP to implement the part of the service on their side, because it is already working.
Thus it is an open decision how to deal with a fallback server.
One path of action proposed by -- bernhard 2016-05-04 12:59:37 is to:
- operate the fallback server to bring value faster to people and show that the user experience side works on a wider scale.
- Publish statistics about the number of email addresses from certain mail user providers on the corresponding website.
- Approach mail service providers repeatedly if their email usage is growing over certain numbers.
- Put public limits in for the service in numbers and time. E.g. 2016-11-16: now that 100k user from example.com use the fallback server, we will provide access to them for another three month and after one month warning them of the discontinuing of the service.
- Publicly announce mail service providers that are now offering the service on the same website.
- Help mail service providers to make it really easy to implement their part, e.g. by providing software components and migration support from the fallback server.
- (For being able to inform fallback server users of a change of service, there must be provisions when signing the users up that it is okay to do so later.)
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 distance future. So a cert-server check is part of our proposed steps.