Hi, for Taverna the question mainly came down to: 1) What encryption functionality have we designed to use? (e.g. we use BouncyCastle for encryption, but our use of Derby does not use encryption)
2) What encryption items (e.g. JARs) will we include in distros (we will bundle BouncyCastle, Derby, etc) With Commons Crypto you have to be careful also about the ECCN classification if it can be seen as a development toolkit for creating encryption algorithms. See https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items >From the linked "Flow chart 1" I find for Commons Crypto: Designed to use or contain cryptography? Yes Specifically designed for medical? No Exempt by Note 4? No (Primary function is "Information security") Limited to DRM stuff? No -> Category 5, Part 2 controlled So then we go through https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration Flow chart 2: Is the item publicly available encryption source code? Yes. -> ECCN 5D002 self-classify For the classification listing on https://www.apache.org/licenses/exports/ you basically just list that you are designed to be used with OpenSSL and JCE, with links to them. But note: https://www.bis.doc.gov/index.php/policy-guidance/encryption/classification Do any of those apply to Commons Crypto? On 19 May 2016 at 07:45, Chen, Haifeng <haifeng.c...@intel.com> wrote: > Hi Stian, > I saw you worked actively on same registration issue for Taverna. Do you have > any suggestions on what steps we should take for Crypto registration? > We are keenly to get a first release of Crypto. > > Regards, > Haifeng > > -----Original Message----- > From: Chen, Haifeng [mailto:haifeng.c...@intel.com] > Sent: Friday, May 13, 2016 1:39 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: RE: US Export classification & ECCN registration for encryption in > commons? > > Hi folks, > From LEGAL-250 discussion, it showed that Commons Crypto should be registered. > Shall we also add Commons Crypto to ECCN Matrix in > http://www.apache.org/licenses/exports/ page (eccnmatrix.xml) the same as > what Apache Taverna did? > > Regards, > Haifeng > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Monday, May 9, 2016 7:48 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: US Export classification & ECCN registration for encryption in > commons? > > On 9 May 2016 at 11:52, Stian Soiland-Reyes <st...@apache.org> wrote: >> My take: >> >> (But we can also ask Legal separately as LEGAL-250 got a bit long >> thread) > > +1 > >> >> The exception for open source means we just need to self-classify as >> 5D002 and send a notification email according to >> http://www.apache.org/dev/crypto.html >> >> >> https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifyi >> ng-encryption-items has some updated guidance after the 2010 changes: >> >>> 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. >> >> By not making binary distributions with third-party JARs we would not >> be INCLUDING the encryption functionality. However we would in some >> cases USE the encryption functionality. >> >> >> There IS an exemption from being classified at all in >> https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifyi >> ng-encryption-items#Three >> >> >> >>> Note 4: Category 5, Part 2 does not apply to items incorporating or using >>> "cryptography" and meeting all of the following: >>> >>> (a) The primary function or set of functions is not any of the following: >>> (1) "Information security"; >>> (2) A computer, including operating systems, parts and components >>> therefor; >>> (3) Sending, receiving or storing information (except in support of >>> entertainment, mass commercial broadcasts, digital rights >>> management or medical records management); or >>> (4) Networking (includes operation, administration, management >>> and provisioning); >>> > (b) The cryptographic functionality is limited to supporting their >>> > primary function or set of functions; and >>> (c) When necessary, details of the items are accessible and will be >>> provided, upon request, to the appropriate authority in the exporter’s >>> country in order to ascertain compliance with conditions described in >>> paragraphs (a) and (b) above. >> >> meaning that say Commons Imaging would be exempt from any registration >> - even if it included support for reading encrypted images. >> >> (however some software using such a hypothetical Commons Imaging >> w/crypto, and incidentally also doing sending/receiving/storing >> information, WOULD need to classify) >> >> >> but Commons-VFS - with support for SFTP, WebDav etc., is arguably >> "Sending, receiving or storing information", and would by having >> strong bindings to Apache SSHd (itself listed) and JSCH which >> encryption functionality VFS would be using. > > Commons NET would also need to register then. > >> The test dependency on Bouncy Castle is ironically not cause for >> registration as VFS code is not designed to use BCProv, and do not >> bundle the Bouncy Castle implementation. >> >> >> >> Commons Crypto would be doing "information security" and Iwould say >> also need to be registered. >> >> On 5 May 2016 at 10:45, sebb <seb...@gmail.com> wrote: >>> Also note that there is a TSU Exception, EAR 740.13(e) - Publicly >>> available encryption source code - which the dev/crypto.html page >>> says applies to the ASF. >>> >>> I think we need to wait for guidance from Legal. >>> >>> On 5 May 2016 at 10:04, Benedikt Ritter <brit...@apache.org> wrote: >>>> Hi, >>>> >>>> Stian Soiland-Reyes <st...@apache.org> schrieb am Mi., 4. Mai 2016 >>>> um >>>> 14:35 Uhr: >>>> >>>>> Hi, >>>>> >>>>> Sorry for spotting this.. >>>>> >>>>> >>>>> Apache Commons Crypto is not listed on >>>>> http://www.apache.org/licenses/exports/ - does it need to be? (One >>>>> would assume so..) >>>>> >>>>> Also it was raised that Commons VFS depends on Bouncy Castle/Apache >>>>> Mina/Jetty/SSHD/Hadoop/jsch and has encryption binding for AES128 - >>>>> perhaps that also needs to be listed and registered? >>>>> >>>> >>>> Thank you for pointing this out. I've reported this as >>>> https://issues.apache.org/jira/browse/CRYPTO-54. I'm not involved in >>>> VFS, but I've seen that the discussion about that has already >>>> started on the vote for VFS 2.0 rc1. >>>> >>>> Benedikt >>>> >>>> >>>>> >>>>> >>>>> We only have listed: >>>>> >>>>> Commons Compress >>>>> Commons OpenPGP >>>>> >>>>> >>>>> See guidance on >>>>> http://www.apache.org/dev/crypto.html >>>>> >>>>> >>>>> BTW - I've raised https://issues.apache.org/jira/browse/LEGAL-250 >>>>> to see if merely using a listed source as a Maven <dependency> >>>>> means you also are classified - or if you would need to also bundle >>>>> the dependency's binary (which I think we don't do). >>>>> >>>>> >>>>> >>>>> -- >>>>> Stian Soiland-Reyes >>>>> Apache Taverna (incubating), Apache Commons RDF (incubating) >>>>> http://orcid.org/0000-0001-9842-9718 >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> >> -- >> Stian Soiland-Reyes >> Apache Taverna (incubating), Apache Commons RDF (incubating) >> http://orcid.org/0000-0001-9842-9718 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
