On Sat, Sep 7, 2013 at 11:00 AM, Stephen Farrell <[email protected]>wrote:
> > Fully agree with you. S/MIME as-is is not usable in the wild. > PGP is better, but I doubt its usable by an entire organisation > or set of home-users for most mail messages. > > Let's posit an end goal where a large proportion of email ends > up with ciphertext bodies at least, but typically without a high > level of assurance that the right public key was used. > As it happens I have been working on a draft on Prism-Proofing email for a couple of weeks now and was hoping to get an ID out with the idea of proposing a BOF or something to the Security AD. > My questions: > > 1) Would we like to get there? > I think we can do better than that. I have been looking at CT applying the concept (but not the exact spec) to email. But being able to send encrypted mail easily and being able to trust the keys are two separable concerns. Separating those concerns is what I was trying to do with XKMS but we never got it hooked into email clients and now the fashion is for JSON rather than XML (which I think is a good thing) > 2) If we would, should we start from a) S/MIME or b) PGP or > c) yet another mail-security clean slate? > Please lets not rehash the message format. S/MIME has won the encrypted mail message format and PKIX the key packaging format. I don't see any advantage to revisiting either. We can build any trust model we like with PKIX packaged public keys and the S/MIME packaging model isn't really a constraint. The real problems are in UI and in particular key distribution. The model is not automatic and it should be. I have pushed for using SRV records to make automated discovery possible but that is not really enough. Perry Metzeger has pointed out that any mechanism has to be deployable without administrator intervention (which I have a quibble on, I think the DNS domain administrator should be able to direct all queries to a lookup of their choice and block unauthorized sources). > 3) If we got as far as having IETF consensus on something > we think could do the above (i.e. we completed the RFCs > for (2)), do we think there's any real chance that that > could be deployed and end up widely used? > Well His Bruce-ship has made a call for action. Perhaps some of the people who hear it will write code. It would be really nice if there was at least one client (e.g. Thunderbird) that supported encrypted email native without any bolt ins. But even if we can't do that we can apply security by funneling the outbound traffic through a SUBMIT proxy that takes an email, sees if it can discover a key and if so encrypts. The reason I want to stick with S/MIME is that it means that I don't need to worry about the other half of the problem. I can free-ride on existing S/MIME clients for the decryption side of things. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
