Re: [Endymail] Improvements to S/MIME

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

On Fri, Sep 12, 2014 at 2:35 PM, Dave Crocker <[e-mail]> wrote:
> On 9/12/2014 11:12 AM, Arnt Gulbrandsen wrote:
>> Just a question... I heard someone say at one IETF conference that
>> S/MIME is the only standard with more implementations than users. Why
>> has it suffered that fate? Surely not because of the two problems you
>> mention.
>
>
> Generic discussions about challenges in gaining use of end2end security
> at Internet scale seem to be applicable to S/Mime.
>
> They note:
>
>    1.  We don't have an existence proof for workable key management at
> scale.
>
>    2.  We don't have an existence proof for usability (UX, HCI, etc.) at
> Internet scale, which means workable for non-geeks who have no extra
> motivation.

For once I agree with Dave, sort of.

It is important to keep note of such issues. But solving them is not
very difficult. Making S/MIME cover the whole message is trivial: Just
extract the whole message including the content headers, encrypt it
and stick it in an attachment. Job done.

The only problem here then is knowing if the recipient supports this
S/MIME format. Which is one of the systemic problems that makes S/MIME
unusable: there is no negotiation mechanism and no way for the sender
to know what the receiver can accept. There are many pieces of data a
sender needs to know:

1) Should encryption be used in preference to plaintext?
2) Does the receiver support AES?
3) Does the receiver support PGP message format?
4) Does the receiver support S/MIME message format?
5) Versions, options on the above.


But what is critical is that if we do end up deploying one of the
proposals that solves these problems - and we already have a working
proof of concept, we have to make sure that the 'encrypt entire
message' issue is not forgotten.

But given that PGP has the same problem, I think this particular
feature could well be a point that gets the two camps to agree on
convergence. Because surely we can all agree that not encrypting the
subject line was a ridiculous limitation that makes the specs toybox
implementations.