Paul Hoffman <paul(_dot_)hoffman(_at_)vpnc(_dot_)org> writes:
The problem is getting the MUAs to care enough about S/MIME to add code that
would automatically respond to that message. MUA interest is zero, if not
negative.
Yup, and that's exactly the problem. Actually it's possible to go back a step
further and say that the MUA lack of interest is caused by user lack of
interest. Outlook has had... well I don't want to call it good but at least
OK [0] S/MIME support built into it for a decade or more, so there's encrypted
email available on every (Windows) desktop, but when was the last time you
heard someone say "I'd really like to send encrypted email but I can't because
certificates"? It's been posited that email encryption has reached pretty
close to all of the market segment that cares about it (which is, to pull a
figure from thin air, 0.05% of email users), so there's no point in doing any
more on it.
If you want encryption badly enough then you fight with some PGP
implementation until either something works or the pain gets too much and you
decide you don't need it that badly anyway. Alternatively, if you're
corporate you're ordered to use encryption and the IT staff come along and set
things up for you and you use S/MIME via Outlook. Once a year you call the
helpdesk when you get warnings about certificate expiry until someone comes
and makes things work again (or maybe you just quietly turn it off so your
email will work like it's supposed to).
Having said that, it wouldn't hurt to have an informational RFC to document
the convention of GETSMIME and GETPGP, so at least those MUAs who want to do
it have some common reference point to go from. It's such a simple thing to
implement (if you already have an MUA) that it seems a shame not to document
the capability.
Peter.
[0] In the sense that making email crypto usable is hard and there's no
evolutionary pressure (with associated budget) to make it less hard, so
MS have done a reasonable job given the environmental constraints.
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime