This is a relatively simple decision path, as export decisions go. Let's go over it step by step.
First, this DNS Security software only authenticates information, rather than hiding it. This happens naturally, because the DNS Security protocols are designed to authenticate, rather than to hide, information. The result, as far as the export controls are concerned, is that the software is exempt from the draconian "Encryption Item" (EI) controls. It is also exempt from the remaining "encryption software" controls that existed before the EI controls were imposed. See note to ECCN 5A002, f. and g.
Now, one could argue that this authentication software could be modified by someone, somewhere, to use encryption for privacy, making it subject to all the nasty controls above. That's true. But the fundamental principle on which this export classification is based is that the literal function of the application -- its intended design -- determines whether it's classified as authentication or not. Any program, whether it contained crypto or not, could be modified by a recipient to add encryption features. That's not the issue; the issue is whether it encrypts for privacy as exported.
Second, because this software is not under "EI" controls, it qualifies for exemption from the entire export control regime, because it is publicly available. Section 732.2 of the Export Administration Regulations (EAR) says how to determine whether your export is "subject to the EAR". It says:
Sec. 732.2 Steps regarding scope of the EAR.
Steps 1 through 6 aid you in determining the scope of the EAR.
...
(b) Step 2: Publicly available technology and software. This step is
relevant for both exports and reexports. Determine if your technology or
software is publicly available as defined and explained at part 734 of
the EAR. Supplement No. 1 to part 734 of the EAR contains several
practical examples describing publicly available technology and software
that is outside the scope of the EAR. The examples are illustrative, not
comprehensive. Note that encryption software controlled for EI reasons
under ECCN 5D002 on the Commerce Control List (refer to Supplement No.1
to part 774 of the EAR) shall be subject to the EAR even if publicly
available. Accordingly, the provisions of the EAR concerning the public
availability of items are not applicable to encryption items controlled
for ``EI'' reasons under ECCN 5D002.
(1) If your technology or software is publicly available, and
therefore outside the scope of the EAR, you may proceed with the export
or reexport. You have no obligations under the EAR and need not comply
with the EAR. You may skip the remaining steps.
Our software is publicly available, and is not controlled for EI reasons;
in fact it is not
controlled at all by ECCN 5D002.
Therefore it is outside the scope of the EAR, and
we "have no obligations under the EAR and need not comply
with the EAR."
TIS then submitted the same source-code prototype to the Commerce Department for a Commodity Determination on August 26, 1996, to see what controls might apply to it there. The September 17 Commerce Department response concluded that the item was eligible for the "General Software Note" (GSN). This Note permits free export to virtually any location of software that is available in the mass-market or is "public domain" (available to the public). (TIS got a second identical response a day later, listing a different Division Director, for some administrative reason.)
This permitted TIS to put their prototype implementation up for downloading by anyone outside of Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria (and also resulted in a handsome T-shirt). Here is the announcement of the exportability of the TIS release.
Therefore, we integrated the RSAREF cryptography library into a new prototype DNSSEC release. This release includes the full source code of the TIS DNS Security version of BIND, and the full source code of the RSAREF cryptographic library. All this source code is unmodified, except for small changes in the Makefiles to make them build together. The result is a single distribution which provides complete source code for authenticated domain name services.
Hugh Daniel and his lawyer Lee Tien submitted his December 15, 1996 CJ Request for the ``Integrated'' release, to the State Department.
At that time, the State Department had just learned that its export-control regime was unconstitutional, so it replied with a cover letter and a Returned Without Action note, suggesting that we re-apply to the Commerce Department, which was in the process of picking up full responsibility for the crypto export controls.
Hugh and Lee therefore submitted their April 25, 1997 Classification Request to the Commerce Department (along with an 8-page explanatory letter), again for the ``Integrated'' release. The June 4, 1997 Commerce Dept response gives the software a classification of "EAR99". The note on the back says, "For items classified EAR99, see part 746 of the EAR to determine the licensing requirements." As explained in another document from the Commerce Dept, ``...EAR99. If this item is `publicly available' within the meaning of section 734.3 of the EAR, whether or not in electronic media described in the Notes in paragraphs (b)(2) and (b)(3) following section 734.3 of the EAR, then it is not subject to the EAR.''
Many people in the export-control world are shocked and amazed that the full source code for publicly available authentication applications is exportable. They've probably been listening to NSA. The agency is famous for "informal" advice containing self-serving lies about just what the export controls control. If you want to know what the export controls really control, make a formal request to the agency that interprets the controls (at this point the Commerce Dept), or ask a Federal court. We not only read the regulations themselves, which say that authentication is exportable, and that publicly available authentication is not even "subject to the EAR"; we also formally asked those same questions of the Government, and got the answers that match our understanding of the regulations.
Initially it worked fine. The BXA produced a decision that was in line with their regulations, as documented in the paperwork linked above. But then when Phil Karn pointed out to them in court that this code was exportable and yet very similar to his non-exporable code, BXA was faced with a dilemma. Either it had to admit to the judge that having this code get outside the country wasn't really that big a threat to the national security, or it had to produce an export control decision that didn't actually agree with the published regulations. Even a novice BXA watcher can predict the outcome of that calculation. They sent a letter "retracting" their earlier classification and reclassifying the software as un-exportable because "with minimal effort" it can be modified to something unexportable. This is a concept wholly strange to the regulations.
We appealed that new determination and held a hearing on it in Washington. The 1998-1999 documents in the page above bring out the issues involved.
How did it all come out? As I write this paragraph in 2009, I don't recall. Perhaps it was still pending when the government lost the Bernstein case and appeal, and had to revise the export controls to take account of the First Amendment. In the long run, DNS Security is finally being deployed on a medium scale in 2009 -- ten years later. It wasn't just the export controls that slowed it down, though they were certainly a factor. The DNS Security software in BIND was revised or rewritten several times for reliability and operational simplicity. Also, its protocols were redesigned a few times by the IETF after various operational problems surfaced. I have been told that all the crypto code that was at issue during these hearings has been ripped out of the code a long time ago, and replaced (after RSA's patents expired) by cleaner code that came without the significant restrictions that RSA's licensing had imposed.
My latest advice on export is to have a good lawyer read the regulations. Craft a course for your project or business that involves not breaking the laws or regulations. Get an opinion of counsel that your course is legal. Then follow it. Without notifying the Commerce Dept. Talking with them just encourages them to slap you down without warning or justification. The system is set up to avoid their decisions being subjected to any kind of examination by a competent judge (e.g. for compliance with their own regulations).
