One alternative to SMTP for email: Confidant Mail

[Mike Ingle]

>> At present, there is no key verification built in and
>> you have to check the key fingerprint (which is always
>> shown to the right of the address) or check a signature
>> chain on your key using a GPG key manager.
>>     
>
> Or you can Trust On First Use, if it suits your threat model.
>
>   
That's more or less what it does. When you get an email from 
joe at somewhere.com, it fetches that key id and adds it to your keyring. 
If you get an email from a different key claiming joe at somewhere.com, it 
also fetches that key id and adds it, but now messages from both users 
show a key collision until you go delete one of those keys. Likewise, 
while you have a key collision, you cannot email that user by typing his 
email address. You have to type or click the key id. In that way it 
forces you to deal with it when and if you get a collision.

>  MFPA>>The intro page on your website says "SMTP-compatible
>  >>address format: keep your existing email address".
>  >>Have you checked whether google (or any other email
>  >>provider) might have something to say about using
>  >>addresses at their email domain name on a completely
>  >>unrelated service?
>
>   
>> They very well might, if I was the one making such
>> claims. The claim is made by whoever created the key,
>> and it is just a claim.
>>     
>
> You are the one stating that the user can keep their existing SMTP
> email address to use on CM. Given that you do not have a process in
> place to verify the user's SMTP email address, I think that is a
> pretty bold statement.
>   
Think I should rephrase that like, "SMTP-style addresses can be used to 
look up keys"?
It is true that people can always keep and use their existing address, 
but others can potentially
generate fake keys for that address.
> Any thoughts on the possible outcomes when a high-profile
> politician/celebrity/company with deep pockets finds they are unable
> to effectively use their SMTP email address on CM due to messages
> showing a key collision and the automatic lookup refusing to match
> because somebody got the address first? Maybe nothing, but worthy of
> consideration.
>
>   
The celebrity will not be blocked because there is no central key 
directory. It's possible some impostor will start using a celebrity's 
email address on CM. Then when the real celebrity wants to use it, he 
will tweet "My real CM key id is (some hash), please ignore those 
impostors" and hopefully that will resolve it. It's similar to regular 
PGP keyservers in that it will accept any key someone wants to post. The 
main difference is keys expire after a month or so if they are not 
re-posted.

The only person who will see a key collision is one who previously 
received a message from the impostor.

Yes I am worried about the bogus keys problem. Just not sure how to 
handle it in a peer to peer system. For business use I like the SSL 
approach.
>
>   
>> It's much like using a gmail
>> address as your username on a website - purely a
>> shortcut identifier. Not to be trusted.
>>     
>
> I have used websites and services where usernames are email addresses,
> but not without some form of challenge/response. (Click the link in
> the email, reply to the email, enter the code that was in the
> encrypted email, etc.)
>   
That is a good idea and if I build a commercial provider I will probably 
implement that. Anyone can run a provider and I expect them to range 
from strictly business to the dodgy darknet variety.

Mike