The primary purpose of the World-Wide Web Consortium (W3C) is to promote interoperabillity among the growing number of clients and servers on the World-Wide Web. At the current time, one of the most critical interoperability problems in the Web revolves around the technical, political, and commercial problems related to security and electronic commerce. This proposal provides a framework for addressing these problems. Where possible it defers to existing standards (both de facto and de jure). In some cases, however, this proposal leads these standards or deviates in some ways. The W3C plans to address these issues over the next three months and will report its findings to the Working Group at that time. In addition, W3C is asking the Working Group to elect a (small) Security Advisory Committee. This committee will be consulted, on an on-going basis, to provide feedback and direction to its security work between meetings of the full Security Working Group.
Building on the work of earlier meetings of the Working Group, we have been exploring ideas similar to those which inspired Secure HTTP. In examining the problem, however, we have come to believe that there is a more important starting point: the ability to integrate vendor-supplied extensions to both clients and servers on the Web. Given a sufficiently flexible extension mechanism, we believe that all of the important security problems can be addressed; the majority of this proposal provides details to support this conclusion. The resulting system has impact on the Web far beyond the security domain; as such we believe it will not be necessary to pursue export approval for the basic framework. At the same time, SHTTP is close to a subset of the overall framework.
While CGI provides a convenient mechanism to extend servers, it has three fundamental limitations for our purposes:
David Kristol (Bell Labs) has submitted an RFC to the IETF which addresses these problems. Our proposal is similar to his, although different in detail; harmonizing the two proposals will be a high priority item if the Working Group approves this proposal. The basic idea is simple: a header line is added to HTTP requests and responses which specifies a processing pipeline to be performed by the recipient (i.e. the server for a request, the client for a response). Processing is specified by giving the name of a protocol that is being observed, and each such protocol specifies the syntax of additional header lines it may require. In essence, the HTTP header lines act as a caller-side named parameter passing mechanism (as in Ada or CommonLisp) with the protocol specification giving the parameter names, their data types, and the encoding mechanism to be used for passing them.
To show the power of this extension mechanism in the security context we have chosen eight well-known problems, and outline the way the extension mechanism can be used to solve each. The solutions we show here are neither optimal nor carefully worked out. Again, this will be a high priority item if the approach is approved by the Working Group.
We add one new header line to HTTP requests and responses, Plug-Ins. The purpose of the line is to specify a pipeline of processing to be performed by the recipient. The syntax of the line is as follows (we follow RFC-822 specification with regard to whitespace, line breaks, continuation lines, etc.):
<Plug-In> ::= Plug-Ins: <ProcessSpec>+
<ProcessSpec> ::= { <protocol> [tag=<anum>+] [<keyword>]}
<protocol> ::= <anum>+[.<anum>+]*[(<parameters>)]
<keyword> ::= required | optional | suggested | deprecated
<parameters> ::= <parameter>[, <parameter>]*
<parameter> ::= <anum>+ = <anum>+
<anum> ::= <digit> | <alpha>
<digit> ::= 0 | 1 | ... | 9
<alpha> ::= a | ... | z | A | ... | Z
Here's an example:
Plug-Ins: { compression.gzip }
{ security.signature.pkp suggested }
This specifies that the entire message (request or response) must first be decompressed using the gzip mechanism. After that, the message will be seen to contain a PKP digital signature. It is suggested by the sender of the message that the signature be verified.
The <parameters> are intended to allow the specification of variants of the protocol when the use of an additional header field is not possible (for example, when the protocol implies that the entire rest of the message has been encrypted). The <tag> is used when there are multiple <ProcessSpec>s and they require header fields with identical names. In that case, the <tag> is used as a suffix to the specified header field name for the protocal with the <tag> field. For example, assume the security.signature.pkp protocol requires an additional header field named signature, and see the header line:
Plug-Ins: { security.signature.pkp tag=.pkp }
Instead of using the signature field, the PKP signature processor will use the field named signature.pkp.