On Fri, Apr 21, 2017 at 12:28 PM, John C Klensin <john-ietf@xxxxxxx> wrote:
--On Friday, April 21, 2017 09:52 -0600 Doug Royer
<douglasroyer@xxxxxxxxx> 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 Alice@xxxxxxxxxxx, 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.