Skip to main content

Commerce Department FAQ on Proposed Wassenaar Implementation Gives Answers, Raises More Questions

DEEPLINKS BLOG
June 12, 2015

Commerce Department FAQ on Proposed Wassenaar Implementation Gives Answers, Raises More Questions

Confusion over the Department of Commerce’s proposed implementation of the latest changes to the Wassenaar Arrangement’s export controls continues. For those of you who are new to the debate over Wassenaar and would like to know just what it is and why you might care about it, click here for our earlier analysis.

The good news is that in an FAQ it released earlier this week, the Department of Commerce’s Bureau of Industry and Security (BIS) has directly addressed some of the concerns we brought up in our previous blog post. For example, in response to our concern that the proposed rules don’t incorporate the exemptions for "technology" "in the public domain" for "basic scientific research" and for the minimum necessary information for patent applications laid out in the Wassenaar Arrangement’s “General Technology Note” (GTN), FAQ 9 states:

Would ECCN 4E001.c be covered by the General Technology Note?

Yes. Per the advisory opinion issued by BIS on 3/25/14, the GTN applies to all ECCNs controlling ''technology," regardless of whether the ECCN specifically refers to the GTN or uses the term "required."

We’re glad to see some clarity here. But this is where the clarity ends. If anything, the FAQ raises more questions than answers.

Now that we know that the GTN exemption applies to the BIS proposal, what about the more important exemptions in the General Software Note (GSN)? While the GTN makes clear that “public domain” technology isn’t controlled, it’s the GSN that specifies that software that’s generally available to the public for use without substantial support is similarly free from control. Jailbreaking tools are a great example of software that might otherwise be controlled by Wassenaar, but that clearly falls within the GSN. But because jailbreaking tools aren’t necessarily within the “public domain,” they wouldn’t necessarily be exempt from the BIS proposal, even though they aren’t controlled by Wassenaar.

FAQ 7 fails to address the question it is ostensibly trying to answer.

Will companies be required to share their zero-day exploits with the government in order to get a license?

The rule states that when an export license application is filed, BIS can request a copy of the part of the software or source code that implements the controlled cybersecurity functionality.

Note that BIS can already request this information as part of a commodity classification request or license application for items in Category 5 Part 2 with encryption functionality. Thus, any existing tools with encryption or cryptanalysis capabilities are already subject to similar provisions.

We are aware that many of the tools that are potentially controlled by this proposal employ encryption functionality and are already subject to export regulations. However, this is not true of all such tools. We would like for BIS to clarify whether or not the exporters of tools without encryption functionality will be required to share with the government the code that implements an exploit.

FAQ 5 and 6 address concerns about the impact of the proposed rules on publicly-available research and public disclosure.

Doesn’t the rule expose researchers to criminal prosecution if they carry information on exploits to a public conference, unless they publish it before the conference?

Under Section 734.7 of the EAR, information that is published, or released at an open conference, is not subject to the EAR. That section also specifies that it would not be an export to transfer the technical data to conference organizers with the intent that it will be published at the conference.

BIS welcomes comments on whether further clarification is needed on when information potentially subject to these rules would be considered "publicly available" and not subject to the EAR.

And

Doesn’t the rule make it easier for researchers to provide exploitable bugs to their government then to publish an exploit in order to fix and alert the world of the problem?

Under Section 734.7, there are no restraints on publishing information otherwise subject to control, and no prior authorization from BIS is required. Once the information is published it is not subject to the EAR. Thus any information that is published is completely outside the scope of the EAR and the provisions of the proposed rule.

We are cautiously optimistic about this language, but we feel it ignores the reality of the way in which security research is carried out today. Many of the vulnerabilities which are reported to vendors are never made public, or only partially so. We would very much like for BIS to clarify whether or not an exploitable vulnerability reported to a vendor who intends to patch but not disclose would be covered by the proposed regulations.

Last, but certainly not least, the FAQ appears to contradict itself. For example, FAQ 10 clarifies that a researcher who has written a proof of concept for a vulnerability, “code that takes advantage of the vulnerability,” would not be required to obtain a license before submitting the proof of concept to the vendor. But back up in FAQ 4, BIS told us that “information on how to prepare the exploit for delivery” is controlled. We’re confused as to how a researcher could submit a functional proof of concept that FAQ 10 told us was kosher without violating the restriction from FAQ 4.

To supplement this FAQ, BIS will be holding an Export Control Reform conference call on June 17, 2015 on “Intrusion and Surveillance Items Proposed Rule (Cyber Rule) for Implementation of the Wassenaar Arrangement 2013 Plenary Agreements.” The stated purpose of the call is to address “possible misconceptions regarding the proposed rule” and answer written questions (submitted beforehand) to ecrweekly@bis.doc.gov. Rest assured, EFF will submit the questions that we feel are most pressing and we’ll be on the line to see how BIS responds. We encourage interested members of the community to submit their questions, join the call with us, and stay engaged in the rulemaking process.

Back to top

JavaScript license information