Re: 0, 1, or many standards and their impact (or not)

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Dec 3, 2013 at 10:30 AM, Eliot Lear <[e-mail]> 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>?[e-mail], 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/