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
j...@somewhere.com, it fetches that key id and adds it to your keyring.
If you get an email from a different key claiming j...@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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
