What would be needed for adoption and ease of use would be for a registry to store public keys and salts... for webmail, a section of the message could be labelled as something like...
The a browser or email plugin can then retrieve the public key for abc@ez.im and confirm the body was sent by who it says it was. Then if the user has already connected via the plugin, their private key is used.
For simplicity the registry will do email validation of its' users, it should issue a SALT so that PBKDFx(SALT + email + passphrase) is used to generate the private key... the public key is stored in the registry.
For more control, a given service entry in dns for peer-crypt registry for the given domain can be set as an authority. A distributed system could be used for confirming tokens combined with DNSSEC as a control system for greater availability.
There are flaws with this idea, but it could be something that can be made insanely easy to use, as well as adding a lot of security to email transmission without creating an all new infrastructure, only adding services on top of what exists.
For power users, they could set the public key without salt in the registries, if they wanted to manage their own, instead of relying on the generation mechanism, or to use/keep the same key across different addresses/providers.
For simplicity the registry will do email validation of its' users, it should issue a SALT so that PBKDFx(SALT + email + passphrase) is used to generate the private key... the public key is stored in the registry.
For more control, a given service entry in dns for peer-crypt registry for the given domain can be set as an authority. A distributed system could be used for confirming tokens combined with DNSSEC as a control system for greater availability.
There are flaws with this idea, but it could be something that can be made insanely easy to use, as well as adding a lot of security to email transmission without creating an all new infrastructure, only adding services on top of what exists.
For power users, they could set the public key without salt in the registries, if they wanted to manage their own, instead of relying on the generation mechanism, or to use/keep the same key across different addresses/providers.