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.
I think I'm starting to need a quick reference card :).
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].
This is true. Just as an exercise, I'll give a description of the informal model that I have been using as I evaluate different proposals for secure HTTP (and other Internet security proposals). (1) I trust the network somewhat more than I trust the server machine. This is why I don't like SSL, for example. Now, I realize that this assumption is not a universal (someone in a college dorm would trust the server a lot more than the network), but the fact is that once you get off your organizational Ethernet, it's hard to monitor the Internet. On the other hand, servers are a problem. If someone's running a web page on Netcom, for example, I don't want to have to worry about whether or not they've been broken into this week (note that I'm using Netcom strictly as an example--the same concern holds for any public access system). I want to be able to authenticate the content I am viewing without having to worry about whether or not the transport & server systems have been compromised. I'm still vulnerable to a denial of service attack, of course, but at least I can tell when I do get something that it is genuine. This concern holds even when I don't care if the content is encrypted. If I get sales literature, I want it signed by the organization it claims to be from, and so on. And for this purpose, I like X.509. Self-signed certificates are fine, if there are other ways to verify the public key. Signed PGP keys could be used as certificates as well, of course. (2) I want authenticated content all the time, even if it's just to an anonymous key pair I've gotten through some other channel. (3) I want private content sometimes. When I want private content, I want end-to-end privacy, not just transport level privacy. (4) Occasionally, I want transaction security (sending a credit card order, for example), where I want the transaction to be encrypted, signed, and not subject to playback attacks. Ideally, the server itself won't be able to decrypt it--only the actual recipient will. In all cases, I expect the network and the server machines and software to be insecure. Anything else is simply unrealistic. Amanda Walker