commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: US Export classification & ECCN registration for encryption in commons?
Date Fri, 20 May 2016 06:53:44 GMT
Hello Haifeng,

Chen, Haifeng <haifeng.chen@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.chen@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:stain@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.chen@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.chen@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:sebbaz@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 <stain@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 <sebbaz@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 <britter@apache.org> wrote:
> >>>> Hi,
> >>>>
> >>>> Stian Soiland-Reyes <stain@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-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message