Hello Haifeng, Chen, Haifeng <haifeng.c...@intel.com> schrieb am Fr., 20. Mai 2016 um 07:39 Uhr:
> [Resend for correcting some text format problems] > > Thanks Stian for your help. > Based on the current understanding, we can conclude that Commons Crypto is > Category 5, Part 2 controlled. And so the encryption registration is needed. > For the encryption registration, Commons Crypto goes to ECCN 5D002 > self-classify category. (I tend to think that Commons Crypto module doesn't > create any encryption algorithms, instead it is only use to provide > usability functionalities) > > As to the encryption classification list in > https://www.bis.doc.gov/index.php/policy-guidance/encryption/classification, > not sure whether Commons Crypto belongs to the following items and thus > need an encryption classification request. > a. "Cryptographic items". [740.17(b)(2)] > b. "Open Cryptographic Interface" items. [740.17(b)(2)] > c. Cryptographic libraries, modules, development kits and toolkits, > including for operating systems and cryptographic service providers (CSPs). > [740.17(b)(3)] > To me b. "Open Cryptographic Interface" items. [740.17(b)(2)] looks correct. But this is just my lucky guess. Benedikt > > What folks think about this? > > -----Original Message----- > From: Chen, Haifeng [mailto:haifeng.c...@intel.com] > Sent: Friday, May 20, 2016 1:28 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: RE: US Export classification & ECCN registration for encryption > in commons? > > Thanks Stian for your help. > Based on the current understanding, we can conclude that Commons Crypto is > Category 5, Part 2 controlled. And so the encryption registration is needed. > For the encryption registration, Commons Crypto goes to ECCN 5D002 > self-classify category. (I tend to think that Commons Crypto module doesn't > create any encryption algorithms, instead it is only use to provide > usability functionalities) > > As to the encryption classification list in > https://www.bis.doc.gov/index.php/policy-guidance/encryption/classification, > not sure whether Commons Crypto belongs to the following items and thus > need an encryption classification request. > ◾"Cryptographic items". [740.17(b)(2)] > ◾"Open Cryptographic Interface" items. [740.17(b)(2)] ◾Cryptographic > libraries, modules, development kits and toolkits, including for operating > systems and cryptographic service providers (CSPs). [740.17(b)(3)] > > What folks this about this? > > > Regards, > Haifeng > > -----Original Message----- > From: Stian Soiland-Reyes [mailto:st...@apache.org] > Sent: Thursday, May 19, 2016 4:10 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: US Export classification & ECCN registration for encryption > in commons? > > 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/identify > >> i 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/identify > >> i > >> 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
