Subject: Re: [smime] S/MIME publishing mailing list

From: Peter Gutmann <[email-masked]>
Date: Sun, 25 Jan 2015 03:42:25 +0000

Paul Hoffman <[email-masked]> 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.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 26 Jan 2015 11:03:41 +0000

Russ Housley <[email-masked]> writes:

>It seems pretty easy to combine with RFC 4387:
>
>        Internet X.509 Public Key Infrastructure Operational Protocols:
>        Certificate Store Access via HTTP. P. Gutmann, Ed.. February 2006.
>
>Has RFC 4387 seen much implementation?

Not sure, since I don't get contacted when it's used :-).  I've seen use in
remote-monitoring (or monitored)/sensing devices (e.g. environmental sensors,
industrial site monitoring, gaming machines) to move certs around, they tend
to just use whatever bits and pieces work (a mix of SCEP, HTTP, and some
handwave at revocation checking via CRLs or OCSP, but often just replacing the
cert when it's deemed outdated).

Peter.