Re: Why are mail servers not also key servers?

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

On Fri, Apr 21, 2017 at 12:28 PM, John C Klensin <[e-mail]> wrote:

> --On Friday, April 21, 2017 09:52 -0600 Doug Royer
> <[e-mail]> wrote:
>
> > On 04/21/2017 09:48 AM, John C Klensin wrote:
> >
> >>
> >> In addition, as others have pointed out, if you can't trust
> >> your email (server) provider, then expecting others to trust
> >> keys on the basis that they are obtained from that server may
> >> not make a lot of sense.
> >
> > You do not have to trust your or their email server. If you
> > trust the cert issuer. Then use the result.
> >
> > If you do not trust the cert issuer, then do not use the
> > results.
>
> Doug,
>
> Sorry... should have been more explicit (or just stayed out of
> this).  While I agree with you, given the current state of
> certification quality readily available to most of us and the
> process needed, in the general case, to verify a cert, I have a
> lot of trouble figuring out what this thread is about if getting
> the cert from the mail server doesn't add value.
>
​...

The big flaw I see in the current S/MIME PKI is that the WebPKI is only
really designed to support validation of organizations and there is no
comparable infrastructure for individuals. Nor is it possible to extend the
WebPKI approach usefully.

The total market for TLS certs is over $1 billion a year. The market for
S/MIME certs to be used across organizations is less than $10 million. Yes,
there is a market to support Intranet S/MIME but the internet market is
tiny.


One change I would like to see is to make enterprise level S/MIME certs the
norm. So instead of the CA issuing certificates for [e-mail], it
issues an example.com certificate that can then be combined with some other
credential issued by example.com that is specific to Alice.

We could use PKIX pathmath and issuer constraints for this of course. But
they are kinda screwed up by existing deployment.
​

​My problem with my code right now is that my original demo was designed to
deep integrate with Outlook Express which became Windows Essentials and is
now unavailable. The new Windows 10 mail client looks like it should be a
lot better and a lot easier to integrate to. However, the client only
became viable a few months ago, with the Anniversary update and the ​API
documentation is almost non existent.

What I need for my demo is the ability to

1) Read the mail client configuration to enumerate accounts and determine
the outbound mail server, etc, etc. for each

2) Create a mail account via an API.

3) Bind the S/MIME credentials.

At present, it seems like the last might need no more than just inserting
the correct cert into the correct cert store and watching it get picked up
automatically.

I would do this for Thunderbird only the code is really impenetrable and
the developers are planning to declare that code base EOL and move to a
scratch rewrite.


​For encryption, an outbound SUBMIT proxy running on the same machine as
the mail client is going to be essential in the short run as strong
addresses and policy driven opportunistic email encryption requires a plug
in approach and plug ins are disappearing from the infrastructure.