[Endymail] Another view of the problem and what the IETF could do

[Tim Bray <[e-mail]>]

I think the inclusion of the string “mail” in the list title is perhaps
unduly limiting. I exchange a lot of messages on the Internet and, yeah,
some are email but a lot aren’t; various social-media and chat messaging
services.  It seems to me that more or less anything that can interchange
text between humans in an end-to-end way should be able to carry an
end-to-end encrypted payload, and that the IETF should  help facilitate
this.

Suppose a piece of messaging software wants to make it easy for me to
encrypt something for a particular recipient at the other end.  The
following steps are necessary:

1. Find a public key for the user that the sender’s prepared to trust.
2. Encrypt the message
3. Get the message there, then…
4. The recipient uses their private key to decrypt the message
5. Display the message appropriately, depending what it is

I think it’s important that this is not a hypothetical.  Right now on
Android, there are crypto apps (in particular I know of OpenKeychain, but
there are others) that use Android’s “Sharing” system to good effect, so
you can do this:

a. Start with anything: Some text, a picture, a video, whatever, in some app
b. Hit the app’s “Share” button
c. In the list of Share targets is “Encrypt with <crypto app>”
d. <Crypto app> pops up, you pick a recipient from the list of public keys
you’ve stored
e. <Crypto app> encrypts, asks you how you want to share the encrypted
message (mail, chat, whatever)
f. Person receives encrypted message.  Hits “share”. Sends it to <crypto
app>. Crypto app asks for private-key passphrase, decrypts, either displays
result or lets them share it to a more appropriate app.

This works.  Nobody ever sees a hex digit.

Going back to the first list:

1. Find a public key for the user that the sender’s prepared to trust.

This is a big problem. The PGP Web of Trust has failed, and we’ve all heard
the griping about the CA biz.  Joe Hildebrand mentioned POSH & WebFinger
and they’re both interesting.  I’m also interested in the notion of a key
directory with associated proofs that you don’t have to trust, for example
the one from https://keybase.io.  In particular see
https://keybase.io/docs/server_security
WORK FOR IETF: Get pro-active on key discovery/trust work? Standardize key
search APIs?

2. Encrypt the message and
4. The recipient uses their private key to decrypt the message

These are sort of solved by various OpenPGP implementations, and also see
https://minilock.io/
Except for, many people live in the browser and their lives would be
improved if they could do the crypto there. This means trusting
network-delivered JavaScript code, which is a conundrum; I wrote about it
at some length at http://goo.gl/KsKe6u
WORK FOR IETF: Well, maybe, but it feels more like W3C or WHAT or TC39
stuff. Could we help with code-signature specs?

3. Get the message there, then…
Solved nicely by all sorts of internet tools.
WORK FOR IETF: Nope.

5. Display the message appropriately, depending what it is
This is a problem.  Lots of the messages I want to send are movies or songs
or pictures, and if there’s no way to communicate the Media Type, it’s less
useful to the recipient.
WORK FOR IETF: Maybe revive draft-moscaritolo-openpgp-literal ?

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)