Comment on the Interim Rule, Encryption Regulations
Published on January 14, 2000
Frank J. Ruggiero
of Export Administration
Street and Pennsylvania Avenue, N.W.
United States Council for International Business (USCIB)
appreciates the opportunity to comment on the Interim Rule, Encryption
Regulations published on January 14, 2000. The USCIB is encouraged by the trend toward a more liberal
policy for the export of encryption technologies. The access to robust cryptography to ensure the security
of business information and information that relates to a business' customers
is essential to the continued growth of electronic commerce and its resulting
benefits to society and the global economy.
expressed in previous submissions, USCIB members believe that the marketplace
should define the types and strengths of encryption technologies that users
access; business and end-users should be able to choose the cryptographic
systems and products that best suit their needs. The Interim Rule is a significant step forward in
achieving that objective.
USCIB members would like to address several outstanding issues in the Interim
Rule that may put U.S. companies at a competitive disadvantage vis-à-vis
their foreign counterparts. Most
notably, the costs that businesses will incur to comply with the often
complex procedures set forth in the Interim Rule will decrease the
competitiveness of U.S. suppliers.
specific are set forth below.
The January 14,
2000 Interim Final Rule adds unnecessary layers of complexity. The unnecessary complexity is
confusing, costly, more difficult than need be, and is inconsistent with the
general objective of the revisions namely, to make 'retail,' 'mass market'
and other forms of encryption products uniformly exportable to almost all
end-users in all destinations, save restrictions on terrorist supporting
states. An example of the
unnecessary complexity is that there are at least thirteen categories of
encryption items, some with sub-categories and each having unique rules.
ITEM (EI) CONTROLS
The Interim Rule makes progress by
releasing certain categories of encryption products from EI controls
mass market encryption
commodities, software up to and including 64-bits after review and
unrestricted encryption source
code not subject to an express agreement for the payment of a licensing fee
or royalty for commercial production or sale of any product developed using
the source code without review; and
certain encryption items exported
and reexported to foreign subsidiaries of U.S. companies without technical
review and classification;
As stated, this
is good progress. Nevertheless,
USCIB members believe that this progress could be greatly improved and the
regulations could be simplified if EI-controls from encryption items that are
generally exportable were eliminated.
At a minimum, USCIB members urge the Department of Commerce to
eliminate all EI-controls on all “retail” encryption products. Again, such controls are unrealistic
and inconsistent with the general intent of the revised regulations and other
provisions of the revised regulations that permit the export of retail
encryption items to most destinations.
encourage the U.S. Government to take the following steps in conjunction with
the elimination of certain EI controls:
A. De Minimis Content
Interim Rule, EI-controlled software is not eligible for de minimis
exceptions. Maintaining EI
controls on greater than 64-bit software could make it impossible for U.S.
manufacturers to supply their products to foreign manufacturers for
incorporation into foreign products.
This will force companies to continue to produce dual versions of
products – one weak encryption version that can be free of EI-controls and one
strong encryption version. This
will likely lead foreign manufacturers to "design out" U.S. origin
components where an EI control creates risk to the foreign manufacturer due
to licensing or other review requirements or where the foreign manufacturer is
unwilling to accept a weaker version of the product to comply with U.S.
rules. Such "design
outs" would significantly impair the competitiveness of U.S. providers
in foreign markets. Therefore,
USCIB members recommend thatSection 734.4(b)(2) be eliminated, and
734.4(h) be amended to reflect that deletion. At a minimum, these paragraphs should be amended to
apply only to “non-retail” EI controlled items.
B. Publicly Available Software
734.3(b)(3) – Virtually all "publicly available software" qualifies
as "retail commodities software" and, therefore, is exportable to
virtually any end-user in all destinations. Moreover, such software is normally distributed via free
or anonymous Internet download and would be exempt from reporting requirements
under the draft regulations. The
exclusion for EI-controlled software from the “publicly available” exception
is inconsistent with other provisions of the Interim Rule and with actual
practice and should therefore be eliminated.
Section 734.7(c) – the exclusion for EI-controlled software from the
“published information and software” rule – should be eliminated. This paragraph (c) was newly added by
the January 14 Rule to make it clear that software controlled under ECCN
5D002 for “EI” reasons remains subject to the EAR even if it is “published”
as defined in paragraphs (a) and (b) of that section. This paragraph should be deleted and
it should be made clear that “published” encryption software of any key
length is not subject to the EAR.
The Interim Rule has been
effective since January 14, 2000.
This has given industry approximately 4 months to assess the
application of the Rule by government agencies in actual practice. Our members have raised several
concerns about the application of the Interim Rule in practice. Classification requests for retail
encryption products are routinely taking much longer than the 30 days
specified in Supplement 6 to Part 742.
More importantly, restrictive interpretations of the regulations are
contrary to the spirit of the promised liberalization and the understanding
that industry had with respect to the new rules. And, in some cases, such interpretations are contrary to
the black letter of the regulations.
example, Section 740.17(d) of the regulations states:
products developed with or incorporating U.S.-origin encryption source code,
components or toolkits remain subject to the EAR, but do not require review
and classification by BXA and can be exported or reexported without further
clear statement, which on its face exempts review and classification, is
being applied in a way that continues to require such review and
classification of all foreign produced cryptographic modules that are
designed to work with closed CAPIs and that have been developed using U.S.
It has been suggested that to
exclude such foreign-produced modules from review would, in effect, make a
closed CAPI an "open cryptographic interface." But that is
not the case. "Open cryptographic interface" is
defined in the regulations as:
mechanism which is designed to allow a customer or other party to insert
cryptographic functionality without the intervention, help or assistance of
the manufacturer or its agents, e.g., manufacturer's signing of cryptographic
code or proprietary interfaces."
But regardless of whether the
U.S. government reviews the cryptographic module, a closed CAPI is still a
mechanism that requires the intervention of the manufacturer (e.g. digitally
signing the code or a hash of the code). So despite the fact that the
January 14 regulations do not give the U.S. government the authority to
review foreign developed cryptographic modules, BXA continues to require such
One of the stated
goals of the Interim Final Rule is to streamline reporting requirements and
in fact, it has made significant progress toward achieving that goal.
Nevertheless, our members have noted with concern that the reporting
requirements as set forth in the Interim Rule remain overly complex and
burdensome, present difficult questions regarding actual practice, and do not
appear to serve any government purpose.
Several particular concerns expressed by our members are set forth
Interim Rule requires reporting of sales of ‘retail’ products to
"Retail" products are sold to both individuals and
non-individuals/businesses. Often, a U.S. merchant that electronically
transmits "retail" products will not know if the end-user is
selling the product to the purchaser in his/her individual or
Therefore, to ensure compliance with this requirement, U.S. merchants
will, in practice, "over-report" their exports. Given the requirement of one-time
review, reporting of retail type products seems to add no value. For example,
both the Netscape Navigator web browser and the Internet Explorer component
of the Windows operating system have been distributed in quantities greater
than the total number of Internet users – so it is safe to assume that
virtually every user has both. However, reporting will not reveal what
software is actually being used by which user.
companies routinely purchase and use several competing products. For example, over 90% of the largest
e-commerce companies run both Oracle and Microsoft SQL servers. The reporting, however, would not
reveal how, and to what extent, each product is actually deployed. The reporting would tell the government,
that for any particular deployment, there would be either an Oracle server, a
Microsoft SQL server, or both.
But the same assumption could be made without any reporting
vast majority of commercial products now use standard security
protocols. So, it is unclear
what is gained by the knowledge that Company X is using SSL for web security
and S/MIME for secure e-mail, since virtually every company is using SSL for
web security and S/MIME for secure e-mail.
the Wassenaar Arrangement – a multilateral export control regime based on
national discretion licensing by each member country – does not require
reporting for any strong encryption exports. Prior to December 1998, the Wassenaar Arrangement did
include reporting requirements for the very small class of encryption
products that did not meet the GSN definitions of mass-market or
public domain. In December 1998,
however, encryption items were removed from the “Sensitive List”, thereby
removing reporting requirements for even non-mass-market encryption products. It is particularly troubling that the
U.S. Government agreed to eliminate all requirements for our foreign
competitors to report exports of any encryption products, while maintaining
burdensome reporting requirements on U.S. companies.
the reporting requirements are overly burdensome; offer the U.S. Government
little, if any, useful information about what, how, and the extent to which
strong encryption software is actually being used around the world; and will
put U.S. companies at a competitive disadvantage in relation to their foreign
Interim Rule is a significant step forward in implementing the Clinton
Administration's encryption policy announced on September 16, 1999 and USCIB
members appreciate that progress.
Nevertheless, the comments above clearly demonstrate that the Interim
Rule will continue to place U.S. merchants at a competitive disadvantage
vis-à-vis their foreign counterparts.
thank you for the opportunity to comment on the Interim Rule. We look forward to continuing our
dialogue with you on this important issue.
Information Policy Committee
members have identified the following categories: (1) authentication-only
products; (2) mass-market products up
to 64 bits; (3) non-mass-market products up to 56 bits, with key
exchange up to 512 bits; (4) other cryptography products (over
64-bits for mass-market, or over 56-bits for non-mass-market) classified as
“retail,”; (5) other cryptography products (over 64-bits for
mass-market, or over 56-bits for non-mass-market) classified as “non-retail”
– including network infrastructure products such as high end routers or
switches designed for large volume communications; customized encryption
products; encryption products that require substantial support for
installation and use; products with encryption that is easily modified by the
key management products up to 512 bits; (7) key management products greater than
512 bits; (8) components (chips, toolkits) up to 56 bits; (9)
components (chips, toolkits) greater than 56 bits; (10) general purpose
toolkits; (11) publicly available, unrestricted source code; (12)
publicly available, restricted source code; and (13) non-publicly available