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:
alice(_at_)example(_dot_)com(_dot_)mm--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(_at_)example(_dot_)com
Strong-Address:
alice(_at_)example(_dot_)com(_dot_)mm--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.