Handling Cryptography within an ASF Release

Purpose and Intended Audience

Overview

Notification of Updates to this Page

Section 740.13(e) of the Export Administration Regulations (EAR) authorizes exports and reexports, without review, of encryption source and object code provided the following conditions are met:

• the code is controlled by ECCN 5D002
• the code will be publicly available
• a notification is sent to the U.S. Government's Bureau of Industry and Security (BIS) at or before making the code publicly available

Current ASF processes satisfy the "publicly available" requirement. The notification requirement is described below. However, the important part of this step is to ensure the included cryptographic functionality meets the definition of ECCN 5D002, which can be summarized as:

• Software specially designed or modified for the development, production or use of any of the other software of this list, or software designed to certify other software on this list; or
• Software using a "symmetric algorithm" employing a key length in excess of 56-bits; or
• Software using an "asymmetric algorithm" where the security of the algorithm is based on: factorization of integers in excess of 512 bits (e.g., RSA), computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
• Software designed or modified to perform cryptanalytic functions

If the cryptographic functionality is limited to one of the above definitions, it should be classified as ECCN 5D002, and the remaining two steps should be taken (described below). If the release may contain cryptographic functionality beyond what is described above, please contact the ASF Vice President for Legal Affairs.

To satisfy the BIS requirements to make source code available for inspection, while minimizing the number of notification emails needed to be sent, the ASF maintains a single web page at http://www.apache.org/licenses/exports/ with links to the applicable source code for each version of each ASF product classified as ECCN 5D002.

To make updates to this ASF-wide Exports page as simple and consistent as possible, the source XML page contains a list of XML trees under eccnmatrix that can be edited by anyone with site-dev karma (which includes all of the PMC chairs). Note that the exports web page is generated from the XML just like the rest of site by running Anakia via the build script in the top-level directory.

Any edits to the exports page should be tested using both the site build process (view the index.html before committing any changes) and by running the bisnotice.xsl transform on the product added/changed (see below). You can probably figure out what the content of the XML fields should be by following the example of other projects and reading the page. If you have any further questions about the content, or if you are not sure that a BIS notice is required, please check the FAQs first and then bring any remaining questions to the legal-discuss mailing list. Note that the product data should only be version-specific if the classification changes (e.g., Apache HTTP Server version 1.3 vs 2.0) or if the link to the controlled source code needs to change, such as if the encryption library included in the product for different releases came from different manufacturers. In addition, note that it is possible to include both controlled and non-controlled (ECCN "n/a") products in the list, but a BIS notice is only necessary for the products that have at least one version classified as 5D002.

After ensuring the distribution's cryptography qualifies for the TSU exception and after ensuring the applicable source code is linked from the ASF-wide export page, but before publicly posting the distribution or committing the controlled code, send an email using the template below.

An XSLT transformer called bisnotice.xsl has also been provided to generate the BIS notice for a product based on the XML data. For example, running it as:

  cd {SVNROOT}/infrastructure/site/trunk/
  svn up
  cd xdocs/licenses/exports/
  java org.apache.xalan.xslt.Process -in index.xml -xsl bisnotice.xsl \
    -param product 'Apache HTTP Server'
  

will result in text output that looks like an email template for the PMC chair to send to the appropriate addresses. A generic example is provided below. Note that the product parameter selects which product(s) to print based on matching a substring of the product name. The template output is only correct when a single product is matched.

   TO: crypt AT bis.doc.gov, 
       enc AT nsa.gov, 
       web_site AT bis.doc.gov
   CC: {applicable project list}, 
       {legal-archive AT a.o}  
   SUBJ: TSU NOTIFICATION - Encryption
   -------------------------------------------------------
   SUBMISSION TYPE:      TSU

   SUBMITTED BY:         {PMC member sending email}

   SUBMITTED FOR:        Apache Software Foundation

   POINT OF CONTACT:     Secretary, Apache Software Foundation

   FAX:                  +1-919-573-9199

   MANUFACTURER(S)       {list of origin of all crypto code, e.g.
                         "OpenSSL Project" or "Apache Software Foundation."
                         If product includes multiple crypto items from 
                         different origins, list all origins.}

   PRODUCT NAME/MODEL #: {Apache product name(s) that include the source
                          code found at the URL below, or any binaries
                          that were created by compiling that source code
                          -- do not specify version numbers if the 
                          future versions will use source code found at 
                          the same URL (even if the source is updated at
                          that URL) }

   ECCN:                 5D002

   NOTIFICATION:         http://www.apache.org/licenses/exports/
   

Should the software qualify for the TSU exception, the notice below should be placed into each distribution's README file.

   This distribution includes cryptographic software.  The country in 
   which you currently reside may have restrictions on the import, 
   possession, use, and/or re-export to another country, of 
   encryption software.  BEFORE using any encryption software, please 
   check your country's laws, regulations and policies concerning the
   import, possession, or use, and re-export of encryption software, to 
   see if this is permitted.  See <http://www.wassenaar.org/> for more
   information.

   The U.S. Government Department of Commerce, Bureau of Industry and
   Security (BIS), has classified this software as Export Commodity 
   Control Number (ECCN) 5D002.C.1, which includes information security
   software using or performing cryptographic functions with asymmetric
   algorithms.  The form and manner of this Apache Software Foundation
   distribution makes it eligible for export under the License Exception
   ENC Technology Software Unrestricted (TSU) exception (see the BIS 
   Export Administration Regulations, Section 740.13) for both object 
   code and source code.

   The following provides more details on the included cryptographic
   software:
   ...
   

Be sure to add some information at the bottom of the notice about the components of the release including cryptography.

What is the "PRODUCT NAME/MODEL #" for my product?

What is the MANUFACTURER?

What is the NOTIFICATION?

When is the first time a notification email must be sent?

What are examples of when a crypto item is publicly accessible through ASF servers?

Are public contributions of crypto items to the mailing list, JIRA or Bugzilla databases considered exports?

If we distribute previously exported crypto items, must we still qualify the same item for export?

If the ASF distributes a particular crypto item within one product under the TSU exception, must the same item requalify for the TSU exception when distributed in a different ASF product?

If the ASF distributes/exports a crypto item after qualifying it under the TSU exception, must the same product requalify for release of future versions?

Where must the email's notification URL point to?

If the notification URL never changes, when are additional notification emails required?

Is there any BIS requirement to tell users and/or redistributors of our products about the crypto within our products?

When exporting a product that is not only designed to use some third-party crypto item, but also includes the third-party crypto item, does this require two notifications or one notification with two manufacturers?

Can the ultimate link to the crypto item's source code point to a non-ASF web page?

What if the object/binary code being distributed was built with a particular compiler switch?

Do we ever need to notify the BIS of the location of object/binary files?

If my project ships a binary that includes libssl/libcrypto, what notifications must be made?

If my project ships a binary that provides bindings to OpenSSL, but does not include its source or binaries, what notifications must be made?

Isn't it somewhat weird that I, who am not a U.S. citizen nor resident, should be constrained as to what or how I can commit to an ASF repository by some U.S. law?

Do digest algorithms such as MD5 and SHA1 require notification?