CCI-Based Web Security: A Design Using PGP

Judson D. Weeks

Adam Cain

Briand Sanderson

Abstract We describe several ways of using the general-purpose Common Client Interface (CCI) for enhancing the security of communications on the World Wide Web (WWW). In this approach, the Web browser communicates with an external CCI application that handles the processing of digitally-signed and/or encrypted data. Our particular design uses the popular Pretty Good Privacy (PGP) software for all cryptographic operations. We define a PGP-CCI protocol which can be used to protect any HTTP message exchange, and we also describe a simpler scheme for PGP-protected form submissions (HTTP POSTs) which may be implemented without modifying web servers. Additionally, we discuss the advantage of using a PGP-CCI application to handle pre-encrypted/signed Web documents in a user-friendly manner. Keywords: Security, Pretty Good Privacy (PGP), World Wide Web (WWW), Common Client Interface (CCI), Cryptography

Introduction

The multifaceted issue of security is inexorably entangled in the World Wide Web. To make manageable the complex task of "securing the Web," we may (imperfectly) divide the issue into four interrelated components [17]:

System Security Ensures that use of Web browsers or servers does not expose host computers to undesirable intrusions Authentication Verifies the identity of Web clients and servers on either end of a connection across an untrusted network Authorization Determines what operations are allowed for particular entities on the Web (e.g., server-side access control applied to Web documents) Confidentiality/Integrity Protects private information from capture or modification as it travels across the open network

While all of these security components are extremely important, most recent Web security development efforts have been aimed at improving the authentication and confidentiality aspects of communications on the Web. In fact, multiple solutions have been offered to address these needs. Secure-HTTP (S-HTTP) [16], as well as systems using Message Digest Authentication[10] and Kerberos-based approaches [4], provide application-layer solutions. Meanwhile, the Secure Socket Layer (SSL) [8], Private Communication Technology (PCT) [1], and DCE-Web [14] systems all address similar needs by providing security closer to the network layer. Despite the difference in approach, the main goals of all of these technologies are the same: to secure Web communications by authenticating Web clients and servers and to cryptographically protect the data exchanged between them.

How do we, both as developers and regular users, deal with this proliferation of Web security schemes? Having a diversity of security technologies is indeed desirable, as we would like to be able to quickly switch from one to another in case of, for instance, a new potentially catastrophic weakness discovered in a particular protocol, algorithm or implementation [11]. However, we would prefer to not have to install multiple browsers and servers for this purpose alone. And, from the developer's point of view, the dreaded "browser bloat" phenomenon will probably make supporting all desired security mechanisms infeasible.

A few systems have been proposed to allow for the peaceful coexistence of the Web security schemes. The Spyglass Security Plug-in Module (SPM) architecture [9] describes a new communication interface between a Web browser and multiple security "modules." The World Wide Web Consortium (W3C) is currently developing HTTP extensions to allow for more flexible negotiation of security parameters. Also, new "portable-code" languages, such as Sun's Java [12], have been suggested as technologies useful for easily adding browser support for various Web security schemes. Currently, none of these systems are in widespread use.

Using a General-Purpose Browser Interface for Web Security

As a novel approach to dealing with this dilemma, we look to the Common Client Interface (CCI) as a means to providing application-layer support for Web security features. By so doing, we hope to enable authenticated and/or signed Web communications in a way that is easily supported by any browser with a general-purpose interface similar to CCI. Additional advantages of this design include the graceful handling of documents which are themselves signed and/or encrypted, and the ability of browsers with no native capabilities for encryption to employ the design. This design will greatly ease the process of international distribution, as all security functionality is completely divorced from the Web browser.

Rather than implement all necessary security features needed by the CCI application from scratch, we make use of the popular Pretty Good Privacy (PGP) software [7] to handle data encryption, signature verification, key management, etc. In essence, the PGP-CCI application is a GUI-based front end to PGP which communicates with the Web browser via CCI.

To demonstrate the feasibility of this scheme, we present the PGP-CCI protocol which can be used to allow the signing and/or encryption of HTTP messages. Similar to S-HTTP in design, this protocol uses HTTP extensions, new HTML anchor attributes, and advanced CCI features. The simpler "PGP-POST" scheme is also described, which uses the PGP-CCI application to encrypt and/or sign HTML FORM submissions and does not require modified web servers or advanced CCI functions.

Outline for the Remainder of this Document

Before jumping into the mechanics of the PGP-CCI and PGP-POST designs, we first clarify the utility of handling signed and or encrypted documents, as opposed to applying similar security enhancements to HTTP messages or communication channels. Next we review the relevant characteristics of CCI, PGP, and previous work combining PGP with the Web. The function and features of the PGP-CCI application are then described, followed by details of how to use this application to handle the viewing of PGP-enhanced documents. We then explain the PGP-CCI protocol and the PGP-POST system, giving example HTTP messages resulting from use of these schemes. Finally, we discuss the security protections offered by these new systems, as well as some security considerations for the use of CCI.

Assumptions About the Reader

Throughout this paper we assume that the reader has a working knowledge of the World Wide Web, HTML, the HTTP Protocol, and the basics of cryptography and digital signatures.

Where Do We Sign?

The distinctions between security of channels, messages, and documents are subtle but crucial. Schemes such as SSL [8] and PCT [1] address the need for secure channels in the form of authenticated, encrypted socket connections which may be used by Web applications. S-HTTP [16] and the PGP-CCI protocol described below, allow for HTTP messages that are signed and/or encrypted. Both of these approaches to secure communications have their strengths and weaknesses, and each will probably have a place in the grand Web security context. However, thus far there has been minimal attention paid to the handling of documents which are security-enhanced. Such documents may be signed and/or encrypted using a variety of security applications in wide use today, such as PGP.

What's the difference? Consider the example of a web site run by a government organization distributing documents which are important, but not secret (1). Documents of this type may be digitally signed by the organization as a matter of course. In any case, a browser viewing such a document on the web may wish to know that the document itself is authentic and has not been modified in transit. Furthermore, it may not matter at all from which web server the document was retrieved or what encryption mechanisms were employed to secure the channel. All that matters is that the document was signed by the government organization in question.

Channel-oriented security schemes can only authenticate the parties on either end of the connection and provide an encrypted channel for the data. Using these systems alone, there is no possibility for signed messages or documents, and thus non-repudiation is not achievable. In other words, these schemes cannot, by themselves, provide signed data which can be stored and used later to prove that the signing party committed to a particular action. This is simply a consequence of putting the "security smarts" below the application layer.

With message-based security enhancements, we can obtain signed or encrypted HTTP messages. This achieves authentication of, and private communications between, the two message sources: the web server and the user of the web browser. Such messages could be stored (although this function is not usually implemented) and used to prove that a particular document was served by a particular web server. However, this is not the same as having a document signed by the information provider. To understand the difference, consider the case in which our governmental organization wishes to distribute an important document using many other organizations' web servers. We would like the document to bear the signature of the organization authoring it; the authentication of the particular web server used to serve the document may be of no interest at all.

Currently, Web applications do not deal well with signed/encrypted documents. A browser user certainly can fetch and view a digitally-signed text file, for example; but to verify the document's signature, the user would have to save the file locally and manually run PGP (or the user's preferred security program) with the local file as input. An improvement in usability is offered in [13] although a GUI-based scheme with tighter browser coupling would be preferable.

A New Approach: Security Using CCI, PGP

Given the relative strengths and weaknesses of sockets-layer security and application-layer security, we have adopted an application-layer security scheme that takes advantage of message-based security enhancements while making provisions for handling signed and/or encrypted documents as well. To this end, we exploit of the flexibility of the Common Client Interface combined with the power of the Pretty Good Privacy encryption package.

CCI

The Common Client Interface, or CCI(2) is a client-side API (Application Programmer Interface) that is designed to expand the functionality of browsers without having to alter the code of the browsers themselves. While there are many variations of CCIs (e.g. Spyglass' SDI [3]), they all provide a means for Web browsers to communicate with other applications that reside on the client, henceforth referred to as CCI applications.

The CCI is a two-way communication protocol with functions that drive the browser (such as OpenURL() [3], which tells the browser to load in a document at a specific URL, and Post() [17], which tells the browser to submit an HTTP Post of escaped data to a specific URL) and functions that re-route output from the browser to the CCI application (such as SendOutput() [17], which routes server responses with certain Content-types to the CCI application rather than having them viewed by the browser). These functions allow application developers to easily integrate a wide range of functionality with the features of a Web browser. For more information on CCIs, see [15], [3], and [18].

Note: While there is at least one CCI which enables communication between the browser and applications running elsewhere on the network, we assume that browsers supporting such CCIs are configured to communicate only with local applications. This is necessary in order to obtain a more secure link between the Web browser and the PGP-CCI application.

To explore the feasibility of CCI-based Web security features without building all necessary cryptographic tools from scratch, we chose to design a CCI application which would act as a frontend to the popular cryptographic software package known as "Pretty Good Privacy," or PGP.

PGP

PGP, originally designed by Phillip Zimmerman, is a sophisticated program to handle the bulk of security needs for documents and message-passing systems. PGP is a public-key cryptographic package that provides protection of documents and messages using symmetric or asymmetric encryption for confidentiality and digital signatures for authenticity and integrity. For further information on PGP see [7] and [19].

Besides providing the tools to secure Web documents and communication, PGP has several other advantages. First, it is freely available in various forms worldwide. Also, it is widely used on the net already, allowing for easy adoption. Next, it has a distinctive trust model in which each user decides how much they wish to trust the public keys of others. In essence, the user becomes his or her own certificate authority and is not forced to rely upon validation by some global authority. To accomplish this, each PGP user maintains his or her own keyring, which is a list of the public keys of others with an associated trust level for each key. As PGP encounters unrecognized public keys, PGP warns the user and asks whether he or she wants to add the key to his or her public keyring and if so, what trust level should be assigned to the key. Under this model, individuals sign the public keys of trusted entities and exchange these with other trusted entities, to build a "web of trust". This allows PGP to be used now, while the certification infrastructure is in its infancy, and then be integrated with the infrastructure as it develops.

Using these functions, we are able to construct a protocol that will allow clients and servers to authenticate each other, provide document access control, keep messages and data confidential as they travels across unsecured networks, and even verify the integrity of documents stored on unprotected servers.

Related Work

While the use of a user-friendly CCI application as an interface between PGP and Web browsers is new, the idea of combining Web applications with external cryptography packages like PGP is not. In fact, simple external function calls, or hooks, were added to XMosaic and NCSA httpd to allow each to run PGP or PEM for handling encrypted, signed HTTP messages [2]. This was effectively a proof of concept implementation which lacked provisions for key management, secure passphrase handling, and other features essential for a valid Web security scheme.

Of special note is the fact that an early version of the Secure HyperText Transfer Protocol, S-HTTP [16], partially defined support for PGP-enhanced messages. The details of using PGP with S-HTTP were not fully specified, and an implementation of this mechanism was never created. In the current S-HTTP specification [16], the PGP-related definitions have been dropped altogether.

The PGP-CCI work described here builds on the previous PGP/PEM hooks, adding flexibility and user friendliness (via GUI-based CCI application), while avoiding the requirements that all keys be exchanged out of band and that cleartext passphrases be stored in scripts. This work follows a scheme similar to S-HTTP, although the protocol is considerably simpler than S-HTTP and may be implemented via CCI without native support for cryptography built into the browser.

PGP-CCI Application Description

The PGP-CCI application is essentially a link between the Web browser and the functions provided by PGP. The CCI application itself may be implemented as a GUI shell to a command-line interface for PGP, or as a complete application built using the PGP source code or even the upcoming PGP API. The PGP-CCI application also functions as a viewer for documents that have been encrypted or signed by PGP (see "Viewing PGP-Enhanced Documents via CCI" below). The security issues for the PGP-CCI application fall into two categories: those issues connected to the interactions between the PGP-CCI application, the browser and the server and those issues connected to the user interface of the application itself. The security issues with the interactions between the PGP-CCI application, the browser, and the server are detailed in the PGP-CCI protocol below. The user interface issues are as follows.

Given the potential for security breaches that automation can provide, the PGP-CCI application must display the following information to the user:

Security status of the current message or document: plaintext, signed, encrypted, or signed and encrypted

Encryption method used: symmetrical session key or the public key of the user

When applicable, message or document signature information: the PGP username, Key ID and date of signature on the message or document

URL of the current message or document

All of these items are necessary to ensure that the user is properly informed about the security status of the messages or documents that are being handled. The third item is particularly important as neglecting to check this kind of certificate information can potentially allow certain types of spoofing attacks (although PGP's trust model makes such attacks less likely to succeed).

One of the cornerstones of PGP security is the importance attached to signing or decrypting a document. Each of these activities requires the use of the user's private key and therefore must be handled with great care. Accordingly, PGP defaults to prompting the user for a pass phrase on every such occasion. Given the frequency with which either of the activities will occur in a Web environment, the PGP-CCI application could optionally cache the user's pass-phrase after he or she enters it the first time; thereafter, the user is merely prompted whether he or she wishes to sign or decrypt. However, if this approach is used, it is very important that adequate measures be taken to insure that an unattended system cannot be abused (e.g. time-out features, periodic flushes of the pass-phrase to prevent recovery of the pass phrase from the cache or user-sloppiness).

Given the amount of HTTP messages and responses that normal web-surfing creates, running every HTTP request through the PGP-CCI application, as detailed in the PGP-CCI protocol below, can become quite a performance hindrance. For performance reasons, the PGP-CCI should be equipped with a feature to easily enable or disable the routing of HTTP requests to the CCI application from the browser. Note that even when the handling of HTTP requests is disabled, the PGP-CCI application should be able to handle the viewing of PGP-enhanced documents.

Viewing PGP-Enhanced Documents Using CCI

As outlined above (see "Where Do I Sign?"), viewing security-enhanced Web documents is a highly useful but often neglected function. However, using CCI makes the implementation trivial. No changes have to be made to the code of either the client or the server; all that is necessary is the addition of a new MIME type.

Storing PGP-Enhanced Documents on a Web Server

Documents signed and/or encrypted with PGP usually have filenames ending with .pgp or .asc, the latter extension signifying that the data is encoded in ASCII-armored (text) format. For transfer of PGP-enhanced documents, we propose the use of the following MIME type:

Content-type: application/x-pgp

Therefore, the only requirement of the web daemon serving such documents is to map the appropriate file extensions to this new content type (3). Usually this process involves adding a new line to the mime.types file on the web server, such as the following:

application/x-pgp pgp asc

That's all there is to it for the server! Even web daemons oblivious to PGP or any other sort of cryptography may serve PGP-enhanced documents by this method.

Viewing PGP-Enhanced Documents

On the client side, the PGP-CCI application registers as a viewer for the application/x-pgp type during its initialization. Thereafter, whenever the browser requests and receives a document of this type, the received data is sent to the PGP-CCI application, which passes the document on to PGP. By processing the output of PGP, the browser can obtain all the information it must display to the user. This includes taking appropriate action in the case of an invalid signature or a failed decryption. Also, if the document turns out to be encrypted using the client's public key, the CCI application should prompt the user before resubmitting the document to PGP along with the user's passphrase, as outlined above (see "PGP-CCI Application Description").

The elegance of this handling of PGP-enhanced documents is that after decrypting or verifying the document signature, the PGP-CCI application tells the browser to display the document. This should work equally well if the document is text, HTML, graphics, or any other media the browser can recognize.

The PGP-CCI Protocol

Protocol Overview

In addition to handling all application/x-pgp content-types, the PGP-CCI application registers with the browser to receive all requests for URLs with the http protocol and to handle all application/x-www-pgp-response content-types. When doing this, the CCI application specifies that the browser give it the full HTTP messages involved in these actions, as well the anchor attributes for http URLs.

A request for a hyperlink containing the PGP-CCI-related attributes proceeds as follows:

When the user clicks on such a link, the browser tells the CCI application that the http URL has been requested. The browser also passes to the CCI application the complete HTTP request it would normally send to the server, as well as the anchor attributes for the desired hyperlink. The CCI application uses PGP to apply the proper enhancements to request, which usually involves encrypting the message using the web server's public key. If the client does not have this key on its keyring, the anchor attributes can be used to find it. Note that before signing or encrypting the request using PGP, the CCI application adds a Date header and also a header containing a randomly-generated session key. These lines allow the server to protect against replays of the enhanced request. The session key also allows the server to symmetrically encrypt a response for the client without having to deal with finding the client's public key. Note that any time the server's HTTP response is to be encrypted, the client's HTTP request must also be encrypted in order to securely transfer the session key. (4) Once the request is processed by PGP, it is encapsulated within a generic HTTP request which is then given to the browser for retrieval on the network. The server uses PGP to decrypt and/or verify the signature on the encapsulated request. PGP checks the configuration files to determine if the request is properly signed and/or encrypted for that URL, and whether or not the authenticated agent is authorized to access the requested document. It then prepares a HTTP response to be sent to the client. If the request was not properly authorized, the server sends a "401: Unauthorized" response with the HTML body containing a hyperlink for the requested document, complete with the anchor attributes needed to resubmit the request properly. Otherwise, the HTTP response is processed by PGP before it is returned to the client. This step may involve signing the message and/or encrypting it using the session key contained in the client's encrypted request. The content-type for the response is "application/x-www-pgp-response." If the server's response is a 401, the browser will display the server's HTML error message. The user may then click on the hyperlink (with the correct attributes) to resubmit the request. If, however, the server's response was a PGP-enhanced HTTP message, its content-type will cause the full HTTP response to be given to the PGP-CCI application. The CCI application uses PGP to decrypt and/or verify the signature on the server's response. PGP then passes the plaintext of the encapsulated HTTP response to the browser by means of a temporary local file (which is deleted immediately after the browser has read it). The browser processes this response as it would handle any HTTP response, while the PGP-CCI application displays the relevant information to the user, including the server's PGP username and Key ID.

Below is a more detailed description of this protocol. Note that as this is an experimental scheme, the exact names and syntax are subject to change.

Hyperlink Attributes for PGP-CCI

In order to allow for pre-enhancement of HTTP requests, including encryption, there must be additional information in the hyperlink for the URL. For greater compatibility and flexibility, we use anchor attributes for this purpose, rather than defining an entirely new protocol ("pgp-http", for example). Note that the anchor attributes defined may be useful for other PGP-related schemes besides PGP-CCI.

PGPPUBKEYID (required) This attribute identifies the public key of the server at the other end of the hyperlink. The CCI application verifies that all eight characters (32 bits) of the Key ID are present before it uses the Key ID to look up the key in its keyring. Example: PGPPUBKEYID="E9B2BB1D" PGPUSER (optional) The full PGP username of the server is included here mainly for the purpose of providing additional information to the browser user (upon inspecting the HTML source code). When the CCI application attempts to access the server's public key, it uses the Key ID (see above). If the CCI finds the public key, and the username does not match the value given in the PGPUSER attribute, the PGP-CCI application warns the user and asks for an "OK" before proceeding. Example: PGPUSER="Topsecret Web Server <www@topsecret.org>" PGPPUBKEYBLOCK (optional) The server may include its public keyblock in the anchor. The CCI application will check first on its keyring for a public key matching the Key ID. If CCI doesn't find such a key, it will next look to see if the keyblock is provided in the anchor. Example: PGPKEYBLOCK="Version: 2.6.2 mQCNAy6sAAAEEAMrb2LlS8sPOwSbwAZg0psGOZrhgtGpjqd2RyC/H8Du 90yFpiANAVVuaZyE/EgEtvA7ixX0CDJnlVyiL3Nagn5IVKN4ifupAAUR tCNKb24gTS4gRYW4gPGpkdWdhbkBuY3NhLnVpdWMuZWR1Pg== =CKpP" PGPPUBKEYSRC (optional) If the CCI application doesn't find the public key on either its keyring or in a keyblock within the anchor, it will check for a pointer to the server's keyblock. The PGPPUBKEYSRC attribute provides such an anchor. Naturally, the CCI PGP application checks to see that the public keyblock retrieved using this URL/URN has a Key ID which matches the value in the PGPPUBKEYID attribute. Example: PGPPUBKEYSRC="http://www.topsecret.org/pubkey.asc" PGPMODE (optional) This attribute includes values indicating whether the HTTP request should be signed, encrypted or both. If this attribute is not found, "both" shall be assumed as the default. Examples:

PGPMODE="request-signed,request-encrypted"

PGPMODE="request-signed"

PGPMODE="body-only" The latter example refers to the PGP-POST scheme described below, and it signifies that PGP-enhancements should be applied only to the data in the body of the HTTP request (the query string, in the case of a post).

Example hyperlink

A typical hyperlink might look like the one below. Note that the order of the attributes is not important.

<A HREF="http://www.topsecret.org/wherever/whatever.html" PGPUSER="Topsecret Web Server <www@topsecret.org>" PGPPUBKEYID="E9B2BB1D" PGPPUBKEYSRC="http://www.topsecret.org/pubkey.asc" PGPMODE="request-signed,request-encrypted" > Click here for the secret formula </A>

Relevant CCI Functions

While the function names and syntax differ across different implementations of CCI-like interfaces, most of the interfaces have commands which are semantically equivalent. Since many implementations are similar to Spyglass' Software Development Interface, we describe the commands used by PGP-CCI in terms of advanced functions based on the specification for Spyglass' SDI [3].

RegisterViewer (TO Browser) To handle PGP-enhanced documents, the PGP-CCI application registers to view all documents with application/x-pgp MIME types. For the PGP-CCI protocol, the CCI application registers to handle application/x-www-pgp-response Content types, giving the additional "FullResponse" flag to signify that the browser should forward the entire server response to the CCI application. RegisterProtocol (TO Browser) The PGP-CCI application registers to handle all requests for URLs with protocol "http" in order to trap requests to be pre-processed using either the PGP-CCI or PGP-POST scheme. The additional flags, "ComposeRequest" and "LinkAttributes," are also included in the call, to tell the browser that it should give the CCI application the HTTP request it would normally send, as well as the anchor attributes for the requested hyperlink. OpenURL (FROM Browser) If a CCI application is registered to handle a requested URLs protocol, the browser uses this command to pass on the request to the CCI application. If the CCI application included the "ComposeRequest" flag during registration, the additional "Request" argument of OpenURL contains the HTTP request. If the CCI application asked for the anchor attributes during registration, they are included in the "Attributes" argument. OpenURL (TO Browser) This function is used by the CCI application to tell the browser to fetch a document specified by the URL argument. If the CCI application supplies the additional "Request" argument, the browser treats this as the full HTTP request to be put on the wire in order to resolve the URL. The PGP-CCI application also uses this command to tell the browser to view a local file (via the "file://" URL protocol) containing the plaintext of a PGP-protected document or HTTP message. ViewDocData/File (FROM Browser) If a CCI application has registered as a viewer for the Content-type of a received document, the browser uses these commands to pass the CCI application the data to be viewed. If the CCI application registered using the "FullResponse" flag, the browser sends the server's HTTP response to the CCI application.

Server Configuration

To use the PGP-CCI scheme, the server must have compiled support. The server's PGP-related information (such as its PGP username, the location of the PGP executable, keyrings, etc.) is specified in configuration files. When launching the server, the administrator enters the server's passphrase, which is stored in memory and then used for any decryption or signing operation (automatic means for specifying the pass-phrase are available, though not recommended).

Using .htaccess files, or equivalent means, the server may be configured to require PGP-CCI authentication/encryption for accessing certain Web documents. Particular entities, or groups of entities, may be specifically allowed access by referring to their PGP usernames. Furthermore, the necessary enhancements for the HTTP request and the corresponding response may be specified by "require" lines in these configuration files. An example ".htaccess" file for a document directory might look as follows:

AuthType PGP-CCI AuthUserFile /etc/httpd/keyrings/pubring.pgp AuthGroupFile /etc/httpd/.htgroup.pgp require user "John Doe <doe@foo.org>" "Ted Tedman <tt@bar.edu>" require request-encrypted require response-signed

Note that any "require user" lines imply that the HTTP request be signed. Also note that the appearance of a "response-encrypted" line implies that the request also be encrypted (in order to send the session key used to encrypt the response).

Unencapsulated HTTP Request

Assume that the browser user has clicked on a hyperlink like the example link given above (in "Hyperlink Attributes for PGP-CCI"). The PGP-CCI application adds a few lines to the HTTP request before signing/encrypting it with PGP. The resulting plaintext HTTP request might look like:

GET wherever/whatever.html HTTP/1.0 Date: Thu, 05 Oct 1995 16:57:05 GMT Accept: */* User-Agent: NCSA_Mosaic/2.7 libwww/2.12 modified Extension: PGPMODE=response-signed,response-encrypted Extension: PGPENCKEY=keyname1,mr18YmNIc+sU0tGpZyE3

The PGP-CCI application adds the Date header, if not already present. The PGPENCKEY must be a 20-character radix-64 encoded string representing a 120-bit random number generated using a secure random number generator [6]. Note that PGP uses the hash of this string to create a 128-bit session key for use in performing the encryption (5). The PGPMODE parameters are optional, and they are set according to user preferences on the PGP-CCI application. The web server should accommodate the client's requests for security enhancements specified in the PGPMODE, as long as they are not explicitly forbidden in the server's configuration file (via a "require response-unencrypted" line in the .htaccess file, for example).

HTTP Request After PGP Enhancements

After the request is processed by PGP, it is encapsulated within a generic HTTP request. The result might look as follows:

GET / HTTP/1.0 Authorization: PGP-CCI Content-type: application/x-www-pgp-request -----BEGIN PGP MESSAGE----- Version: 2.6.2 pwhjT53Ue2c2cv+mAAAIX+PUGxKzA4mRODt0PnRQyqTwKOHmj81Q90aAuJX7 E8bNEU5OW+r413/ZwpEUiIlkCewco+61ufR7y5yvwoNn383eMM2AdcArGh28 HuYxPCSlxqRHlzFwOZNdhcfA2aPi8gduBBu2guPC7Vtbfg4n9K9PCmYXQPh6 =VSGG -----END PGP MESSAGE-----

The Authorization line is set to "PGP-CCI" to indicate to the server that PGP-CCI scheme should be followed.

Server HTTP Response to Valid Request

If the enhancements on the client request match the server's requirements for the requested document, the request is considered valid. The server then prepares a HTTP response as it normally would and this response is encrypted and/or signed using PGP. The result is prepended with additional headers, and the result might look like:

HTTP/1.0 200 Document follows Date: Mon, 11 Sep 1995 14:23:32 GMT Server: NCSA/1.5 Extension: PGPENCKEY=keyname1 Content-type: application/x-www-pgp-response Content-length: 874 -----BEGIN PGP MESSAGE----- Version: 2.6.2 hGxuwKXyEBAwCkj3VdDLVnCDAqUy28gqK7R0GlVej3L5b+x7C6FN4s4gdf PUiZ4AkCewco+61ufR7y5D4ogWWtY6w3zI7BWfCexxNHvHBRO9e+cQZhLg i6cE8bNEU5OW+r413/ZwpEUiIlnzaJblq9xx4r12wEYlQlexjs1ThUTvXS HzTCSlxqRHlzFwOZNdhcfA2aPi8gduBBu2guPC7Vtbfg4n9K9PCmYXQPh6 =VSGG -----END PGP MESSAGE-----

In this case, the encapsulated message has been encrypted using the session key named "keyname1"; the client supplied this name in the request and may use it to look up the value of the session key for decrypting the server's response. The server may also include its public keyblock in the body of the response, and PGP can use it for signature verification (in case the public key was not found already during the preparation of the HTTP request). Note that the content-type application/x-www-pgp-response causes the data to be sent by the browser to the PGP-CCI application.

Server HTTP Response to Invalid Request

If the proper security enhancements were not applied to the request, as in the case where the user types in the URL by hand, the server sends back a 401 response. A hyperlink for the requested URL, including the relevant anchor attributes, is contained in the message body, so that a client may resubmit the request properly. The entire HTTP response might look as follows:

HTTP/1.0 401 Unauthorized Date: Thu, 05 Oct 1995 03:09:19 GMT Server: NCSA/1.5.1 Content-type: text/html WWW-Authenticate: PGP-CCI <HEAD> <TITLE>Authorization Required</TITLE> </HEAD> <BODY> <H1>Authorization Required</H1> Browser not authentication-capable or authentication failed. <P> This document requires that you enhance the request using PGP. <H2> Try requesting this document again, using the link below, after you have launched your PGP-CCI application </H2> <A HREF="http://www.topsecret.org/wherever/whatever.html" PGPUSER="Topsecret Web Server <www@topsecret.org>" PGPPUBKEYID="E9B2BB1D" PGPPUBKEYSRC="http://www.topsecret.org/pubkey.asc" PGPMODE="request-signed,request-encrypted" > Click here to resubmit your request </A> </BODY>

PGP-POST Description

We now describe a simpler version of the PGP-CCI Protocol that, while limited, can be deployed without having to upgrade to a PGP-aware server. This method is used with HTTP POSTs only and is a variant of the general PGP-CCI protocol described above. Its purpose is simply to allow strong encryption and/or signing of form data.

The main difference between the PGP-POST and the standard PGP-CCI protocol is that in PGP-POST only the data in the query string, and not the whole HTTP message, gets signed and/or encrypted. In this mode, the PGP-CCI application has to make sure that the important data that would normally be in the signed/encrypted portion of the message headers gets escaped and prepended to the query string of the POST data. For example the Date field would be:

Date=Sat+07+Oct+1995+16:57:05+GMT

The fields that have to be handled this way are precisely the headers from the standard protocol that have to be encrypted, namely: