apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <cliffschm...@gmail.com>
Subject Crypto FAQ
Date Wed, 05 Jul 2006 00:11:19 GMT
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

Mime
View raw message