There are two well-distinguished layers in this W3 scenario. The first layer is that of the World Wide Web and is situated between the browser, the proxy and the CGI programs. In this layer, the client poses requests to the server by activating a hyperlink; this hyperlink contains a call to a CGI program which creates the server's response: a HTML page which in turn contains a hyperlink to the next CGI program in the sequence; this is the layer of the HTTP protocol.
The second layer is located between the Plasma applications on the client and server sides. Here, data are passed through to the security platform so that Plasma may perform cryptographic operations on them. The protocol to be used between the Plasma applications is predetermined by the application independent API of Plasma and may be considered separable into three phases: The connection establishment and authentication phase, the secure document transmission phase, and the connection teardown phase.
When integrating Plasma into the WWW the principal problem is to pass the
data on both sides from the WWW layer onto the Plasma layer. On the
serverside this is possible using CGI programs (Common Gateway Interface
[12]). When using a Mosaic browser, a CCI implementation (Common
Client Interface [11]) on the client side and CGI programming on the
server side would be possible; but here it is not possible to encrypt a
client's request![[*]](icons/foot_motif.gif){kind=icon}
: The client formulates his request by
activating a hyperlink to a server side page. This causes the service request
to be forwareded immediately to the server. In addition to that, the
request can also be transmitted to the CCI interface ``in parallel'' (and
therefore to Plasma) - but by then it is already too late to secure the
request. A PlugIn is another possibility for a browser to pass data to
another program and to read back the response from this program. The PlugIn
API is a proprietary extension of the Netscape Navigator API and is not
supported by other browsers.
The Plasma relevant data are embedded into the HTTP protocol; to fulfill the requirements for browser independent communications there is to find a way to pass the information onto Plasma on the way from client to server and conversely, i.e. to filter the data for the security platform. Therefore it is not possible to use a special propose filter module because HTTP is not aware of the filter.
The proxy, however, is well known of the HTTP protocol. Proxies in W3 buffering the informations from the server on clientside and handing over these data to the browser if they are completely arrived. So the proxy is the component where the filter functionality can be integrated. Therefore Plasma has been integrated into the World Wide Web using a proxy on the client side and using CGI programs on the server side. This allows a secure usage of the World Wide Web by all clients, no matter what the browser of their choice might be (Netscape, Mosaic,...).
The data to be passed on to Plasma can only be transferred on WWW via the HTTP protocol. Informations intended for Plasma are so-called Plasma tokens. There exists three different kinds of Plasma token; the Plasma application has to discern whether the token is an authentication token (type X509), a document or Container token (type Cont), or a Final token (type Finl). It must be possible in any phase of the protocol between the PLASMA applications to pass data from the WWW layer onto PLASMA:
Because these Plasma tokens can only transferred on the WWW, they are transferred connected to elements of the HTTP protocol, i.e. the replies of the server and the requests of the clients. These HTTP elements include comments field not considered by the HTTP protocol which can be used to fill in the identification tag for the filtering process. These packages will be called in the following as Plasma packets. Plasma packets contain consequently an identification tag which the CGI programs and the proxy may detect.
The communication between web client and web server is not diverging from the normal HTTP protocol, therefore the architecture presented here can also be performed with a firewall. It is, however, important to note that the proxy used as a filter should not be the same proxy used for protecting a domain by a firewall. For a secure web scenario every client user has to start the proxy on this machine, where he started his own PLASMA system; every user should start in the best case his own proxy.
