On Mon, Dec 30, 2013 at 3:44 PM, Dave Crocker <[email protected]> wrote:
> On 12/30/2013 12:38 PM, Paul Lambert wrote: > >> Another approach, however, is to start from scratch and to define an >>> >entirely new email system, which uses cryptographic addresses instead of >>> >human-readable identifiers. I guess that's the approach you are >>> >suggesting. Is this correct? >>> >> Yes - we should start from scratch (versus direct >> augmentation of S/MIME/PKI or PGP). >> > > > Starting from scratch to build a new email system is not likely to > succeed, any more than the various, earlier efforts to do that succeeded, > back when the installed base was a few orders of magnitude smaller and > adoption of a new system relatively easier. > > And then there is the small matter of wondering how viable the human > factors of cryptographic email addresses will prove to be... Starting from scratch is not likely to succeed. Any new scheme has to support SMTP for legacy. But when I am looking at adding crypto to SMTP+JABBER+SIP etc and realize that 90% of the effort required is due to having to retrofit the security to a badly designed protocol, I think that it is quite likely easier to support secure JABBER etc. through a new protocol with crypto designed in from the start and that if the messaging protocol is done right it would be capable of being used as an SMTP replacement as well. The reason for replacing SMTP would be not so much to replace the protocol as to distinguish infrastructure that is designed with some sort of clue from the muck that festers out in SMTP land. There will always be some twit bleating on about how a change to the protocol is completely unacceptable because he might have to stop using his 30 year old mail server program. Mailing lists will never work well in SMTP because the protocol does not really support them properly and the extensions designed to add support are not supported in the clients. The only way to fix support properly is for control messages to follow the same path as outbound messages and the only way to make that change is to move to a new protocol. That can't be done in the current mail system but it is easy to do if there is a policy layer. Any mechanism that can be used to tell the sending mail client that S/MIME or PGP format mail is preferred can in principle be used to say that the mail should be sent over some JSON-B based REST scheme that provides a superset of SMTP and JABBER capabilities. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
