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