On Fri, Sep 12, 2014 at 2:35 PM, Dave Crocker <[email protected]> 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. _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
