From: Raph Levien <raph@c2.org>
Date: Sat, 18 Nov 1995 16:57:26 +0800
To: cypherpunks@toad.com
Subject: Design proposal: crypto-capable generic interface
Message-ID: <199511180842.AAA06560@infinity.c2.org>
MIME-Version: 1.0
Content-Type: text/plain


Hi to cypherpunks who write code,

   The recent discussion of "plug-in" crypto is reminding me of some
design work I did earlier this year. This post presents the motivation
and some of the details of that design, slightly updated.

   First, a few words about what I consider to be good interface that
can support plug-in crypto. It has to support both email and the Web;
I feel that everything else follows. It should support completely
transparent integration, by which I mean no extra clicking or commands
or anything like that. Finally, it should be generic in that it will
support a number of other plug-in applications besides
cryptography. Two specific applications which interest me are file
format conversions and external-body resolving.

   The design is based partly upon .mailcap, which is perhaps the best
example of a generic interface we have today. However, while .mailcap
is a nice interface for popping up windows to present semi-interesting
multimedia types, it certainly cannot support transparent
cryptography. I feel that its primary weakness is the inability to
support MIME to MIME rewriting. However, .mailcap has some good ideas
which are worth stealing.
   For the purposes of this proposal, I will assume that all objects
are MIME encapsulated. I think that's a reasonable assumption, as it
handily covers all cryptographic protocols that have any hope of
surviving.

   I will propose my design at a very high level. Please forgive me
for leaving out the juicy details.

   I propose that the new interface lives as a sort of daemon, rather
than a static collection of command line script pieces. A reasonable
way for applications to talk to the daemon would be Unix domain
sockets, or whatever the equivalent is on Mac and Windows
platforms. There should be a simple protocol for automatically
starting up a daemon if there isn't one already running.

   The first part of the interface is the negotiation. The daemon
tells the application what MIME types it can understand (this part is
very similar to the .mailcap file, but doesn't include the
corresponding command lines). In reply, the application tells the
daemon what MIME types it can understand (this is like the
Http-Accept: field in HTTP).

   Once the negotation has been established, the application can send
the daemon MIME objects that the app does not understand but the
daemon does (for example, an image/fractal). The daemon can return a
MIME object that the app does understand (for example, an image/ppm).

   Alternatively, the daemon may request an authentication. This is
useful when resolving external bodies that require authentication,
including non-anonymous FTP, and standard authenticated HTTP. In this
case, the daemon sends a message to the app requesting the
authentication. It specifies whether it needs both username and
password, or just password. In the latter case, it hands a username to
the application.
   The application can then query the user for the authentication
data. It hands this back to the daemon. In reply, the daemon indicates
success or failure. In case of success, it hands the object back to
the app.

   I'm quite pleased with this protocol as outlined. It's fairly
simple, which means it might actually get implemented. It's also easy
to see that it does exactly what you want for file format conversions,
external body resolving, and decryption of encrypted messages.

   Encryption is a bit more tricky, but in essence you just hang a
premail-alike off this kind of protocol. The hard part is specifying
the key, but you just call it a "parameter" and put in hooks for the
daemon to ask for whatever parameters it needs. This requires that
keys have some nonforgeable names, which is unfortunately not a
feature of PGP 2.6.2. S/MIME will do it just fine, if you buy into the
Certifcation Authority (<wink> at Nick Szabo).

   One final aside: I've been fairly frustrated with this mailing list
as a forum for talking about real design proposals and implementation
issues. Ignorant posts by the likes of Dr. Fred and Alice d'Clueless
tend to attract far more attention than real crypto work. I want a
forum for, and just for, cypherpunks who write code. If I had just a
smidgen more free time (as if), I'd be trying to start one
myself. Anyone else?

Raph