Subject: Why are mail servers not also key servers?

From: Jon <[email-masked]>
Date: Thu, 20 Apr 2017 15:20:05 +0200

Hi All,

I'm not sure if this is a topic which has already come up or not (I did
a simple search brought nothing up).

Anyway, the state of email security is still pretty poor despite much
low hanging fruit. PGP is great for those that use
it, but they are a small group. TLS seems to be the only wide spread
security implementation and I suspect that it has worked because it's
transparent to the end users. So, why hasn't key exchange been made to
be transparent? Why are (E)SMTP servers not also key servers? Have users
generate a key pair on registration, store those keys on the server (in
an encrypted archive), and make the public key available. A little
coding later and we've got key exchange and message confidentiality.

Some extra security can be had by giving mail servers their own keys
with which they can sign exchanges (and remember each other). TLS can be
used to as part of an initial key exchange if that is desired. Can
we not extend smtp again to include the necessary key exchange commands?
Is there any movement on this?

Jon

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Apr 2017 10:22:17 -0400 (EDT)

On Thu, 20 Apr 2017, Jon wrote:

> Why are (E)SMTP servers not also key servers?

You will find a history of that discussion in the dane archives.

Basically, it is the equivalent to the domain's DNS servers acting as
key servers, except that:

- SMTP is often blocked cross-domain, eg by ISPs, hotspot operators, etc
- SMTP failure cannot be distinguished from SMTP attacks, whereas DNSSEC
   based published keys (eg OPENPGPKEY and SMIMEA) can be detected when
   blocked (DNSSEC returns bogus or indeterminate results)
- Using public DNS to publish keys allows for a level of indirection,
   making targeted attacks much harder to do.

> coding later and we've got key exchange and message confidentiality.

SMTP servers could be key servers without having the private key of
individuals?

> we not extend smtp again to include the necessary key exchange commands?

I believe there was a draft that tried to do something like this.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Apr 2017 17:29:46 +0300

> Is there any movement on this?

Hi, Jon

I’m sure such things have been considered in the past, and for certain SMTP could be extended. I can think of a few complications right of the top of my head. There are undoubtedly others:

1. People use multiple MUAs. For this account I use this Mac MUA, a phone MUA, and occasionally the web-based MUA. I’d need to share the private key to receive encrypted mail on all three. Doing it in the browser is a hard problem.

2. There’s the administrative problem of tying the SMTP server to whatever server is serving the public keys. HTTPS from the same IP address? New special DNS SRV record somehow tied to the gmail.com <http://gmail.com/> MX record?

3. How much to you trust your email provider? Because they could trivially serve the wrong public key and intercept your traffic.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Apr 2017 17:36:03 +0300

> SMTP servers could be key servers without having the private key of

Sure. If they double as HTTPS servers.

I want to send you an email, so I type “[email-masked] <mailto:[email-masked]>” in the To: field, and my MUA goes to https://mail-public-keys.nohats.ca/.well-known/mail-pubkeys/paul <https://mail-public-keys.nohats.ca/.well-known/mail-pubkeys/paul> and that gets your public key.

And now my MUA can encrypt.  And it all works, as long as we trust nohats.ca <http://nohats.ca/> (and conversely gmail.com <http://gmail.com/>) and as long as you have a copy of your private key on every single MUA that you use.

Small assumptions, no?

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Apr 2017 11:08:20 -0400 (EDT)

> Sure. If they double as HTTPS servers.

I should drink coffee before posting... What I meant to say was the
model where the mail server generates and/or has a copy of the private
key seems dangerous. And I tried to say SMTP servers could be key
servers with only having public keys, not private keys. Still, using
(E)SMTP has all the problems I described earlier.

> I want to send you an email, so I type “[email-masked]” in the To: field, and my MUA goes to
> https://mail-public-keys.nohats.ca/.well-known/mail-pubkeys/paul and that gets your public key.

But any MUA can already get my key using RFC-7929 at sha256("paul")[1:28]._openpgpkey.nohats.ca

eg:

dig openpgpkey 0357513deb903a056e74a7e475247fc1ffe31d8be4c1d4a31f58dd47._openpgpkey.nohats.ca.

So using another HTTP(S) server that is not the SMTP server itself does
not seem to make much sense to me? An SMTP server relaying the
OPENPGPKEY or SMIMEA or other source of pubkey could be useful,
if we think DNS transport is bigger problem than ESMTP transport.
But I think it is harder for people to contact mx.nohats.ca on port
25 from a random ISP compared to use DNS against 8.8.8.8 on an ISP
network.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Apr 2017 15:23:42 +0000

> 25 from a random ISP compared to use DNS against 8.8.8.8 on an ISP

This was all covered in the discussion of draft-moore-email-addrquery.
(Perhaps on the UTA rather than DANE list? I don't recall)

My take at the time was (and remains) that queries for the recipient's
public key can be tunneled through the user's MSA, thereby avoiding
the issue of inability to reach port 25 from consumer end-device
IP space.  That discussion unfortunately appears to have worn-out
the draft author.  

I still think that draft is worth pursuing, if one is willing to
not set the bar too high.  The reason we have so little security
is sometimes (often?) because we're unwilling to accept less than
"perfect" security.  It is not unreasonable to trust the MSA to be
a trusted proxy for remote keys.  After all, in that model the same
MSA/MTA operator is trusted to vend your keys to others.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Apr 2017 11:19:05 -0500

> MSA/MTA operator is trusted to vend your keys to others.

+1

The link to DNSSEC could be this:

 - the client should learn via DNSSEC that the user's MSA supports this
   feature, 

and

 - the user's MSA should learn via DNSSEC that the target domain (and
   any MTAs on the way there) supports this feature.

Nico
--

---

From: Jon <[email-masked]>
Date: Thu, 20 Apr 2017 19:01:05 +0200

On 20/04/2017 16:29, Yoav Nir wrote:
>> *SNIP*
> I’m sure such things have been considered in the past, and for certain
> SMTP could be extended. I can think of a few complications right of the
> top of my head. There are undoubtedly others:
> 
> 1. People use multiple MUAs. For this account I use this Mac MUA, a
> phone MUA, and occasionally the web-based MUA. I’d need to share the
> private key to receive encrypted mail on all three. Doing it in the
> browser is a hard problem.
> 
This is why I think smtp should be extended. All your mail agents
support (E)SMTP and presumably they would all support an extension to
smtp. The private keys will need to be stored some how to allow for
multiple clients, but a key generated from user input could be used to
decrypt a stored copy of the private key.

> 2. There’s the administrative problem of tying the SMTP server to
> whatever server is serving the public keys. HTTPS from the same IP
> address? New special DNS SRV record somehow tied to the gmail.com
> <http://gmail.com> MX record?
> 
Indeed there is an administrative problem. I've done a project I call
CMTP that takes a very federated, hand off stance on this to keep
administration down.
https://github.com/darakian/cmtp
tl;dr servers have keys and sign transactions. The server key is simply
requested and is trusted on first use.

> 3. How much to you trust your email provider? Because they could
> trivially serve the wrong public key and intercept your traffic.
> 
I really dislike this argument. You, me, and many others already trust
our mail servers in the same capacity. Sure a mail server could serve
the wrong key and then my mail ends up in a nefarious villains hands,
but that is already the case today. If there's some degree of
confidentiality we at least have traffic interception as a possible case
rather than the default.

Jon

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Apr 2017 17:35:51 +0000

> decrypt a stored copy of the private key.

A major problems with all E2E email encryption proposals is unrelated
to key distribution, none of the extant MUAs provide an adequate
interface for E2E encrypted email.

      + Encrypted email is not searchable.

      + Encrypted email is difficult to scan for spam and malware

      + Changing the private key can mean loss of access to email
	encrypted under the old key.

      + Signatures stop verifying when the signature key expires,
	even though they were valid at the the email was received.

In addition, nobody is investing any effort into major improvements
in standalone MUAs.  Free webmail has gotten rather fancy, but
content security is not in the provider's interest.  Will users
want to pay for security that reduces usability?

Therefore, for the foreseable future, hop-by-hop TLS is the best
security you're likely to get, and is most appropriate for the
vast majority of email.

It is not enough to invest effort in better key distribution,
the effort will be wasted unless the right incentives are in
place to induce a similar effort in usability of E2E encrypted
email after it arrives.

> confidentiality we at least have traffic interception as a possible case

TLS is quite sufficient to guard against passive monitoring, and
the final message stored unencrypted in the user's mailbox is much
more usable.

Make (stored) E2E email usable, and then there'll may be real
incentives to address key distribution.  Otherwise, any effort
to address key distribution will be largely wasted.

Do you have a design for an efficiently searchable and yet secure,
encrypted content index that supports concurrent updates from
multiple clients without losing data integrity?

How do you propose to handle spam and malware?

-- 
	Viktor.

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Apr 2017 11:48:04 -0600

On 04/20/2017 11:01 AM, Jon wrote:
> (lots snip)

You seem to be describing a configuration server.  (I forget the RFC#, I 
think it was a Chris Newman one). A configuration server could store a 
BLOB of data that could be decrypted by a client that had the key.

I would like to see an extension so that the MUA could contact the 
destination server (perhaps their MX record host) and get a users PUBLIC 
key. Perhaps (just an idea - no screaming please) a new TXT record type 
that points to the domains PubKey server.

I think it is undisputed that the MX server would know which email 
recipients are valid for itself. Or if a proxy SMTP server, could relay 
the request to the real hidden SMTP server.

As someone else pointed out, draft-moore-email-addrquery is a great start.

-- 

Doug Royer - (http://DougRoyer.US  http://goo.gl/yrxJTu )
[email-masked]
714-989-6135

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Apr 2017 11:56:08 -0600

>        + Encrypted email is not searchable.

Sure it is, by the recipient MUA, else the user could not read their 
email. It would not be searchable by a 3rd party - which is the point of 
encryption.

>        + Encrypted email is difficult to scan for spam and malware

The scan would have to take place in the MUA. Firewall scanners would 
fail, as they do now with S/MIME or encrypted PGP.

> 	encrypted under the old key.

Only if you throw away old keys. Doctor, Doctor, it hurts when I do 
this. - So Do not do that :-)

> 	even though they were valid at the the email was received.

Again, do not throw away the old keys. An MUA should not allow a user to 
throw away any key needed for any message still in the store. Yep - complex.

> ....

--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Apr 2017 14:53:27 -0400

> Sure it is, by the recipient MUA, else the user could not read their email.
> It would not be searchable by a 3rd party - which is the point of encryption.

Which MUAs index content of encrypted messages?  How does this work for clients
that store only a cache of recent messages, or webmail?

> The scan would have to take place in the MUA. Firewall scanners would fail,
> as they do now with S/MIME or encrypted PGP.

Endpoint scans are often not nearly as effective.

> Only if you throw away old keys. Doctor, Doctor, it hurts when I do this.
> - So Do not do that :-)

The mocking tone is entirely out of place.  Not all MUAs support multiple recipient
keys.

> Again, do not throw away the old keys. An MUA should not allow a user to throw away
> any key needed for any message still in the store. Yep - complex.

Should not is not the same as do not.  My point is and remains that E2E encryption
of email is not usable with today's MUAs, progress on some of the issues is both
difficult and unlikely.

-- 
	Viktor.

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Apr 2017 13:10:38 -0600

>> Sure it is, by the recipient MUA, else the user could not read their 
email.
 > that store only a cache of recent messages, or webmail?

That is an implementation detail. If the MUA wants to see the message, 
it can, if it can't, its not an MUA.

Storing the message in a cache is orthogonal to if it is encrypted. I 
can cache the encrypted message, cache it after its decrypted, or not 
cache it at all.

Webmail does not work with encrypted email. Never will until you give 
your private key to some unknown email-web-server implementation and 
that systems unknown administrator. Not something the IETF should be 
recommending.

 > Endpoint scans are often not nearly as effective.

No change to the current operation of encrypted email. The entire point 
of encrypted email is so that no one (including the server) can see the 
contents of encrypted email.

If your ISP holds your private key, then you have no privacy in your email.

 >> Only if you throw away old keys. Doctor, Doctor, it hurts when I do 
this.
 > The mocking tone is entirely out of place.  Not all MUAs support 
multiple recipient

That is an implementation detail, not a protocol detail. If you want to 
see old email, don't throw away the key to that email.

 > of email is not usable with today's MUAs, progress on some of the 
issues is both

I use E2E almost every day. Works fine. Update the MUA your using. If 
you do not want to update your MUA, then, your making the decision for 
things to not work. Its not a protocol issue.

A Web-clients MUA have a problem, because you would have to store the 
private key in the email-web-server. I would not do that, so I will not 
use an MUA that allows my private key to be given to another server, 
managed by some unknown person. They have that problem now - no change.
Not fixable, unless you give away your private key. And again, not 
something the IETF should be recommending.

--

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Apr 2017 14:26:05 -0500

On Thu, Apr 20, 2017 at 01:10:38PM -0600, Doug Royer wrote:
> That is an implementation detail. If the MUA wants to see the message, it
> can, if it can't, its not an MUA.

Sure.

> Storing the message in a cache is orthogonal to if it is encrypted. I can
> cache the encrypted message, cache it after its decrypted, or not cache it
> at all.

If you want to use IMAP and leave the mail on a server (which does not
have your private keys thus can't decrypt the e-mails) then the server
can't index your email.  Your client could build and keep an index
(presumably stored encrypted) to search email with.

No MUA does that.  Maybe they should, and it'd be nice.  But since they
don't, E2E encrypted email is just too difficult to use.

Now, indexing encrypted email on the MUA side is clearly an
implementation detail, but it is a detail which (along with many other
UI details) is critical to adoption.

Part of the problem is that there is very little work being done on
MUAs.  We can tell people what to do, but they're not doing it, so we're
stuck.

> I use E2E almost every day. Works fine. Update the MUA your using. If you do
> not want to update your MUA, then, your making the decision for things to
> not work. Its not a protocol issue.

And what MUA is that?

> private key in the email-web-server. I would not do that, so I will not use
> an MUA that allows my private key to be given to another server, managed by
> some unknown person. They have that problem now - no change.
> Not fixable, unless you give away your private key. And again, not something
> the IETF should be recommending.

I'm not so sure.  A client could use JS crypto APIs to locally decrypt
(and hopefully not send the cleartext back to the server! but you have
to trust the MUA software...), and it could even build an index in local
storage.

But still, without anyone actually implementing such a thing...

Nico
--

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 21 Apr 2017 05:50:47 +1000

On 21 Apr. 2017 3:57 am, "Doug Royer" <[email-masked]> wrote:

>         encrypted under the old key.

Only if you throw away old keys. Doctor, Doctor, it hurts when I do this. -
So Do not do that :-)

... And re-import every old key when you switch to a new MUA. Sounds like
fun to enforce.

Cheers
-- 
Matthew Kerwin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Apr 2017 16:10:59 -0400

Sharon Boyen and I wrote this up as an RFC a while back:

https://tools.ietf.org/html/rfc4386

The weakness as I see it is that it still lacks the data necessary to make
the decision whether to use the key or not. In particular:

[email-masked] sends a message to [email-masked]

Forget the issue of trust for a moment, the infrastructure should deliver
all the information that Alice's email client needs:

* Is encryption refused, optional or required?
* Which encryption protocols are supported (OpenPGP, S/MIME)?
* Which key(s) should be used?

Note that this is only the raw information, a client would also have to
decide whether the information was trustworthy or not. Though if the email
would be sent en-clair otherwise, that does not matter much.

For ubiquitous use of message level encryption, it is essential to take
into account the fact that spam and malware filtering is actually a bigger
concern than confidentiality:

END TO END ENCRYPTION IS NOT A PRIVILEGE I WILL EXTEND TO ANONYMOUS SENDERS

So encrypted mail is going to have to be signed by an authorized sender for
end to end encryption to be permitted. Everything else goes through the
filters as usual.

I am working on code right now: Prismproof.org

On Thu, Apr 20, 2017 at 10:36 AM, Yoav Nir <[email-masked]> wrote:

> I want to send you an email, so I type “[email-masked]” in the To: field,
> and my MUA goes to https://mail-public-keys.nohats.ca/.well-known/mail-
> pubkeys/paul and that gets your public key.
>
> And now my MUA can encrypt.  And it all works, as long as we trust
> nohats.ca (and conversely gmail.com) and as long as you have a copy of
> your private key on every single MUA that you use.
>
> Small assumptions, no?
>
> Yoav
>
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Apr 2017 16:11:26 -0400 (EDT)

On Thu, 20 Apr 2017, Nico Williams wrote:

> MUAs.

I think there is just no work to be done. Decrypt the email on the MUA
and store/use it as any uncrypted email now and run the OS or at least
the user's directory using a disk encryption system.

Paul

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2017 20:54:34 -0000

>Sure. If they double as HTTPS servers.

As others have noted, this topic has come up more than a few times before.

Here's a recent draft we wrote for a simple per domain https key
server, based almost entirely on existing standards.  It distributes
public keys.  Managing your private keys on all of your MUAs remains
as intractable a problem as it's always been.

https://datatracker.ietf.org/doc/draft-bhjl-x509-srv/

R's,
John

---

From: Rui Costa <[email-masked]>
Date: Thu, 20 Apr 2017 23:37:24 +0100

Although having read some of the DANE discussions that took place ~1 year ago, being PGP illiterate, a little less about SMTP, certificates, ... i don't understand this:	

Cryptography (at least "in the beginning") was created for E2E communication, independently of your network's layers or the hops/people it goes through.	
PK allowed something Caeser (or Dönitz, or other Enigma's users, or...) hadn't: the ability to avoid the 2 E2Es having to meet in order to set new keys.	

I guess (maybe wrongly) certificates handle something the internet brought, formerly inexistent: the answer to "is this person that sent me her/his public key REALLY the person she/he says to be, with whom i want to talk to?" In other words, some means of trust/signature, once "we can't see" with whom we speak/write.	

So, can someone point me to some URL/documentation/https://mailarchive.ietf.org/arch/msg/ietf/xyz explaining the point on having keys/cryptography somewhere in between these 2 end points? (And thus i guess i'm saying i don't understand cryptography's point on scenarios other than what i think people have called on these threads "E2E".)	

Some time ago a friend of mine told me her company changed the old firewall/proxy into zscaler. When the browser presented her new certificates asking her trust, she asked network support why didn't they explain people the implications: often on lunch breaks people use the network for private purposes like going to the bank, f.i. Network support pointed her to corporation network support which said it was that corporation's company own decision. She asked her director, that told her "we'll talk about it in the afternoon", an afternoon ~2 years ago. This makes me wonder whether people that have to take these decisions understand the implications.	

Most people think "https" means they're talking directly to the other end via a secure channel, know nothing about "man in the middle" or similar concepts. Why give them false confidence on scenarios other than E2E?	

King Regards,	
Rui

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Apr 2017 19:40:59 -0400 (EDT)

> So, can someone point me to some URL/documentation/https://mailarchive.ietf.org/arch/msg/ietf/xyz explaining the point on having keys/cryptography somewhere in between these 2 end points? (And thus…

I want to send you an encrypted email. I need your key. I can send a
plaintext email asking you for the key. I have to hope that it really
reached you and that it is you who gave me the key and that the key
was not modified in transport.

versus:

You publish your key somewhere with a verifiable link of key to your
email address. Now your first contact with me will be encrypted and
secured.

People have different ideas of what minimums and maximums to use
for "verifiable link of key to email" (or even key to human)

Paul

---

From: Rui Costa <[email-masked]>
Date: Fri, 21 Apr 2017 01:26:10 +0100

Thanks Paul. We're considering untrustable email/DNS/... servers. OK.	

This particular email hasn't any jurisprudence value. However, it could have the same value as a registered letter, couldn't it? (Can't layers' emails?) I suppose the difference is some digital signature, which i guess will mean some certificate issued by some trusted entity. (Which means, at least once, the 2 ends can't avoid "having to meet" (not to set new keys but) to know each other's signature. (I actually don't know which entity grants them.))	

Why doesn't that solve the doubt about "who gave [...] the key"? And again, what have the networks in between to do with it?	

In traditional mail, the only thing one needs is the delivery registry and signatures. (Perhaps wrongly, i'm extrapolating Portuguese law to other countries'.) From that, you're sure you're writing who you want to write to. If on top of that you want, both of you can exchange keys and encrypt. However, that's inside the envelope. The mail service doesn't really care or know what's in there and wouldn't understand the message if the envelope was violated. Its role is simply...	
-transport	
-providing you the proof you sent the letter	
-providing you the proof the other end sent you the receipt (with its own signature)	

(But i fear you'll point out why this won't work with email, if you carry on the babysitting :-) Kind Regards	

-----Original Message-----
From: Paul Wouters [mailto:[email-masked]] 
Sent: 21 de abril de 2017 00:41
To: Rui Costa
Cc: [email-masked]
Subject: RE: Why are mail servers not also key servers?

On Thu, 20 Apr 2017, Rui Costa wrote:

> So, can someone point me to some 
> URL/documentation/https://mailarchive.ietf.org/arch/msg/ietf/xyz 
> explaining the point on having keys/cryptography somewhere in between 
> these 2 end points? (And thus i guess i'm saying i don't understand 
> cryptography's point on scenarios other than what i think people have 
> called on these threads "E2E".)

I want to send you an encrypted email. I need your key. I can send a plaintext email asking you for the key. I have to hope that it really reached you and that it is you who gave me the key and that the key was not modified in transport.

versus:

You publish your key somewhere with a verifiable link of key to your email address. Now your first contact with me will be encrypted and secured.

People have different ideas of what minimums and maximums to use for "verifiable link of key to email" (or even key to human)

Paul

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: 20 de abril de 2017 23:37
To: [email-masked]
Subject: RE: Why are mail servers not also key servers?

King Regards,	
Rui

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2017 02:11:56 -0000

In article <[email-masked]> you write:
>This particular email hasn't any jurisprudence value. However, it could have the same value as a registered letter, couldn't it?

Postal mail isn't a very good analogy here.  Registered postal mail
depends on a trusted third party, the government post office, to make
assertions about the mail it handles.  It typically provides two
services.  One is reliable delivery of valuable physical objects like
jewelry which doesn't apply to e-mail.  The other is to prove that one
party sent a message to a second, even if the second party doesn't
want it and won't sign for it.  (The usual example is a letter from
your insurance company saying they've canceled your policy.)  In the
US they're separate services Registered and Certified mail, elsewhere
they're usually combined.

E-mail crypto doesn't do either of those things.  A digital signature
says that this message really came from whoever, with the physical
analogy being a notary stamp.  Encrypted e-mail doesn't promise that
the mail will be delivered, but makes a negative promise that it will
not be delivered to (or at least read by) anyone but the person with
the key.

If a recipient is cooperative, and sends you back a message signed
with the same key to which you encrypted the message, that tells you
he got it, but that's not a very interesting case.

In the real world we have centuries of law and practice that tell
notaries how to verify someone's identity, and tell recipients what
the value of a notary stamp is.  In e-mail, we have the web of trust
for PGP and for S/MIME third party CAs (or DANE domain assertions)
none of which map very well into the way we manage identities in the
normal world.

R's,
John

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Apr 2017 21:35:33 -0600

> was not modified in transport.

You send me a signed email from a mutually trusted source. I now have 
your public key, because you can extract it from the signed S/MIME 
email. (I am guessing you can do this with PGP.)

I can now send you an encrypted email, and it includes my public key, so 
you can decrypt it.

There are free email cert companies. This email is signed by one (unless 
the list server strips them out like it used to). Your MUA now knows my 
public key.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 Apr 2017 22:03:49 -0600

This is how it is done. I know it works with Thunderbird and Outlook.

To send a signed email, I only had to configure my MUA once. Thunderbird 
and Outlook always S/MIME signs all of my email with the free cert I use.

You send me a signed (not encrypted) email from a *mutually trusted* 
cert source. Your MUA signed it with your private key, because that's 
how its done. Only your public key can verify it.

My MUA examines the email, extracts your public key that is included in 
an S/MIME signed email, verifies it was signed by the mutually trusted 
cert source. I now know the 'From' email address matches the signature, 
the content, and the only way your MUA could have generated those 
sequence of bits, is that it was signed by your matching private key.

I now have your public key. Verified by a email message signature that 
could have only been signed by the matching private key, which validate 
against the trusted cert source. Who cares if the world sees your public 
key - that the point of a public key.

If someone were to modify the message in transit (only some of the 
headers are used in the signature verification), the signature will fail 
to validate. Then my MUA would tag it as bad signature and should be 
un-trusted.

Thunderbird signifies a good signature with an image of a letter, with a 
red seal.

When my MUA validates that the signature matches the email content, then 
the recipient MUA knows nothing was altered, including the public key, 
which it keeps.

Thunderbird and Outlook collect these certs by default. I do not have to 
do anything. I can even export them to a file, and import them into 
another MUA.

I can now send you an encrypted email, encrypted with my private key and 
your public key. Only your MUA can open it with your private key and my 
public key, and in that process, also validates it.

--

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Apr 2017 14:52:37 +1000

> he got it, but that's not a very interesting case.

It's also abuse of the cryptographic primitives, I hope that this
isn't really how it works and you are eliding certain key details.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Apr 2017 14:06:16 +0200

>email. (I am guessing you can do this with PGP.)

Just replying to a random part of the discussion.

Is there any kind of description and any kind of agreement of what attacks
secure mail is supposed to defend against?

Without a clear statement of what it is supposed to do, it is not possible
to figure out whether a proposal actually meets that goal. And without a
clear goal it is also not possible to figure out if the system is going to 
useful or not.

People have wildly different ideas of what e-mail security means. 

In the context of this discussion, one thing I'm curious about, and something
that should be clear from the description of the attack vectors, is who
controls a key.

To put it in terms of TLS certificates, is an e-mail key 'DV' or 'EV'?

It is easy to come up with lots of ways in which a domain holder can provide
a public key for a mailbox at that domain. But is that what we want?
In some cases, like corporate mailboxes, probably yes. In other cases,
journalists or activists with an e-mail account at a big e-mail provider,
probably not.

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 21 Apr 2017 09:35:35 -0400

On Thu, Apr 20, 2017 at 11:48:04AM -0600, Doug Royer wrote:
> key. Perhaps (just an idea - no screaming please) a new TXT record type that
> points to the domains PubKey server.

How's this going to work when the MUA is:

	- running on a host that's not connected to the 'net
	- running on a host that can't connect to MX's (because
		of local firewall rules)
	- running on a host that can't connect to MX's (because
		they're unreachable or down)
	- running on a host that can't connect to MX's (because
		they no longer exist)
	- running on a host that can connect to the MX's but can't
		get the user's public key because the user is no
		longer valid
	- and so on

There are way too many failure modes here that will render messages that
have already been received either temporarily or permanently unreadable.

---rsk

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Apr 2017 07:53:11 -0600

> have already been received either temporarily or permanently unreadable.

Currently, if you need to send an encrypted email to someone, and you 
can not get their public key - same results. No change. It does not 
break anything that is not already broken.

You only need their public key when you want to send them encrypted 
email first, If your happy with first a signed one, then encrypted one, 
then you do not need to look one up.

Automated email might have a hard time performing the signed email 
exchange first, followed by the encrypted email. Humans could do it 
manually and only be slightly annoyed at the extra step.

No matter what kind of public key lookup service is designed, if you can 
not reach it, it is not going to work.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Apr 2017 07:59:35 -0600

> secure mail is supposed to defend against?

I am not a security expert, I did however buy a couple of them lunch at 
an IETF meeting years ago and I am sure that the experts will correct 
any misstatements I have made here. S/MIME has been working for years.

> clear goal it is also not possible to figure out if the system is going to

To be clear, this is not a goal or proposal. This is how S/MIME works 
now. This is how it was designed to work.

> that should be clear from the description of the attack vectors, is who

You should be in control of your private keys. You private key is as 
secure as you make it. The average non-technical user will just send 
email, get email, and might make sure that the signed, or encrypted 
email checkbox is checked in their MUA.

> journalists or activists with an e-mail account at a big e-mail provider,

The only reason you need to fetch a persons private key first, is so 
that you do not have to exchange the signed and not encrypted key first.

And I would imagine that a journalist and activists would most 
definitely want people to send them encrypted email.

--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 10:24:09 -0400

The problem I keep seeing is that whenever we start talking about problem
X, people immediately start throwing in problem Y, Z... Often prefixed with
the words, 'but you obviously haven't thought about...'

I have identified at least a dozen problems with mail security, all of
which need to be fixed in order to deploy something better. And I think I
have a pretty good solution to all of them. I am not saying I have the best
solution or a perfect solution but I have *A* solution.

Tweaking the SMTP mail infrastructure doesn't help because the sending and
receiving device do not interact with either server directly under the
current model. SMTP email has grown to meet a lot of important requirements
in ways that make repurposing SMTP mail servers a non starter.

Talking about 'end to end' is also unhelpful because the only ends that
matter are the sender and receiver brains and you are not going to have
true end-to-end in out lifetime. The last and the first meter is always
going to be a weak link. As I showed in another post, there are good
reasons to only accept encrypted messages end-to-end after the sender has
been deemed trustworthy.

Also, Dave Crocker will soon chime in to point out the deployment problem.
And he is completely right. You are not going to replace SMTP with a new
email system. The only way that a system as pervasive as SMTP has ever been
replaced is by a new system that offers a superset of its functions.

I watched Tim B-L very carefully at CERN and I think I learned how the
deployment strategy of the Web worked. The key was to find one feature that
the Web offered to a distinct community that nothing else provided. In this
case the feature was to allow people to read the CERN phone book without
using CERN-VM, a mainframe whose operating system was the most unpleasant
in history.

So the first step towards sanity is to talk about data level security, not
just message. Right now, there is no standards based approach to encrypting
business documents, Word, Excel, program code, etc. in ways that support
business processes. Yes, you can buy and configure a Microsoft CRM system
but it only works for Microsoft products and not even the CIA and NSA
bother with it, hence Snowden, Manning and the two as yet unknown GRU moles
in NSA and CIA who supplied the Shadowbroker and Vault7 data.

The principle obstacle to deployment of such a system has been a set of
patents on the core technology. Patents which expire this year.

A secondary obstacle has been the insistence on perfect security so that if
Alice sends a document to Bob, Bob can only use it for purposes Bob
approves of. That might sound good till you realize it makes the document
next to useless to Bob. He can't edit, can't steal slides from a Powerpoint
Deck, he can't even show it without permission. Oh and he can only use
particular hardware configurations.

The biggest pratfall for traditional CRM schemes is that most of the most
important documents in any corporation have to be sent outside the company.
We are required to open our accounts to our auditors, we are required to
share trade secrets with our external counsel to apply for patents and of
course we have to share price information with customers to make a sale.

So what I suggest we do is that we start a Working Group to develop a
Confidential Document Control protocol, that is CRM minus the secure
hardware requirement.

Proxy Re-Encryption provides the technical capabilities we need to meet the
requirements of CDC. We would of course need to also solve the key
distribution problem. I have running code which addresses both.

Note however that once you solve the key distribution problem for CDC, you
can apply that solution to SSH, Web password management, second factor
authentication/confirmation and yes, messaging.

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2017 14:31:12 -0000

>isn't really how it works and you are eliding certain key details.

It doesn't use the same session key, it uses the same public key.  It's
not obvious to me why that would be wrong.

R's,
John

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Apr 2017 16:46:22 +0200

>any misstatements I have made here. S/MIME has been working for years.

At a technical level, yes. S/MIME does stuff. Whether it does the right thing?
Who knows.

>email checkbox is checked in their MUA.

By and large, private keys are the boring part. Yes, private keys will leak
every now and then. But overall that's not a big issue.

The big issue is how do you make sure that a public key actually belongs to
the party you want to communicate with and is not a key inserted by an
attacker.

It is easy to say 'trusted third party' without actually defining what such
a third party will look like. That gives the mess that is the current CA
system.

It is also easy to say, just use DNSSEC. Disregarding the trust issues
with that model.

>that you do not have to exchange the signed and not encrypted key first.

You never 'fetch' a private key. 

>definitely want people to send them encrypted email.

Only if governments or other large parties cannot mount a man in the middle
attack. Which they can, if they can control the distribution of public keys.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 11:29:05 -0400

On the trust issue, one of the problems I have identified with existing
message level security schemes is the lack of an infrastructure to
adequately manage user private keys. This is in part a result of the
constraints of 1990s technology which took seconds to perform RSA
operations. Today, those constraints are no longer relevant.

If we are going to have a useful discussion about Trust, we have to talk
metrics. Otherwise we end up with handwavy arguments like'nobody can trust
a CA'. Oh really, you think that email about Johnny making the school choir
that you currently send en-clair can't be trusted to CA issued trust?

When I worked on the design of what is now the WebPKI in the early 1990s at
CERN, I used a Work Factor analysis that is denominated in dollars. In the
wake of BlockChain, I realized that the model had to be extended to take
account of time because the wonderful thing about BlockChain and any
Lamport hash chain is that the Work Factor of an attack goes to essentially
infinity as soon as a data item is enrolled.

https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/

The big problem with private keys is that people have multiple devices and
they HAVE to be able to read email on more than one. Which means that
either you have to re-engineer the mail crypto to use proxy re-encryption
or you have to be able to move private keys about. I am currently
completing the code for the second approach.

My scheme in a nutshell is to establish a personal PKI for each user and
give them the tools to manage it transparently. OpenPGP offers something
similar but it isn't designed to allow a user to keep a personal
fingerprint for their whole life. Mine is and making that possible requires
the same offline/intermediate/online approach we use to manage WebPKI keys.
Each key in my scheme has a very narrow purpose. That means more public key
operations but greatly simplifies the code.

So let us say that the fingerprint for Alice's personal Mesh
is MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.

We can use this to create a strong DNS address so:

example.com.mm--MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

which allows us to construct a strong email address:

[email-masked]

mm-- is a DNS label prefix following the practice established for 118N
domains. It is the top level because it is the root of this particular
naming scheme and we do not want anyone to be able to resolve this name
unless they understand the mm-- prefix.

Try to send a mail with that address using a regular email client and it
will fail. Which is exactly what I want. This allows me to support the use
case 'only send if it can be encrypted'.

In this case, the fingerprint is of a personal signing key which signs
Alice's Mesh profile which in turn signs Alice's Mail profile which
describes how to send email to Alice. So if a mail is sent to that address,
following the specified profile, it has been sent securely (for Alice's
definition of secure). There is no opportunity for a third party to
compromise the communication. You are not relying on any CA or TTP for
trust.

What you probably will end up doing if you are an Enterprise customer is
paying some party some money to run the infrastructure that
maps MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ to the necessary resources and also
helps you address the first contact and promiscuous encryption use cases.

There is a business model for existing CAs here but the services are rather
more than signing a certificate.

The concept of strong addresses can be applied to any IETF protocol and is
wonderfully back compatible because every strong DNS address is a valid DNS
address but one that has no chance of accidentally being confused with an
ICANN issued address. It would take an act of intentional malice for
confusion to arise.

So how to apply these to the use case raised by John Levine?

We could configure a mail client to add a header that includes strong email
address as a header:

From: [email-masked]
Strong-Address: [email-masked]

This gives us Trust After First Use (TAFU) which is a great way to build a
Web of Trust. It does work for SSH. It is fine for interpersonal messages.

If you combine Web of Trust and Trusted Third Party models, you can achieve
a higher work factor than is possible with either alone.

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Apr 2017 09:39:23 -0600

On 04/21/2017 08:24 AM, Phillip Hallam-Baker wrote:
> ...
> 
> Tweaking the SMTP mail infrastructure doesn't help because the sending 
> and receiving device do not interact with either server directly under 
> the current model. SMTP email has grown to meet a lot of important 
> requirements in ways that make repurposing SMTP mail servers a non starter.
> 

They do not, does not mean they can not. So, maybe SMTP server is not 
the correct place. But MX host might be, with a public key server on a 
different port. Because the MX host is currently the authority for an 
email addresses validity checking (well it bounces it if its not valid - 
but it knows if its valid).

Is it repurposing? Is this really different?

   RCPT TO user@domain
   250 OK
   550 No such user here

   PEMCERT user@domain
   250 OK ...PEM-encoded-cert..
   550 No such user here

   PGPCERT user@domain
   250 OK ...PGP-encoded-cert..
   550 No such user here

Thoughts below on this. And I am thinking of how the code would be 
written ...

I was leaning towards the SMTP/MX server because its currently the only 
place of authority where you can find out if user@host is valid. If you 
send a RCPT TO and it says, NO, then your done.

I have no problem with another solution. I just think you would have to 
replicate the email address validity check problem as part of that other 
implementation. 'User' is not always the same as email address. So any 
new service would have to know about email proxy rewrite rules 
(Doug.Royer@gateway -> dougr@his-site-server),  mailing/distribution 
lists, ... and the mess goes on.

I am not saying a public key server would need to understand those 
rules. I am saying that Doug.Royer@gateway would be the public key you 
might need. I am saying a public key server would need to parallel the 
knowledge of what the SMTP server already knows is a valid email address 
for its site. Currently Doug.Royer@gateway is in some file/database as 
valid in a way that is currently unique the SMTP server implementation.

And, who is the local authority for the public cert of 
Doug.Royer@gateway? The SMTP server already knows it goes to 
dougr@his-site-server.

So, maybe the SMTP server is not the place. I think it would make for a 
simpler implementation. Or maybe an entirely news service, that the SMTP 
server would use, to make sure they are in sync.

It seems to me that a completely new approach is not going to be adopted 
as quickly as extending SMTP.

Or I could see the SMTP server implementation also opening up a new 
public key service port that is only used for fetching public keys. And 
that port could use a non-SMTP protocol. However the MX host is the 
authority.

Lets not make two authorities.

--

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Apr 2017 11:48:10 -0400

--On Friday, April 21, 2017 09:35 -0400 Rich Kulawiec
<[email-masked]> wrote:

>> I would like to see an extension so that the MUA could
>> contact the destination server (perhaps their MX record host)
>> and get a users PUBLIC key. Perhaps (just an idea - no
>> screaming please) a new TXT record type that points to the
>> domains PubKey server.
> 
> There are way too many failure modes here that will render
> messages that have already been received either temporarily or
> permanently unreadable.

An idea was kicked around some years ago (can't remember if
there was ever an I-D) to create an SMTP extensions that would
work more or less like VRFY to return either the public key of
the server, that of a user associated with an address, or both.
IIR it never got any traction, partially because of the issues
Rich identified about and partially because of the issues others
have mentioned about being sure one reaches the right server
and/or can trust the keys received.

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.

   john

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Apr 2017 09:52:13 -0600

> the basis that they are obtained from that server may not make a

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.

--

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Apr 2017 12:28:42 -0400

--On Friday, April 21, 2017 09:52 -0600 Doug Royer
<[email-masked]> 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.
> 

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.

There are, as Rich points out, too many cases (perhaps a large
number every year) where a direct connection cannot be made from
the MUA to the remote server (final delivery MTA or something
verifiably under its control).  For almost any case involving
relaying rather than that sort of direct connection (and some
that don't), cert requests risk being used to propel a DoS or
blowback attack unless the server can verify the identity of the
MUA or at least the submission server, creating a chicken and
egg problem at best. 

The one advantage the (final delivery) mail server has is that
is is able to know --and, in general, is the only system that
knows -- which email addresses in its systems are aliases for
which other one, including such things as whether case-folding
works (and, for non-ASCII local parts, what it even means).
However, some of the discussions now going on in LAMPS
notwithstanding, the certificate issuer generally doesn't have
access to that information so the cert one gets back may not
match the address you asked about closely enough that, in the
general case, you can make a competent decision as to whether or
not to trust it.

Each one of those complications, including any returned
certificates that can't be trusted without further verification
(that might be all of them), makes the value proposition for
fixing a mail server to return certificate over something
mail-related less attractive... and the answer to the original
question in the subject line closer to "why bother?".   And, if
the plan is to connect to that server over something other than
email protocols, then it seems to me there is relatively little
advantage of trying to tie the discovery and retrieval
mechanisms to the email infrastructure rather than treating its
as a service we already know how to find with the DNS (even
though that doesn't solve all of the problems.  So that answer
is, again, "why bother?" except for a very selected set of cases.

Back to trying to get useful work done.

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 12:56:27 -0400

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

---

From: Wei Chuang <[email-masked]>
Date: Fri, 21 Apr 2017 10:00:22 -0700

I just wanted to second the draft-bhjl-x509-srv approach as preferable as
opposed to a new SMTP extension.  That draft calls for transport of the
certificate request and response to be over HTTPS.  As HTTPS is based on
Web PKI and generally has more up-to-date crypto (due to the ecosystem)
that traffic will stay private.  SMTP uses STARTTLS which has stripping
problems, and its PKI is worse off.  There's a lot of self signed certs
there making certificate path validation problematic.  Just my two cents.

-Wei

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 13:31:26 -0400

Again, how does the draft advance on the existing RFC?

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Apr 2017 11:59:38 -0600

I have learned much in this thread!

--

---

From: "John R Levine" <[email-masked]>
Date: 21 Apr 2017 16:49:58 -0400

> https://tools.ietf.org/html/rfc4386

I don't see what the connection is.  RFC 4386 tells you how to find an 
LDAP or OCSP server.  This is a profile of RFC 4387, which tells you how 
to find a key server for S/MIME and PGP keys, how to retrieve keys by 
e-mail address from it, and optionally how to check whether a domain has 
signed the keys it returns.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Apr 2017 09:31:09 +1000

> not obvious to me why that would be wrong.

https://tools.ietf.org/html/rfc8017#section-6

If you are using ECDSA/ECDH, then you can also commit the same abuses.
Historically, keys were saved with an "EC" type, and can be used for
either interchangeably (the library I work on commits this sin).  In
the case of EC, there isn't a known path from use of ECDSA to abuse of
ECDH and vice versa, but it isn't known to be safe either.

This is much harder, if not possible with the X25519/Ed25519 pair,
because no library will support you in this.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Apr 2017 08:28:40 -0400

> because no library will support you in this.
​That isn't actually true. My library supports encryption on the Ed25519
curve and it does it for a very specific reason.

The Montgomery curves are only designed to support scalar multiplication,
they don't expose a primitive for point addition because you don't need
that for operations using EC keys. You do need EC addition for operations
on keys however and that is what a lot of my code does.​

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Apr 2017 14:12:17 -0700

On 4/20/2017 6:20 AM, Jon wrote:
> So, why hasn't key exchange been made to
> be transparent? Why are (E)SMTP servers not also key servers?

SMTP is a transfer protocol, for sending a specialized 'file' /to/ a 
server.  A key server needs a query transaction, to get small bits of 
data /from/ a server.  They are fundamentally different interaction 
service models.

A closer approximation would be DNS, which perhaps explains DKIM and 
DANE, as has been cited in this thread.  (However they are at the domain 
level and you appear to be targeting per-user keys, given the PGP 
reference.  That's a much harder problem.)

The deeper concern is the apparent view that lack of key servers is the 
limiting factor in use of encryption.  Typically, the problem is 
assessed as usability -- key management on the infrastructure side, and 
end-user interface on the apps side.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Doug Royer <[email-masked]>
Date: Wed, 26 Apr 2017 18:28:40 -0600

> data /from/ a server.  They are fundamentally different interaction 

Yes.

 From an implementation point of view the MX/MTA is currently the only 
'authority' for what is a known email for a domain.

LDAP is generally not exposed to the Internet.

I understand that if a new non-MX/MTA protocol is designed, any 
compliant MUA and MTA would have to be rewritten, along with a new key 
server.

I was thinking that having them combined would be less new code and 
typing :-)

> end-user interface on the apps side.

I tend to believe the deeper concert is the lack of any standard way to 
get an individuals key. Once a protocol exists, then the MUA's can 
implement it. And there should be NO UI issue. User enters the 
destination email address, user says encrypt this, it works or is told 
the destination email has no cert available.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 26 Apr 2017 22:26:56 -0600

While discussing this topic in non-list email. I had other points that 
came up.

(1) The cert for a domain does not necessarily have the same CA as all 
other certs for users in a domain.

	Example:
		[email-masked] may have a CA assigned by
		the example.com, it could be self signed.

		[email-masked] may have a cert provided by an
		unrelated CA to [email-masked]

		Which can be a different cert from the site:
			https://virtual-host.com

		That happens to be hosted on example.com

Real life example, [email-masked] has a cert, the CA is 
StartCom. (This email is signed by that StartCom cert).
And it is not the same CA used by [email-masked]

Both are at google.com, both have a different CA.

(2) Certificate chains.  [email-masked] may have a cert signed by 
the eng.example.com, and the eng.example.com cert may be signed by the 
example.com CA. The example.com CA, could be self signed, or be signed 
by an outside CA.

--