On Tue, Dec 3, 2013 at 10:30 AM, Eliot Lear <lear@xxxxxxxxx> wrote:
--
On 12/3/13 12:46 PM, Phillip Hallam-Baker wrote:
And twenty years later the market still hasn't decided between S/MIME and PGP.
I agree with Jim that having two standards in this space has mattered not one bit. There are many reasons why email simply isn't encrypted. First, it's hard to get a key. Second, those who are in a position to simply dole them out don't as it provides no value to them. Third, there is no deployed directory infrastructure to find someone else's key. Forth, if there was one, it would result in defeating of common anti-spam/anti-malware tools.
All true.
But I think the reason neither camp has tried to address them is that they think the real problem is that the other is confusing the market.
Comodo and another CA actually do dole the keys out (or at least sign them) for free. But that isn't the real problem. The real problem is that it is a complete pain to register for the key even if that is free and it only lasts a year when you do. So for most people they spend fifteen minutes setting up encryption, use it once or twice and the next time they want to use it their certificate has expired.
There are a lot of problems here, but I think they can all be solved. In fact I think I have already solved them.
1) The keygen tool I have written generates keys and will in the future configure an email client to use them to decrypt mail.
2) Strong email addresses mean that it is easy to use the key since it combines the fingerprint for verifying the public key and the location at which to discover it. There is no need for any external infrastructure except for the ability to publish the public key and policy blob on a Web site.
3) The Web and .well-known is all we need for this.
If the strong email address is <fingerprint>?alice@xxxxxxxxxxx, then the public key blob can be found at http://example.com/.well-known/ni/<fingerprint>
4) Spam, shmam. it really isn't as much as a problem as you might think since we assume anyone who is going to send encrypted email is going to have the means to sign it. If we can sign the email we can use their reputation.
All that end to end encryption defeats is content analysis. Which is no real loss because spam filtering hasn't relied on content analysis for a very long time now.
<fingerprint> is the hash of a public key. It is best if this is a long term key that is used to sign use keys with finite lifespans. This would normally be an encryption keypair shared across all devices and a signature keypair per device. The long term master key can also sign a policy statement that specifies how the keys should be used. The policy can include statements like 'always send encrypted mail if you can' to 'send mail encrypted only after specific authorization'.
In the longer term I am expecting that we will establish an infrastructure for key distribution that combines CA issued trust with peer endorsement and has strong timestamping. With that infrastructure deployed I can have policy statements of the form 'encrypted email preferred but only send encrypted if you have a key older than at least a year.
Website: http://hallambaker.com/