One alternative to SMTP for email: Confidant Mail

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Thursday 26 March 2015 at 11:57:43 PM, in
<mid:55149CF7.2070400 at confidantmail.org>, Mike Ingle wrote:



> 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.


Why should the user need to delete one, rather than just be told there
were two and the one with such-and-such a fingerprint (or the one
highlighted) signed this message? If it is just a string in a key UID
rather than a functional email address, it will not necessarily be
unique.



> 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.

I guess a future UI enhancement might be the ability to specify a key
id in a contact list entry. Or something akin to Enigmail's
Per-recipient rules.



> Think I should rephrase that like, "SMTP-style
> addresses can be used to look up keys"?

I think it is a good idea to re-phrase it so that you are not stating
the user can keep their existing SMTP email address, and also to make
it clear this identifier is used only for key look-up and not for
message delivery.


> It is true that
> people can always keep and use their existing address,
> but others can potentially generate fake keys for that
> address.

It is also true that some email providers recycle email addresses that
have fallen out of use. Out of seven yahoo addresses I used for
consecutive periods between 2004 and 2009, six are currently available
to be registered. (The odd-one-out is from 2006.) I have left each one
active with an auto-forward to the next.



> 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.

That is re-assuring to hear. See also my first comment, above.



> 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.

In a similar way to a file that has not been requested for a
relatively long time dropping off a peer-to-peer filesharing network?



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

Or subsequently received a message from the imposter, then goes back
to look at the message that was not from the imposter, presumably.



> Yes I am worried about the bogus keys problem. Just not
> sure how to  handle it in a peer to peer system.

Is there a way to incorporate some sort of challenge/response at key
creation time before the key is uploaded to the peer-to-peer system?
Or could the challenge/response be handled by a number of
"verification agents" incorporated into the peer-to-peer network?



> Anyone can run
> a provider and I expect them to range  from strictly
> business to the dodgy darknet variety.

Using "darknet" services to enhance privacy does not equate to
"dodgy". A person's communications are none of anybody else's
business, apart from whoever they choose to communicate with.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Oven mitt: A partially charred grease stain that fits over the hand.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJVFsHZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwa/EH/iv0O00KWyhNB4hg6eHEgeZM
xRIZj2ZuKqM7nAB9sjSAkHuqBMYUyOK1ax/E27oxC7nCV0STPA8f7SYU5BD/Mgyw
6AJaDeHf78iS9DpMf3ffbKRZQAK2Nv4Sh4NzTzi7eOKIc2Q/vTezWD9NZSvmlAWQ
2+1aVoYHjGFcqeb73FVssQNJfExjnkCeK4RdngEoDFbwwAAb1TZ+Riggv5EqhPrv
WntSpz0UyBoult1oAkhut0UIdsfdUZeCUBMYss8EVFaGD0JPPkZRj55QdtUaMGhF
vo59Pi1Yvwh6lXgcSIubp5HgEDvKjAZf5nyAHjemk4pNuLTvFWjsBjhXBnGxDSGI
vgQBFgoAZgUCVRbB318UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45JQCAQDpDKWBL+9PUZsY8wZt2X1f1KVN
STpTVBfz4Bve7y/0swEAXCBuKgk0objXBzFT5WQqwP+KKhWYZYqTGVFOmuNPdg8=
=ugkT
-----END PGP SIGNATURE-----