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.
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:
alice@xxxxxxxxxxxxxx--MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ
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: alice@xxxxxxxxxxx
Strong-Address: alice@xxxxxxxxxxxxxx--MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ
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.