--On Friday, December 31, 2021 17:09 -0500 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: >... > It is not in the callsign system itself, but once there is a > directory that maps @alice onto a public key fingerprint plus > a service from which a contact assertion signed under that key > can be obtained, we can bootstrap to new messaging protocols > that give us any desired communication properties very easily. > > The reason SMTP email is so sticky is that all Bob has is the > address alice@xxxxxxxxxxx. So Alice is limited to the set of > protocols supported by example.com in the case of Alice and > the least common denominator in the general case which is > SMTP. There is no way to negotiate a service upgrade to > OpenPGP over SMTP. Sorry but, having spent much of the last several days working on rfc5321bis, I don't understand that at all. First of all, at least in principle, absolutely nothing prevents Alice from creating alice-bob-only@xxxxxxxxxxx (or, preferably, something much more obscure) and then discarding or rejecting anything that does not come from Bob, using whatever authentication mechanism the two of them can work out. If there were one reasonable, network-wide authentication mechanism (which might or might not involve a key server), they would not need to negotiate. Second, I'm not sure what you mean by "OpenPGP over SMTP" but cannot think of anything that would prevent defining an SMTP extension that asserted that no message was welcome unless the content was in OpenPGP (signed, encrypted, or both). Alternately, it would be fairly easy to write an extension, probably cloning and modifying STARTTLS, that would use OpenPGP to hide most of the envelope or, indeed, use OpenPGP as an alternative to all elements of TLS except the tunnel itself. Some versions of the latter would have the same problem that using TLS with SMTP does, naming having to have keys scattered around and get the envelope (and maybe the message) at least partially into cleartext at each relay. But, unless one says "no relays", one has to be satisfied with either encrypting content (maybe including message headers) but not envelopes or having things in clear on the relay almost no matter what one does. > In my scheme, Alice can decide she is only going to accept > calls from @bob and @carol. She can put @stalker on a > blocklist that prevents him from retrieving her contact > assertion, posting messages, placing calls, etc. etc. For accepting calls and running blocklists all of that can be done with SMTP. Whether it can be done with SMTP as provided by a particular mail service provider is another question, but that just implies either finding a different provider or supplying the current provider enough incentive to offer it. As to blocking access to contact information and the like, as far as Internet mail is concerned in the absence of a directory service, that is more or less the default... and advertising mail address to a list like list one (on putting it in an RFC) are matters of choice with other choices available if one can maintain multiple addresses for different purposes (and that seems no different from having different callsigns). john
