My target audience, like Perry's is people who simply can't cope with anything 
more complex than an email address. For me secure mail has to look feel and 
smell exactly the same as current mail. The only difference being that sometime 
the secure mailer will say 'I can't contact that person securely right now 

I also agree that the devil is in the deployment. And that is why I think we 
need to separate concerns. We are not going to get anywhere if each and every 
one of us who has an idea has to implement an email client to make it work. And 
we certainly won't get any deployment if we have to deploy plug ins and other 
stuff for 50+ MUAs.

My experience of SET was that the scheme failed largely because it lacked 
agility. The first draft of the protocol was to burdensome to use. But we could 
not persuade banks who had paid $6 million to a vendor to deploy SETv1 to pay 
the same vendor another $6 million for the changes necessary to deploy a V2.

In the case of secure email there is an asymmetry. I think that deployed S/MIME 
has the problem of receiving and decrypting mail solved pretty well. The part 
that remains broken is establishing keys and sending the messages.

Which is why I think a critical step is to separate out the parts of the 
problem which can fixed for all proposals from the parts where innovation is 

I consider the following parts of the problem to be fixed:

1) Message formats: S/MIME

There is no intrinsic advantage to PGP or S/MIME format so choose one format 
according to which has the larger installed base. S/MIME wins. End of story. 
This does not mean committing to S/MIME PKI, or not supporting Web of Trust, 
but it does mean using CMS/PKCS#7 for message packaging.

2) MUA crypto User Interface: None

There must be no demand made of the user whatsoever. No button to press to send 
the message encrypted instead. The message is encrypted if the MUA can send it 
encrypted, end of story. 

The only UI that may be needed in the MUA would be to give the user feedback as 
to why something can't be sent.

As it happens, I have been working on a protocol to provide exactly this degree 
of separation. The idea being that the MUA makes a (secured) remote procedure 
call to a trusted service that tells it:

1) Whether the email should be sent encrypted
2) The crypto parameters (key, algorithm, etc,) to use if so
3) (optional) proof that allows the MUA to validate the action of the trusted 
service if the assertion of the trusted service is audit able and the MUA 
understands how to validate the assertion.

So here is how I would see it working, I have a scheme that combines elements 
of Certificate Transparency with a meta-notary scheme I have been working on. 
To implement this scheme I would write the necessary handlers for an omnibroker 
server to allow us to deploy the scheme and test it. If we find we need to 
tweak the scheme we tweak the omnibroker side of the scheme, the MUA side stays 
constant. If we think it is ready for prime time we can reduce the trust 
dependency on the broker by migrating some or all of the checking into the MUA.

In practice it is likely that we would have omnibrokers that support more than 
one scheme and in particular provide support for legacy schemes as well. If we 
have six schemes and three get some sort of traction then we are likely to want 
to combine ideas into a seventh rather than fight a VHS vs Betamax.

In my particular scheme the omnibroker is a permanent fixture as my approach is 
to attempt to mitigate the risks of using trusted third parties through 
separation of duties and multiple controls rather than eliminate them entirely. 
But I think that people will still find a value in using my scheme as a testbed 
even if they believe that the only acceptable approach is to eliminate the 
Trusted Third Parties entirely.

In practice the cost of crypto expertise is always going to exceed the cost of 
crypto products. I don't know what folk charge in the bargain basement for 
crypto clues but I rather doubt its less than my plumber. 

If someone can make a buck from a PRISM Proof email scheme then they will have 
a motive to facilitate deployment and spread it quicker. 
The cryptography mailing list

Reply via email to