>> Are you sure this is the case for commons-crypto? I thought we only >> supported JCE encryption and Open SSL encryption. From the definition of "OCI", I tend to not consider Commons Crypto is an Open cryptographic interface. The algorithm and key lengths it support are fixed.
I would tend to be a ECCN 5D002 self-classify category considering the following: a " Cryptographic items": NO. Commons Crypto doesn't implement the cryptographic algorithms. Instead it wraps to JCE or OpenSSL and it will also not pack any JCE or OpenSSL in its dist. It is more a use of cryptographic items and provide classes for easy of Java usage. b. "Open Cryptographic Interface" items. NO. From the definition of "OCI", I tend to not consider Commons Crypto is an Open cryptographic interface. The algorithm and key lengths it support are fixed. c. Cryptographic libraries, modules, development kits and toolkits, including for operating systems and cryptographic service providers (CSPs). NO. Commons Crypto is more a utility class library. And it is for ease of use for developers. Not for operating systems and cryptographic service providers as mentioned. So how about we go to the process of ECCN 5D002 self-classify category and registration like Taverna did? Regards, Haifeng -----Original Message----- From: Stian Soiland-Reyes [mailto:st...@apache.org] Sent: Friday, May 20, 2016 4:10 PM To: Commons Developers List <dev@commons.apache.org> Subject: Re: US Export classification & ECCN registration for encryption in commons? On 20 May 2016 at 08:53, Benedikt Ritter <brit...@apache.org> wrote: > b. "Open Cryptographic Interface" items. [740.17(b)(2)] looks correct. > But this is just my lucky guess. I'm struggling to find the official definition of "OCI", but I think it's this: https://www.bis.doc.gov/index.php/forms-documents/doc_view/838-772 > (Open cryptographic interface - A mechanism which is designed to allow > a customer or other party to insert cryptographic functionality > without the intervention, help or assistance of the manufacturer or > its agents (i.e., manufacturer's signing of cryptographic code or > proprietary interfaces). If the cryptographic interface implements a > fixed set of cryptographic algorithms, key lengths or key exchange > management systems, that cannot be changed, it will not be considered an > "open" > cryptographic interface. All general application programming > interfaces (i.e., those that accept either a cryptographic or > non-cryptographic interface, but do not themselves maintain any > cryptographic > functionality) will not be considered "open" cryptographic interfaces > either.) Are you sure this is the case for commons-crypto? I thought we only supported JCE encryption and Open SSL encryption. If it is the case it seems we have to submit a formal "encryption classification request", and export would be more restricted on which countries are permitted. See: https://www.bis.doc.gov/index.php/policy-guidance/encryption/classification -- Stian Soiland-Reyes Apache Commons, 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
