http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items
says

> Is the item designed to use cryptography or does it contain cryptography?

> Almost all items controlled under Category 5, Part 2 of the EAR are 
> controlled because they include encryption functionality. Items may be 
> controlled as encryption items even if the encryption is actually performed 
> by the operating system, an external library, a third-party product or a 
> cryptographic processor. If an item uses encryption functionality, whether or 
> not the code that performs the encryption is included with the item, then BIS 
> evaluates the item based on the encryption functionality it uses.

Similarly, if the item includes encryption functionality, even if the
encryption functionality is not used by the item, then BIS evaluates
the item based on the included encryption functionality.


So "include encryption functionality" would be the case for the binary
dists that embed Jetty, etc.

If it is not included (as in the source code) then it's evaluated on
which encryption functionality that is used - which would not be
directly used by Jena's source code, but by HTTP Client's support for
HTTPS etc. (We only use the HTTP Client encryption ITEM rather than
the HTTP Client encryption FUNCTIONALITY). So I think you are right in
the approach you suggest.



On 30 October 2016 at 13:56, Andy Seaborne <[email protected]> wrote:
> Jena does not implement any cryptographic but we do bundle dependencies that
> include such software in the binary distributions for HTTPS and for web app
> security (Shiro).
>
> Plan:
>
> 1/ Include a "Cryptographic Software Notice" in each of the binary
> distribution README files.
>
>     apache-jena/dist/README
>     jena-fuseki2/apache-jena-fuseki/README
>     jena-fuseki1/apache-jena-fuseki/README
>
> This part is Apache-required and not part of the US export registration
> process.
>
> The software bundled concerned is
>   Apache HttpClient
>   Apache HttpComponents Core
>   Eclipse Jetty
>   Apache Shiro
>
> PR#187
>
> 2/ Register a product
>
> NB "version" has a specific means, more like "usage"
>
> "Apache Jena (distribution)"
>   Versions: development
>             [for the snapshot maven repo]
>             binary distribution
>             [for the binaries and release maven repo]
>
> and send required email to the required US gov organisations and Apache
> lists.
>
> ----
>
> I thought about 3 products (apache-jena, fuseki1, fuseki2). For stability,
> the links ended up to the gernal area of repo or archives (as other projects
> also have it) so 3 products did not make anything better.
>
> I also looked at various other projects - things are not uniform. Theer are
> cases of "over register" where the crypto notice in the code base README.
> That's unhelpful when the project itself does not provide crypto software
> and wrong when the source-release gets made (it goes not contain any such
> software). Like NOTICE, being minimal seemed more in the spirit of things.
>
>         Andy
>
> [1] http://www.apache.org/dev/crypto.html
> [2] http://www.apache.org/licenses/exports/



-- 
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

Reply via email to