On 5/2/22 09:20, John R Levine wrote:
We have several decades of S/MIME and PGP failing because nobody knows
how to do key distribution at scale.
I'm not convinced that that's the (only or even most important) reason,
or that it's even true. From my perspective there have been several
barriers to adopting S/MIME and/or PGPMIME, e.g. lack of MUA support,
lack of email domain CAs and support for them among root CAs, lack of a
well known and trusted set of root CAs such as exist for the web (it's
not clear that they should should be the same set), lack of a standard
key discovery mechanism, and (mostly I suspect) lack of mindshare.
When there are multiple barriers to solving a problem, any one of those
problems can become an excuse to avoid solving the other problems.
But it seems likely that enterprises could issue email-only certs for
their employees, and MSPs could issue email-only certs for their
customers. There are limitations with that model, especially for
private individuals. But such a model could be extremely useful for
B2B communications, where what you really want to authenticate is not
the sender's "real name" so much as the sender's role with a company.
And it could be useful for others also, though not for every conceivable
purpose.
The biggest problem in generating such certs is arguably that there are
no established protocols for MUAs to generate keypairs and CSRs, and to
have them request that the MSP issue certs in response. There might
also need to be some new extensions to X.509. Having the MSP act as CA
makes sense when the important identity for the user being authenticated
is their email address and not their name. Certificates used in email
need to reflect that (perhaps SAN already does that sufficiently), and -
more importantly - so do the UIs of the MUAs that interpret those
certificates. "Keith Moore" is NOT the same as
moore@xxxxxxxxxxxxxxxxxxxx and it's important that MUAs not conflate the
two. (MUAs are already notorious for hiding people's email addresses
from message recipients, by default, whether to save display space or
out of some misguided notion of usability.)
Even if MUAs had a way to generate keypairs and CSRs and get certs back,
many people read their mail from multiple MUAs. So that needs to be
managed. Either each user's MUA has a separate key pair, or there
needs to be a secure way to distribute the user's private key to all of
the user's MUAs. I know which one I'd prefer, but either way there are
details to be worked out.
Of course a "3rd party" cert issued by a trustworthy but neutral CA
could be useful in addition to these, especially for mail sent by or to
private individuals. But email is not like the public web. The
model of having a small set of trusted CAs for the web doesn't extend
well to signing keys used in email from or to private individuals. I
used to say that I'd never trust the US Government's certificate for
Phil Zimmerman's key. (nowdays I'd probably say Edward Snowden's key,
but you get the idea). There is no one party or even hierarchy that is
sufficiently trustworthy for all purposes. There are incentives for
even widely-trusted CAs to occasionally lie about the keys for a small
number of specific individuals, and less chance that they'd get caught
doing so when those keys are used in private email than when used on the
public web. One party might well want multiple assurances of another's
public key before trusting that key, but this needs to be made clear in
their user interface.
User interface issues seem like some of the more significant problems
because (for example) it really does make sense for the President's
secretary to sign an email from the President. How do you communicate
to users who has the authority to sign something for purpose A but not
purpose B? And yet, humans have been doing similar things with
signatures on paper for many centuries. I don't think it's an
unsolvable problem unless perhaps you want to cram all of that
information on a watch face.
Then there are questions of how encrypted or signed email should
interact with forwarding and/or mailing lists. Should encrypted mail
sent to a mailing list be decrypted by the list and re-encrypted for
each recipient? How, again, to communicate to the sender that their
message is going to a list and that it's entirely up to the list to
decide how to disseminate the cleartext? Should the sender be made
aware of that before composing or at least sending the message?
And then there's the problem of searching encrypted mail in a mail
store, when you'd like to be able to store the messages as received
rather than having them be stored in cleartext and accessible to the
MSP. Some users, perhaps, will be fine with having their messages
stored in cleartext; others will not.
And finally there are the various enemies of privacy who will fight any
effort to make email more secure, no matter how badly it's needed. And
they won't be honest about either their concerns or their goals.
***
So I see a lot of careful engineering that's needed, and a lot of user
interface work (which is admittedly problematic for IETF), and probably
some hard political work by honest people to overcome the efforts of
dishonest people who will try to subvert it (whether or not they believe
they're doing good).
But I don't think there are fundamentally unsolvable technical problems,
so much as problems that make people uncomfortable - because there's no
simple system that spans a wide enough range of compromises to suit
everyone. But that doesn't mean that there's no system that doesn't
solve most people's problems.
Keith
