DDTC and BIS have issued their respective proposed rules on “harmonizing” the definitions in the ITAR and EAR. Although there are numerous revisions to definitions of terms including the highly-anticipated cloud computing provisions, I certainly wouldn’t call this a harmonization of terms.
For example, BIS and DDTC still have separate terms for the following:
- Foreign Person vs. Foreign National
- Public Domain vs. Publicly Available
- Technical Data vs. Technology
There are, however, some very interesting bits in the rules. Below are my initial notes and highlights of important provisions in the proposed rules along with a very handy “Project Harmonization Chart”chart from BIS which shows comparable regulatory text side-by-side for convenience.
Don’t forget that comments to these rules must be submitted by August 3, 2015 so get reading!
Notes and Comments on Proposed Rules
Note: emphasis and highlighting is my own and not from the rules themselves. I’ve hopefully arrange the comments in such a way as to juxtapose similar concepts and highlight differences that still exist between the two agencies and their respective sets of regulations.
(ITAR) Public Domain
The Department proposes to revise the definition of “public domain” in ITAR § 120.11 in order to simplify, update, and introduce greater versatility into the definition. The existing version of ITAR § 120.11 relies on an enumerated list of circumstances through which “public domain” information might be published. The Department believes that this definition is unnecessarily limiting in scope and insufficiently flexible with respect to the continually evolving array of media, whether physical or electronic, through which information may be disseminated.
Paragraph (b) of the revised definition explicitly sets forth the Department’s requirement of authorization to release information into the “public domain.” Prior to making available “technical data” or software subject to the ITAR, the U.S. government must approve the release through one of the following: (1) The Department; (2) the Department of Defense’s Office of Security Review; (3) a relevant U.S. government contracting authority with authority to allow the “technical data” or software to be made available to the public, if one exists; or (4) another U.S. government official with authority to allow the “technical data” or software to be made available to the public.
Paragraph (a)(7) is added for the release of information to a public network, such as the Internet. This makes more explicit the existing control in (a)(4), which includes the publication of “technical data” to the Internet due to its inherent accessibility by foreign persons. This means that before posting information to the Internet, you should determine whether the information is “technical data.” You should review the USML, and if there is doubt about whether the information is “technical data,” you may request a commodity jurisdiction determination from the Department. If so, a license or other authorization, as described in § 120.11(b), will generally be required to post such “technical data” to the Internet. Posting “technical data” to the Internet without a Department or other authorization is a violation of the ITAR even absent specific knowledge that a foreign national will read the “technical data.”
(ITAR and EAR) Policy regarding determination of citizenship
Paragraph (b)(1) is added to clarify existing ITAR controls to explicitly state that disclosing “technical data” to a foreign person is deemed to be an “export” to all countries in which the foreign person has held citizenship or holds permanent residency.
Contrast this with the policy that BIS intends to codify – that when technology or source code is released to a foreign national, the export is “deemed” to occur to that person’s most recent country of citizenship or permanent residency.
(ITAR and EAR) Cloud storage provision
The Department also proposes to add a new provision excluding from ITAR licensing requirements the transmission and storage of encrypted “technical data” and software.
The Department recognizes that ITAR-controlled “technical data” may be electronically routed through foreign servers unbeknownst to the original sender. This presents a risk of unauthorized access and creates a potential for inadvertent ITAR violations. For example, email containing “technical data” may, without the knowledge of the sender, transit a foreign country’s Internet service infrastructure en route to its intended and authorized final destination. Any access to this data by a foreign person would constitute an unauthorized “export” under ITAR § 120.17. Another example is the use of mass data storage (i.e.,“cloud storage”). In this case, “technical data” intended to be resident in cloud storage may, without the knowledge of the sender, be physically stored on a server or servers located in a foreign country or multiple countries. Any access to this data, even if unintended by the sender, would constitute an “export” under ITAR § 120.17.
The intent of the proposed ITAR § 120.52(a)(4) is to clarify that when unclassified “technical data” transits through a foreign country’s Internet service infrastructure, a license or other approval is not mandated when such “technical data” is encrypted prior to leaving the sender’s facilities and remains encrypted until received by the intended recipient or retrieved by the sender, as in the case of remote storage. The encryption must be accomplished in a manner that is certified by the U.S. National Institute for Standards and Technology (NIST) as compliant with the Federal Information Processing Standards Publication 140-2 (FIPS 140-2). Additionally, the Department proposes that the electronic storage abroad of “technical data” that has been similarly encrypted would not require an authorization, so long as it is not stored in a § 126.1 country or in the Russian Federation . This will allow for cloud storage of encrypted data in foreign countries, so long as the “technical data” remains continuously encrypted while outside of the United States.
(EAR) Encrypted technology and SW
Paragraph (a)(4) establishes a specific carve-out from the definition of “export” the transfer of technology and software that is encrypted in a manner described in the proposed section. Encrypted information—i.e., information that is not in “clear text”—is not readable, and is therefore useless to unauthorized parties unless and until it is decrypted. As a result, its transfer in encrypted form consistent with the requirements of paragraph (a)(4) poses no threat to national security or other reasons for control and does not constitute an “actual” transmission of “technology” or “software.” Currently, neither the EAR nor the ITAR makes any distinction between encrypted and unencrypted transfers of technology or software for control or definitional purposes. [Although this may come as a surprise to some it is not new!]
The intent of this requirement is that relevant technology or software is encrypted by the originator and remains encrypted (and thus not readable) until it is decrypted by its intended recipient. Such technology or software would remain encrypted at every point in transit or in storage after it was encrypted by the originator until it was decrypted by the recipient.
BIS understands that end-to-end encryption is not used in all commercial situations, particularly when encryption is provided by third party digital service providers such as cloud SaaS (software as a service) providers and some email services. However, in many such situations, technology or software may be encrypted and decrypted many times before it is finally decrypted and read by the intended recipient. At these points, it is in clear text and is vulnerable to unauthorized release. BIS considered this an unacceptable risk and therefore specified the use of end-to-end encryption as part of the proposed definition. A key requirement of the end-to-end provision is to ensure that no non-US national employee of a domestic cloud service provider or foreign digital third party or cloud service provider can get access to controlled technology or software in unencrypted form .
What type of encryption needs to be used?
FIPS 140-2 is a well understood cryptographic standard used for Federal Government procurement in the United States and Canada, as well as for many other uses, both in the United States and abroad. However, BIS understands that companies may use hardware and software that has not been certified by NIST or that does not conform to NIST guidelines (e.g., for internal use or conforming to other standards). To accommodate this, this paragraph allows for use of “similarly effective cryptographic means,” meaning that alternative approaches are allowable provided that they work. In such cases, the exporter is responsible for ensuring that they work. In contrast, the corresponding definition proposed by DDTC makes FIPS 140-2 conformity a baseline requirement. Hardware and software modules must be certified by NIST, and NIST key management and other implementation standards must be used. Alternatives are not permitted regardless of effectiveness.
Some notes for exporters regarding FIPS 140-2
It’s hard to determine exactly which algorithms are supported in the FIPS 140-2 standard. One must pay attention to the way the algorithms are implemented and various other requirements including the oft-overlooked fact that the underlying symmetric key (DES, AES) used in a secure connection (SSL, TLS) must be encrypted by a public key (RSA) of equal or greater bit strength. Here is a very nice blog post called FIPS 140-2 for Mere Mortals which is very informative.
Basically, the following are approved cryptographic functions under FIPS 140-2:
- Symmetric Key: AES, TDEA, and EES
- Asymmetric Key: DSS (DSA, RSA, and ECDSA)
And here are the allowed algorithms along with the RSA bit length needed to provide enough strength for encapsulation (credit to Archimedes Newton)
- 2TDEA (112-bit DES) – RSA key length of 1024 bits – overall security strength of 80 bits
- 3TDEA (168-bit DES) – RSA key length of 2048 bits – overall security strength of 112 bits
- AES-128 – RSA key length of 3072 bits – overall security strength of 128 bits
- AES-256 – RSA key length of 15360 bits – overall security strength of 256 bits
(EAR) Releasing the means to access the encrypted data constitutes an export
Paragraph (a)(6) defines as an export the release or other transfer of the means of access to encrypted data. This is intended to complement the exclusion of certain encrypted data from the definition of export, specified in proposed § 734.18(a)(4) and discussed below. Logically, providing the means to decrypt or otherwise access controlled technology or software that is encrypted should constitute a controlled event to the same extent as releasing or otherwise transferring the unencrypted controlled technology or software itself. Upon transfer of the means of access to encrypted technology or software, the technology or software would acquire the classification and control status of the underlying technology or software, as specified in proposed § 764.2(l). The meaning of “clear text” in the proposed definition is no different than an industry standard definition, e.g.,information or software that is readable without any additional processing and is not encrypted. Comments are encouraged regarding whether a specific EAR definition of the term is warranted and, if so, what the definition should be.
Note that this includes the transfer of:
- cryptographic keys
- network access codes
- any other information that the exporter “knows” would result in the unauthorized transfer of controlled technology
(ITAR and EAR) Physical access to unsecured tech data
In the proposed rule, BIS states that merely providing physical access to unsecured ITAR tech data is controlled; merely providing physical access to unsecured EAR technology is not unless you know that doing so will cause or permit the transfer of controlled “technology” in clear text or “software” to a foreign national.
(EAR) Release and “visual inspection”
The new definition notes that “visual inspection” must actually reveal controlled technology or source code to be a release of technology or technical data. Merely seeing an item briefly is not necessarily sufficient to constitute a release of the technology required, for example, to develop or produce it. This fits with the DDTC definition of release which refers to “allowing a foreign person to inspect a “defense article” in a way that reveals “technical data” to the foreign persons.”
Peculiarly responsible; a new “catch-and-release” definition
This rulemaking proposes a definition of the currently undefined term “peculiarly responsible” in order to respond to common industry questions. The new definition would be modeled on the catch-and-release structure BIS adopted for the definition of “specially designed.” Thus, under the proposed definition, an item is “peculiarly responsible” for achieving or exceeding any referenced controlled performance levels, characteristics, or functions if it is used in “development,” “production,” “use,” operation, installation, maintenance, repair, overhaul, or refurbishing of an item subject to the EAR unless (a) the Department of Commerce has determined otherwise in a commodity classification determination, (b) it is identical to information used in or with a commodity or software that is or was in production and is EAR99 or described in an ECCN controlled only for Anti-Terrorism (AT) reasons, (c) it was or is being developed for use in or with general purpose commodities or software, or (d) it was or is being developed with “knowledge” that it would be for use in or with commodities or software described (i) in an ECCN controlled for AT-only reasons and also EAR99 commodities or software or (ii) exclusively for use in or with EAR99 commodities or software.
DDTC is asking for comment on the following:
- How adequately the proposed regulations address the technical aspects of data transmission and storage
- Whether the proposed regulations mitigate unintended or unauthorized access to transmitted or stored data
- Whether the proposed regulations impose an undue financial or compliance burden on the public
- Whether having only a 30-day delayed effective date instead of the typical six-month delayed effective date as with other ECR rules causes a problem for exporters
BIS is asking for comment on the following:
- Whether the revisions proposed in this rulemaking create gaps, overlaps, or contradictions between the EAR and the ITAR, or among various provisions within the EAR
- Whether the alternative definition of fundamental research suggested in the preamble should be adopted (note to reader, the alternative definition would read: “`Fundamental research’ means non-proprietary research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community.”)
- Whether the alternative definition of applied research suggested in the preamble should be adopted, or whether basic and applied research definitions are needed given that they are subsumed by fundamental research (note to reader, the alternative definition would read: “Systematic study to gain knowledge or understanding necessary to determine the means by which a recognized and specific need may be met”)
- Whether the questions and answers in existing Supplement No. 1 to part 734 proposed to be removed by this rulemaking have criteria that should be retained in part 734
- With respect to end-to-end encryption described in the proposed revision of the definition of “Activities that are Not Exports, Reexports, or Transfers,” whether the illustrative standard proposed in the EAR rulemaking also should be adopted in the ITAR rulemaking; whether the safe harbor standard proposed in the ITAR rulemaking also should be adopted in the EAR rulemaking; or whether the two bodies of regulations should have different standards
- Whether encryption standards adequately address data storage and transmission issues with respect to export controls
- Whether the proposed definition of “peculiarly responsible” effectively explains how items may be “required” or “specially designed” for particular functions
Lastly, here’s that side-by-side comparison of the regulatory text proposed by both Departments.