Distributing Crypto Software from Theory

Introduction

There is a special Web server running on the machine mynah.lcs.mit.edu that can be used to serve export-controlled cryptographic software from theory NFS space. This Web server is called the Domestic Web Server, or dws for short.

The dws can serve many different software packages. Before a remote Web user is allowed to download software in a package served by the dws, that user must fill out and return a Web form indicating that he or she is allowed to receive the software.

The specific form can vary from package to package, but a form can only consist of simple "yes" or "no" questions, and only a user submitting a form answered with all "yes" questions will be allowed to download a package's software.

The Package Directory

Each software package served by the dws is contained in a directory under the dws home directory, which is currently /a/fredette/Work/dws-theory (this should eventually move - fredette).

Each package directory must contain a form template file and a response template file. Both of these are HTTP files that are processed by the dws before presenting them to a remote user.

The remaining files in a package directory are the files making up the distribution of cryptographic software. These should usually be gzipped tar archives.

For example, currently SDSI is distributed as two packages - one for the United States (under sdsi-US), and one for Canada (under sdsi-Canada). Note that the latter directory contains symlinks to the response template and tar files in the former; this is because only the form template is different for US and Canada users - the response template and the software they get are the same.

All distributions should follow the SDSI model, with one package each for the US and Canada, with different form templates, but with symlinks in the Canada directory to the response form and software in the US directory.

The Form Template - `form.html`

Each package directory has a form template file in it. This file has the name form.html and contains the HTML that is returned to a remote user when they first connect to the dws.

This file contains whatever legalese your software requires, in the form of the authorization questions and instructions for the user. As mentioned, the authorization questions must only be "yes" or "no" questions, and all of the questions have to be answered "yes" for the user to be granted access to the software.

The authorization questions themselves must be inside an HTML POST <FORM>. The names of the <INPUT> or <SELECT> form elements that the user fills are generated automatically by the dws as it serves the page to the user. The dws does this by looking for the string %DWS-QUESTION% in the form.html and replacing it with an element name that is different each time the form is served. (Using these generated names prevents a remote user from POSTing for software without first retrieving the form.html.)

For example, this excerpt is from the sdsi-US package's form.html file, at /a/fredette/Work/dws/sdsi-US/form.html:

Users who  wish to obtain a copy of SDSI are required to answer the
following questions:<p>
<hr>
<FORM method="POST" action="http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/sdsi-US">

    Are you a citizen or  national of the United States  or a person who
    has  been lawfully admitted   for permanent residence  in the United
    States under the Immigration and Naturalization Act?<p>
<select name="%DWS-QUESTION%">
<option value="no" selected> No
<option value="yes"> Yes
</select>
<p>

    Do   you agree not   to export  SDSI,  or RSA  to the  extent
    incorporated therein, in violation of the export control laws of the
    United States   of  America as   implemented by the    United States
    Department of State Office of Defense Trade Controls?<p>
<select name="%DWS-QUESTION%">
<option value="no" selected> No
<option value="yes"> Yes
</select>
<p>

After all of the authorization questions, but before the end of the <FORM>, you must also include the string %DWS-FORM-HTML%. The dws substitutes for this string any remaining hidden form elements that it will need to see to check the contents of the POST. From /a/fredette/Work/dws/sdsi-US/form.html:


%DWS-FORM-HTML%

<input type="submit" value="Submit"> <p>

</FORM>

There are two other tokens that the dws will substitute for in a form.html. %DWS-HTTP-SERVER% and %DWS-HTTP-PORT% will expand to the IP address and port that the dws is listening on. This can be used to form A HREF= URLs that point to form.htmls from other packages on the dws.

The SDSI US and Canada form.htmls use this to form links to each other, so users can easily move from one to the other:

MIT distributes SDSI only to US citizens located in the United States,
or to Canadian citizens located in Canada.  This page is for the
United States.<p>

<h3>Click <a href="http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/sdsi-Canada/form.html">here</a> 
to see the page for Canada.</h3>

The Response Template - `response.html`

Each package directory has a response template file in it. This file has the name response.html and contains the HTML that is returned to a remote user when they have submitted a form to the dws that authorizes them to download the software.

This is the page that the users download the software from. The software tar files should all be made available as A HREF= URLs. These URLs must use tokens that the dws substitutes for, so that the final URLs that are served back to the user do point to your software, but are also temporary and unguessable.

The tokens that the dws substitutes for in a response.html are:

%DWS-HTTP-SERVER%
The IP address on the dws server the remote user connected to.
%DWS-HTTP-PORT%
The port the dws is listening on.
%DWS-DIR
The nonce and package directory for your software.

For example, this excerpt is from the sdsi-US package's form.html file, at /a/fredette/Work/dws/sdsi-US/form.html:

<UL>

<LI><A HREF=http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/%DWS-DIR%/sdsi20-0.3.0-mips-sgi-irix5.3.tar.gz>
sdsi20-0.3.0-mips-sgi-irix5.3.tar.gz</A>, 1495KB.

<LI><A HREF=http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/%DWS-DIR%/sdsi20-0.3.0-sparc-sun-sunos4.1.4.tar.gz>
sdsi20-0.3.0-sparc-sun-sunos4.1.4.tar.gz</A>, 1000KB.

<LI><A HREF=http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/%DWS-DIR%/sdsi20-0.3.0-sparc-sun-solaris2.5.1.tar.gz>
sdsi20-0.3.0-sparc-sun-solaris2.5.1.tar.gz</A>, 1155KB.

<LI><A HREF=http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/%DWS-DIR%/sdsi20-0.3.0-i386-pc-solaris2.5.tar.gz>
sdsi20-0.3.0-i386-pc-solaris2.5.tar.gz</A>, 1950KB.

<LI><A HREF=http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/%DWS-DIR%/sdsi20-0.3.0-i386-unknown-freebsd2.2.5.tar.gz>
sdsi20-0.3.0-i386-unknown-freebsd2.2.5.tar.gz</A>, 940KB.

<LI><A HREF=http://%DWS-HTTP-SERVER%:%DWS-HTTP-PORT%/%DWS-DIR%/sdsi20-0.1.0-i586-pc-linux-gnu.tar.gz>
sdsi20-0.1.0-i586-pc-linux-gnu.tar.gz</A>, 990KB. <I>Note that this is <b>not</b> current.</I>

<LI>
sdsi20-0.3.0-i386-unknown-netbsd1.1.tar.gz <I>(soon)</I>

</UL>
<P>

Note that the above URLs don't mention sdsi-US or sdsi-Canada; this is because the substitution for %DWS-DIR% includes the correct directory. This is what makes it possible to share a single response.html between a package's US and Canada directories.

Quick Instructions

These are quick instructions for preparing a package for the dws.

Make a world-readable directory somewhere in theory NFS space. This directory must not be available to the outside world already; that would defeat the purpose of the dws. (For example, if you're in CIS or TOC, your project probably already has a directory under /b/cis/WWW somewhere - making a new directory under there is wrong, since that directory will be served by the normal Web server on theory.)
The new directory you make will be your United States package directory, and its name preferably ends in -US, like sdsi-US does.

Make one or more tar files out of your software, compress them with gzip -9, and place them in the package directory.

Make a form.html in the package directory that is appropriate for distributing your software in the United States. Take /a/fredette/Work/dws/sdsi-US/form.html as an example, but remember that your software may not require some of the restrictions that SDSI does, and/or may require other restrictions that SDSI does not.

Make a response.html in the package directory that is appropriate for your software. Take /a/fredette/Work/dws/sdsi-US/response.html as an example.

Make sure the package directory and everything you have put in it is all world-readable.

You should make another package directory, alongside this US one, for Canada, although if you do not intend to make this software available to Canadians, you can skip this.
Package directories for Canada usually have names that end in -Canada. Make a form.html in this package directory that is appropriate for distributing your software to Canada. Take /a/fredette/Work/dws/sdsi-Canada/form.html as an example, but remember that your software may not require some of the restrictions that SDSI does, and/or may require other restrictions that SDSI does not.
Make symlinks (do man ln to learn how to make symlinks, which are also called "soft links") from this directory to everything in your United States package directory other than its form.html.

Mail fredette@theory.lcs.mit.edu with the fully-qualified names of your United States package directory and (if you made one) your Canada package directory.

My email response to you will include the URLs you should place in your project's home page that will bring users to the form.html for your package.

$Header$