See what happens when you call my name (or at least try to...) James is > Amanda is >>

...

This seems a very relevant criticism: Has Amanda, or anyone else proposed an extension to HTML that would incorporate such things? Actually, it's not an extension to HTML, but to MIME (whose formats HTTP uses top tag and label data), and it just went to Proposed Standard (the last step before Internet Standard). The MIME multipart/signed and multipart/encrypted body parts allow anything using MIME encapsulation to sign and/or encrypt arbitrary body parts. Since it's at the document layer, it requires no special transport software, works with existing proxies and caching servers, and allows secure HTTP software to share code with secure email software (since it would use exactly the same formats). The framework is general enough to allow use with either PEM-compliant signatures and encryption or others (such as PGP). I believe that can also be used with symmetric key management, which could be useful for special purpose applications. Uh, PEM-MIME no longer supports symmetric key management.

EInet's secure SHTTP proposal is also an end-to-end security framework. Actually, it's EIT. EInet is an MCC (the people who did MacWeb, not to be confused with MCOM, the people who did Netscape. Confusing, ain't it?) project.

Anyway, the approach that Amanda describes is pretty much the one that SHTTP takes. We use already established encapsulation formats to do data encapsulation. SHTTP can be used to enhance either entire protocol messages or objects or both. (You can do both in the same message using a recursive encapsulation). I think Amanda has done an adequate job of talking about end to end security, so I won't talk about that. I would like to briefly motivate why just using PEM-MIME isn't enough, though. (We considered it and believe me it would have been a lot easier on our brains and fingers...) PEM-MIME and to a lesser extent PGP are basically cryptographic messaging formats intended for email type applications. However, the email model is fundamentally different from the Web model in a number of ways. Let me just give one example: In the email world, you don't necessarily have any sort of prior relationship with the person you're communicating with and that public key cryptography is relatively cheap. (When it takes minutes to ship mail across the net, who's going to notice a second or two of signature verification?) However, in the case of the Web, things are very different. When a server replies to one of my requests, we have definitely exchanged at least one message. Now, assume for the moment that my request was encrypted and that I desire confidentiality for the reply. There is no need for the server to perform public key crypto because we've had the opportunity to exchange a key already. This means a substantial performance improvement. [It incidentally means that a server and I can communicate privately even if I don't have a key pair]. When I say that just PEM-MIME is inadequate, I don't mean to imply that using it is inadequate, however. On the contrary, we use PEM and PKCS7 already and are gearing up to include PEM-MIME, now that it's going to proposed standard. [Incidentally, there's no reason you couldn't use PGP too, although I propose that it's most useful in the proposed PGP-MIME multiparts...] And you should be able to reuse your PEM-MIME engines to write SHTTP handlers. It's just that we also took on some issues that we thought were important that we couldn't steal solutions for.. -Ekr