-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry to be late to the conversation. I discussed this in person but forgot to send something to the list.
I agree that we need to go through this process. I had looked at it several years ago, but thought it didn't apply to us since we were only using external cryptographic code. However, I think I was wrong about that and that we should have filed something before. This is heightened now with the additional encryption of database data we added for 2.5. I can go ahead and start the process. Josh On Wednesday, July 12, 2017 12:06:52 PM Andy Kurth wrote: > On Tue, Jul 11, 2017 at 8:32 PM, Henry Schaffer <[email protected]> wrote: > > It looks to me than Andy's statement, "None of the VCL-proper source code > > actually does any direct encryption via mathematical or other functions." > > puts the VCL-proper source code into the latter category of "PMCs > > considering including cryptographic functionality within their > > products or *specially > > designing their products to use other software with cryptographic > > functionality* should take the following steps ..." [emphasis added] > > described in the Overview. > > > > I don't understand how Step 1 applies, since that's for crypto software. > > Might we be able to skip this? > > But Steps 2-4 look pretty straight forward and appear necessary. > > > > Will that do it? > > My understanding is that step 1 is simply to determine whether or not the > software is controlled by ECCN 5D002, which describes any software that > uses cryptography in one way or another. I think the answer for step 1 is > yes, VCL is controlled by ECCN 5D002. > > The scope of 5D002 is described in "EAR Category 5 Part 2 - Information > Security": > https://www.bis.doc.gov/index.php/documents/regulations-docs/federal-registe > r-notices/federal-register-2014/951-ccl5-pt2/file > > Pages 1 and 2 apply (up to section "A" on page 2), as well as section "D. > SOFTWARE" beginning on page 7. > > Section D gives a slightly expanded definition than included on the ASF > > page: > > Related Definitions: 5D002.a controls “software” designed or modified to > > use “cryptography” employing digital or analog techniques to ensure > > “information security.” > > This is exactly what VCL is "using cryptography" for. Whether or not the > algorithms are in the VCL-proper source code or another imported/linked > product doesn't seem to be a factor. Unfortunately, the ASF page is very > vague regarding this. It does, however, seem to allude to this here: > https://www.apache.org/dev/crypto.html#faq-twocryptos > > To paraphrase, "Q: If a product uses AND includes 3rd-party crypto items, > does it require one or two notifications? A: One notification, but list > both sources." I infer from this that it's a given a notification is > required when using any 3rd-party crypto. > > There are some exceptions listed in EAR 5D002. VCL doesn't seem to meet > all of the requirements for any that I have found although exceptions could > possibly apply to other ASF projects. Specifically on page 2 Note 4.a.4, > 5D002 does ****not* *apply if: > > The primary function or set of functions is ****not** any of the following: > > 4. Networking (includes operation, administration, management and > > provisioning); > > I know this isn't black or white and the meaning of many of the terms > leaves room for interpretation, but VCL's primary function is to provision, > and it provisions certain networking aspects, so 5D002 does ****not***-**** > *not** apply because of this. > > There's a note on the ASF page: > > Note - the regulations covering US export control laws for encryption were > > changed on June 25th 2010. This page describes the previous process which > > should be continued until an updated version has been drawn up and > > approved > > by the Apache VP Legal Affairs. > > Actually, the latest changes happened 2016-09-20. The page also states: > > Fortunately, the TSU exception to these restrictions, EAR 740.13(e), > > > applies to cryptography of concern to the ASF. > > Part 740 is "License Exceptions": > https://www.bis.doc.gov/index.php/documents/regulation-docs/415-part-740-lic > ense-exceptions/file > Unfortunately, 740.13(e) was redacted from the latest version (page 34): > > (e) [Reserved] > > What was 740.13(e) is now in 742.15(b): > https://www.bis.doc.gov/index.php/documents/regulation-docs/416-part-742-con > trol-policy-ccl-based-controls/file > > (Note: 742.15 starts on page 26) > The changes made to 740 are explained on several legal sites. Per the > following: > http://www.lexology.com/library/detail.aspx?g=b6d5542e-d636-4864-843c-ac7895 > a26450 > > The DOC is revising license exception TSU and Part 742.15 of the EAR to > > > state that publicly available encryption source code classified under ECCN > > 5D002 is no longer subject to the EAR once the TSU email notification is > > sent to BIS and the ENC Encryption Request Coordinator. Part 742.15(b) now > > contains the notification requirement that was previously found within TSU > > at Part 740.13(e). > > So, to make an overly long story short and back to your point -- I think > yes, we did step 1 via this thread and we just need to do steps 2-4. :) > > -Andy > > > --henry > > > > On Tue, Jul 11, 2017 at 1:34 PM, Andy Kurth <[email protected]> wrote: > > > This thread is to discuss the pertinence of the U.S. export control laws > > > regarding cryptography described on the following page: > > > https://www.apache.org/dev/crypto.html > > > > > > The following seems to apply to VCL: > > > > PMCs considering including cryptographic functionality within their > > > > products or *specially designing their products to use other software > > > > with cryptographic functionality* should take the following steps > > > > before > > > > > > placing such code on any ASF server, including commits to subversion > > > > > > VCL has always used some cryptographic functionality and new features > > > > added > > > > > for VCL 2.5 expand the usage. The README lists requirements of > > > php-openssl, openssh, openssl-devel, and xmlsec1-openssl. The backend > > > installation scripts will install a few encryption-related modules and > > > > the > > > > > backend Perl code uses functions from the Crypt::OpenSSL::RSA and > > > others. > > > The frontend does the same. Encrypted strings generated from these > > > > modules > > > > > and libraries are stored in the VCL database. None of the VCL-proper > > > source code actually does any direct encryption via mathematical or > > > other > > > functions. > > > > > > I'm hoping I'm wrong, but it sounds like we should go through all of the > > > steps listed on the page and that all of this should be completed before > > > releasing VCL 2.5 so that the README includes the proper crypto notice. > > > > > > Please discuss... > > > > > > Thanks, > > > Andy > > > > > > PS - I think the *"before placing such code on any ASF server, including > > > commits to subversion"* part of the guidelines is irrelevant at the > > > > current > > > > > time since encryption code has been committed -- in some cases, years > > > > ago. > > > > > We'll certainly abide by this in the future once we figure out how > > > things > > > need to be handled. - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlluICQACgkQV/LQcNdtPQO10ACeMTmcBSgygjZOdsY1kVv4UCAC 2KsAnAs2HYOTei1KsI6fldKHHGvWg+6A =F7ZM -----END PGP SIGNATURE-----
