I'd like to get an FAQ together that covers the key Q&As that came up during the ApacheCon BOF last week. To aid my memory of the event (wish we would have taken notes during the BOF to go straight to the list), Bill suggested I start with a list of the Q&As that I've had with BIS, many of which came up during the BOF. Please jump in with comments or questions to add. I'll add the result of this thread to the dev/crypto.html page shortly.
Note that no of this can be considered official BIS positions, but these most of these answers did come from an engineer in the part of the Washington D.C. admin office that concentrates on crypto issues (outside of this office, very few BIS folks really understand the crypto issues). I've also thrown in a couple questions that I've seen come up on ASF lists that are clearly answered by the EAR. Once we've locked down how we want to do things and have run out of Q&As, I'll discuss with our counsel which subset of those we want to get a formal answer on and get that process started. However, I'm not implying that anything should be held up while we do this -- let's keep things moving based on what we know now. Finally, please note that Q&A 1&2 is something I only recently became aware of -- we've obviously not complied with this in the past, but there are several things we haven't done perfectly. Let's just get it right now and not worry about our past unintentional flaws. Also, Q&A 7, does not say that we are required to notify BIS of any substantial change in crypto functionality -- only when the manufacturer of the crypto changes. Some folks have told me they thought there was a requirement to notify when there is a substantial change in functionality, but I believe that no longer applies if the URL is still correct. I've stated this to a BIS engineer, and he couldn't point to anything refuting my claim. Q1. When is the first time a notification email must be sent? A1. Prior to exporting. NOTE: this even includes distribution of code through publicly accessible servers/repositories before there has been any official release. Q2. What are examples of when a crypto item is publicly accessible through ASF servers? A2. The obvious example is including something like OpenSSL within a product distribution from a /dist URL. *The less obvious example*, is the point at which a subversion repository starts to include code that is specially designed to work with any other 5D002 item, whether that item is ever to be included within a product distribution or not. In other words, a project should send out a notification email just after making the decision to include code that is specially designed to work with crypto APIs but before actually committing such code. No need to worry about surprise JIRA attachments with such code -- only the event of committing the code to the ASF product repository. Q3. If we distribute crypto (item controlled by EAR 5D002) previously distributed/exported by another manufacture/company/open source project, are we also responsible for ensuring it qualifies under the TSU exception, including sending a notification email? A3. Yes. The ASF is responsible for complying with the EAR, whether or not the item we are exporting has been previously exported under the TSU exception by another manufacturer. Q4. If the ASF distributes/exports 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? A4. Yes. Each product must qualify separately, which includes sending notifications for each. Q5. 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? A5. No. As long as the email's notification URL for the source location still (directly or indirectly) points to the applicable source for each version's crypto item, no additional process is required. Q6. Where must the email's notification URL point to? Must it point directly to the applicable source, or can it include a level or two of indirection, such as pointing to a list of links to the crypto source of all versions of all products, for instance? A6. The notification URL can point to a page with links to each applicable source. As long as it would be reasonably obvious for a BIS official to find the appropriate source for each crypto item being exported. In other words, it's perfectly fine if every ASF notification email included the exact same URL, as long as that one URL contained info to clearly point off to the applicable source for each crypto item of each version of each product. Q7. If our notification emails point to a page that is always updated with the latest URLs for the crypto source of all versions of all products, when do we ever need to send an additional email beyond the initial notification email for each product? A7. Only when any information submitted in the original notification is no longer true, e.g. a change in the manufacturer. Q8. If there any BIS requirement to tell users and/or redistributors of our products of the crypto within our products? A8. No, but it's a good idea to do so. Q9. When exporting a product designed to use some third-party crypto that also includes the third-party crypto itself, does this require two notifications or one notification with two manufacturers? A9. Any of the following options are fine: two emails, or one email with two complete notifications, or one email with one notification that distinguishes the two items with different manufactures and different URLs. Note that the URLs for the two items can be identical if the distinct source code is linked from the listed URL's web page. However, the preference is to have one email with a complete set of required information for each crypto item in the product. Q10. Is there any problem with the ultimate link to the crypto item's source code pointing to a non-ASF web page? A10. Not as long as the ASF is confident that such non-ASF page is likely to remain available for BIS inspection for the foreseeable future. Should this not be the case at some point, the ASF should update the link to a location that will remain available. Q11. What if the object/binary code being distributed/exported was built from the pointed source but with a particular compiler switch? Is this okay? Any need to explain what compiler switch was used to get the resulting object/binary? A11. It is fine to use whatever compiler switches we like. There is no need to provide compiler switch info, as long as the pointed source code is a superset of all the controlled source that ends up being distributed within the object/binary file. Q12. Do we ever need to notify the BIS of the location of object/binary files? A12. No, but whether we are distributing source of object/binary, we must always make sure a notification has been made pointing (directly or indirectly) to the applicable source. Cliff
