httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: restructuring mod_ssl as an overlay
Date Wed, 07 Jun 2006 23:02:01 GMT
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.


> 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, 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  
    subject to export regulation and is allowed the TSU exception.

Here are some other links worth looking at

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*


View raw message