On Jun 7, 2006, at 1:39 PM, William A. Rowe, Jr. wrote:
On the T-8 prohibited countries list, note it is a crime to export
technologies
to them (it's hard for the US to define a crime to obtain said
technologies in
a foreign jurisdiction - let's not get into that debate). However,
as a 'public
download' I believe we are now exempted from trying to discern
where these
parties are. Providing both the base server and an ssl feature
demonstrates good faith that we are providing unrestricted access
to our httpd sources, and
permitting our users to avoid mod_ssl/crypto.
Exactly. It avoids us getting into trouble for asking people to
download httpd without specific reference to the export controls.
Note that Cliff only looked at what was needed for crypto -- he didn't
look at the general issue of producing controlled versus uncontrolled
(for export purposes) software.
On very important points;
we have to file export notices prior to each release in which
the crypto capabilities are changed;
This means the strength of the crypto or feature set.
Right.
Does apr's sha1 and m5 hashing
still fall into this category?
No, one-way hashing and crypto technologies used for the sole purpose
of authentication (not data privacy) are specifically excluded.
we have to file export notices prior to publishing each binary
package that includes mod_ssl and the notice must include a
URL to the 100% open source version of that package;
and
we can only distribute binary versions of openssl if we can point
to the 100% open source package from which it was built *and*
file an export notice for that package prior to our publication;
seem in once sense to be the same issue. Package mod_ssl + OpenSSL
0.9.7i
and does this become one notification or two seperate notifications?
When/If OpenSSL 0.9.8 is distributed 'by us', it's crypto
capabilites are
changed (notably ECC) so renotification is absolutely required.
Less clear
when we go from 0.9.7i to 0.9.7j (it happened to be a buildfix
release) what
is required.
It is impossible for us to distribute OpenSSL without also providing
a URL to the exact 100% open source distribution from which it was
built. As you note, we can't do that by pointing to openssl.org, so
we would have to provide our own copy of the distribution or include
the source code directly in our product, just to comply with EAR.
My preference is to not distribute OpenSSL.
But if I understood Cliff's research and even our earliest legal
advise, it's
not the 'binaries' we notify BIX of, it's actually the "source", so
it wouldn't
seem that once we have notified them of the source code to our
packages, that
any renotification would be needed for individual binaries.
Notification is for products. We must have one notification per product
that includes export-controlled code and 100% of the source code for
that product must be available from a single URL. The notification is
made each time the URL changes or the crypto capability changes.
Note that the single URL may contain a list of package versions and
docs on how to build each such version from a list of source packages.
If we have five different products that use mod_ssl or openssl
(e.g., httpd, tomcat, ftpd, flood, fubar) then we need five different
notifications and each must be distributed as 100% open source to
qualify for the TSU exception.
This also explains why we don't have to provide a notice for everything
in our subversion repository.
Are we 100% certain the 'hooks' for plugging in mod_ssl themselves
are now
totally and completely clear of all this garbage? That was once a
concern back
in the 90's, and I'm almost certain it's technically irrelevant now.
The module hooks are not a concern. The calls within mod_ssl itself
are sufficient to be controlled, as Cliff said:
The 5D002 ECCN includes software specially designed to use other
technology controlled by 5D002. That would imply that mod_ssl is
also
subject to export regulation and is allowed the TSU exception.
Here are some other links worth looking at
http://www.apache.org/dev/crypto.html
http://www.access.gpo.gov/bis/ear/ear_data.html
http://www.hecker.org/mozilla/eccn
http://www.adobe.com/support/exportcompliance.html
http://www.adobe.com/support/eccnmatrix.html
Note that most of Adobe's products are classified as 5D992, which is
either because they requested a specific review and the result was
NLR (no license required) or possibly because of the regulation of
c. "Software" designed or modified to protect
against malicious computer damage, e.g., viruses.
and I don't need to speculate as to why such software is not allowed
to be exported to the T-8 countries.
One weird thing about the ECCNs is that there is no classification
number for "not controlled". *shrug*
....Roy
