You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Nick Burch <ni...@apache.org> on 2012/02/01 19:28:06 UTC
Re: Is a TSU notice needed for software using javax.crypto?
On Tue, 31 Jan 2012, Roy T. Fielding wrote:
> Please note that the BIS requirements have changed since the last time
> we updated the export requirements. AFAIK, we no longer need to send
> notices for merely using publicly available crypto packages.
You wouldn't happen to know any references for that change, would you?
(If someone can point me at the new exemption details, then I can have a
go at updating the page to reflect the changes)
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Fwd: Is a TSU notice needed for software using javax.crypto?
Posted by Pid * <pi...@pidster.com>.
FYI
Begin forwarded message:
*From:* "Roy T. Fielding" <fi...@gbiv.com>
*Date:* 3 February 2012 21:41:42 GMT
*To:* legal-discuss@apache.org
*Subject:* *Re: Is a TSU notice needed for software using javax.crypto?*
*Reply-To:* legal-discuss@apache.org
On Feb 1, 2012, at 10:28 AM, Nick Burch wrote:
On Tue, 31 Jan 2012, Roy T. Fielding wrote:
Please note that the BIS requirements have changed since the last time we
updated the export requirements. AFAIK, we no longer need to send notices
for merely using publicly available crypto packages.
You wouldn't happen to know any references for that change, would you?
With a bit of digging ...
http://www.bis.doc.gov/encryption/default.htm
and, specifically, Note 3 of
http://www.bis.doc.gov/encryption/ccl5pt2.pdf
which eliminates the old way of inheriting 5D002 classification
just because we package a binary with OpenSSL or bouncycastle.
(If someone can point me at the new exemption details, then I can have a go
at updating the page to reflect the changes)
Of course, that assumes we can understand the new regs. In the past,
Cliff actually confirmed our interpretations with some regulator in
the BIS. I don't know if we need to do that again, or if we can just
proceed based on a reasonable interpretation of the regulations
(and assume they'll tell us otherwise if we are wrong).
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Is a TSU notice needed for software using javax.crypto?
Posted by Rob Weir <ro...@apache.org>.
On Sat, Feb 4, 2012 at 1:26 PM, Nick Burch <ni...@apache.org> wrote:
> On Fri, 3 Feb 2012, Roy T. Fielding wrote:
>>>
>>> You wouldn't happen to know any references for that change, would you?
>>
>>
>> With a bit of digging ...
>>
>> http://www.bis.doc.gov/encryption/default.htm
>
>
> That looks like the info we're after, thanks. I've added a note and a link
> to that at the top of the crypto page, suggesting people check with this
> list before proceeding because of the changes.
>
>
> Now, on with reviewing the encryption details....
>
Making my own pass over this for the ODF Toolkit podling. We're in a
similar situation to other Java libraries that rely on JDK Crypto
extensions but have no crypto code in our releases.
Question 1: "Is my item classified under Category 5, Part 2 of the EAR?"
http://www.bis.doc.gov/encryption/question1.htm
They say: "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."
I read this as we evaluate the ODF Toolkit based on the crypto
operations we use in the JDK, which may be a subset of the full
capabilities that the crypto extensions expose.
There are then a set of enumerated exceptions. There are special
exceptions for medical technology and digital rights management
technologies ("intellectual property or copyright protection
functions"). We don't fit into those exceptions.
But then there is Note 4 which "completely removes" technology
("decontrols") from Category 5, Part 2 of the EAR if it meets 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."
http://www.bis.doc.gov/encryption/question6sub_2.htm
Let's parse this. First, what is "the primary function or set of
functions"? Note 4 starts with "Category 5, Part 2 does not apply to
items incorporating or using “cryptography” and meeting all of the
following:". So, we're talking about the ODF Toolkit, which uses
cryptography. We're not talking about the Java Crypto Extensions.
What is a "primary function"? This is addressed in their FAQ:
"The primary function is the obvious, or main, purpose of the item.
It is the function which is not there to support other functions."
http://www.bis.doc.gov/encryption/enc_faqs.htm#15
Note: I am interpreting "the primary function or set of functions" as
being the same as "the primary function or primary set of functions",
e.g., the lack of a comma in there means that "primary" modifies both.
The ODF Toolkit is described on our home page:
"The Apache ODF Toolkit is a set of Java modules that allow
programmatic creation, scanning and manipulation of Open Document
Format (ISO/IEC 26300 == ODF) documents. " I would take that
description as a statement of the library's primary purpose.
Going down the list:
a 1. Is it "information security"?
Part 772 provides the definitions for EAR. The definition of
"information security" is:
http://www.bis.doc.gov/policiesandregulations/ear/772.pdf
"Information Security (Cat 5) -- All the means and functions ensuring
the accessibility, confidentiality or integrity of information or
communications, excluding the means and functions intended to
safeguard against malfunctions. This includes “cryptography”,
“cryptographic activation”, “cryptanalysis”,
protection against compromising emanations and computer security.""
My interpretation: The primary function of the ODF Toolkit is not
"information security". Although the Toolkit does enable, when used
in conjunction with the Java Crypto Extensions, the encryption of
office documents and to the ability to affix and verify digital
signatures to those documents, this is not its primary function.
Moving on....
Is our primary function: "2. A computer, including operating systems,
parts and components therefor;"
My interpretation: Obviously not.
Is our primary function: "3. Sending, receiving or storing information
(except in support of entertainment, mass commercial broadcasts,
digital rights management or medical records management);"
My interpretation: No.
Is our primary function: " 4. Networking (includes operation,
administration, management and provisioning);"
My interpretation: No.
So we do not hit any of the non-exceptions in Note 4(a). That leaves
4(b) and 4(c), both of which we must be able to answer yes to in order
to qualify for the Note 4 exemption:
"b. The cryptographic functionality is limited to supporting their
primary function or set of functions;"
My interpretation: Yes. The primary function is "programmatic
creation, scanning and manipulation of Open Document Format (ISO/IEC
26300 == ODF) documents." The ODF Toolkit does not expose generic
encryption support. It is used to support the above primary purpose.
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."
My interpretation: Yes. First, the code is publicly available (or
will be as soon as we check this feature in) as open source software.
Second, we would comply with requests for supporting information.
So I think we hit that Note 4 exemption and don't need to file any
control declaration. Of course, IANAL, nor am I a federal government
bureaucrat. To the uninitiated, like me, these regulations are
daunting. But I would be interested in whether anyone reads the
regulation in a different way than I have.
> I believe that under the new rules (EAT Category 5 Part 2), the same policy
> should apply whether we use someone else's encryption (including OS or
> Platform supplied stuff), or if we implemented our own encryption routines
> (which I don't think any projects do?). That's based on their question 1
> <http://www.bis.doc.gov/encryption/question1.htm>.
>
At least in terms of question 1, I read it the same way.
> From their question 2 <http://www.bis.doc.gov/encryption/question2.htm> I
> think there will be a difference for things like httpd (based on open source
> encryption) and Java projects (based on mass market encryption). I'm not
> sure though, as it's not completely clear when you need to carry on with the
I'm not sure "mass market encryption" would include Java code that
uses the crypto extensions. The mass market stuff is in Note 3, but
one of the requirements is that:
"The cryptographic functionality cannot be easily changed by the
user;" Is this ever true of open source software?
They also seem (perhaps inadvertently) to exclude open source software
by requiring that "mass market" items be "sold".
> encryption providers classification, and when it's your own. The flowchart
> <http://www.bis.doc.gov/encryption/decision_tree.pdf> doesn't help much here
> either. Projects using javax.crypto I think should be fine under 5x992,
> which doesn't need registration and can be self classified, but I'm not
> clear if things based on a 5d002 publicly available encryption source code
> can be 5x992, or have to be 5d002 themselves
>
> It looks to me like if we are covered under 5x992, we may not need to
> register or produce annual / semi-annual reports, only record that we're
> self classifying. 5d002 still seems to need a notification, but not reports.
> If we're under 5x992, then I think 740.17(e)(1)(iii) covers us for not
> needing to report
> <http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=ba2d5996d28cc22033ea2bfb857555cc&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.17>
>
>
>
>> and, specifically, Note 3 of
>>
>> http://www.bis.doc.gov/encryption/ccl5pt2.pdf
>>
>> which eliminates the old way of inheriting 5D002 classification
>> just because we package a binary with OpenSSL or bouncycastle.
>
>
> Maybe, I'm not completely sure if that's what it means...
>
>
>
>> Of course, that assumes we can understand the new regs. In the past,
>> Cliff actually confirmed our interpretations with some regulator in the BIS.
>> I don't know if we need to do that again, or if we can just proceed based
>> on a reasonable interpretation of the regulations (and assume they'll tell
>> us otherwise if we are wrong).
>
>
> I think we could have 3 kinds of encryption software in our projects:
> 1) Actually implements encryption
> 2) Uses someone else's 5D002 public source encryption
> 3) Uses someone else's mass market encryption
>
Another way of cutting it, is:
1) Products whose primary function is sending/receiving information
over the network, or storing information. These seem to hit the
exceptions in Note 4.
2) Products whose primary function is something other than
sending/receiving/storing information.
> For 1, I don't know if we have any projects at the moment that do this, but
> I think the situation for them is unchanged
>
> For 3, I believe we just need to note somewhere (probably centrally and in a
> notice in the software) that we're self classifying under 5x992, then we
> don't need to notify BIS or produce reports.
>
> I'm still not sure on 2, if it counts as 1 or 3
>
>
> For those still following:
> * Do you think I'm correct with interpreting the situation for cases 1
> and 3? (If so, I can start drafting the new guidance)
> * Can you find anything saying which way case 2 goes?
>
I'm reading it as more dependent on the primary function of the program.
> Nick
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Is a TSU notice needed for software using javax.crypto?
Posted by Nick Burch <ni...@apache.org>.
On Fri, 3 Feb 2012, Roy T. Fielding wrote:
>> You wouldn't happen to know any references for that change, would you?
>
> With a bit of digging ...
>
> http://www.bis.doc.gov/encryption/default.htm
That looks like the info we're after, thanks. I've added a note and a
link to that at the top of the crypto page, suggesting people check with
this list before proceeding because of the changes.
Now, on with reviewing the encryption details....
I believe that under the new rules (EAT Category 5 Part 2), the same
policy should apply whether we use someone else's encryption (including OS
or Platform supplied stuff), or if we implemented our own encryption
routines (which I don't think any projects do?). That's based on their
question 1 <http://www.bis.doc.gov/encryption/question1.htm>.
>From their question 2 <http://www.bis.doc.gov/encryption/question2.htm> I
think there will be a difference for things like httpd (based on open
source encryption) and Java projects (based on mass market encryption).
I'm not sure though, as it's not completely clear when you need to carry
on with the encryption providers classification, and when it's your own.
The flowchart <http://www.bis.doc.gov/encryption/decision_tree.pdf>
doesn't help much here either. Projects using javax.crypto I think should
be fine under 5x992, which doesn't need registration and can be self
classified, but I'm not clear if things based on a 5d002 publicly
available encryption source code can be 5x992, or have to be 5d002
themselves
It looks to me like if we are covered under 5x992, we may not need to
register or produce annual / semi-annual reports, only record that we're
self classifying. 5d002 still seems to need a notification, but not
reports. If we're under 5x992, then I think 740.17(e)(1)(iii) covers us
for not needing to report
<http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=ba2d5996d28cc22033ea2bfb857555cc&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.17>
> and, specifically, Note 3 of
>
> http://www.bis.doc.gov/encryption/ccl5pt2.pdf
>
> which eliminates the old way of inheriting 5D002 classification
> just because we package a binary with OpenSSL or bouncycastle.
Maybe, I'm not completely sure if that's what it means...
> Of course, that assumes we can understand the new regs. In the past,
> Cliff actually confirmed our interpretations with some regulator in the
> BIS. I don't know if we need to do that again, or if we can just
> proceed based on a reasonable interpretation of the regulations (and
> assume they'll tell us otherwise if we are wrong).
I think we could have 3 kinds of encryption software in our projects:
1) Actually implements encryption
2) Uses someone else's 5D002 public source encryption
3) Uses someone else's mass market encryption
For 1, I don't know if we have any projects at the moment that do this,
but I think the situation for them is unchanged
For 3, I believe we just need to note somewhere (probably centrally and in
a notice in the software) that we're self classifying under 5x992, then we
don't need to notify BIS or produce reports.
I'm still not sure on 2, if it counts as 1 or 3
For those still following:
* Do you think I'm correct with interpreting the situation for cases 1
and 3? (If so, I can start drafting the new guidance)
* Can you find anything saying which way case 2 goes?
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Is a TSU notice needed for software using javax.crypto?
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Roy Fielding wrote:
> Of course, that assumes we can understand the new regs. In the past,
> Cliff actually confirmed our interpretations with some regulator in
> the BIS. I don't know if we need to do that again, or if we can just
> proceed based on a reasonable interpretation of the regulations
> (and assume they'll tell us otherwise if we are wrong).
Roy almost certainly understands the export regs better than I do, and Cliff
understood them even better when he and I first discussed his FAQ years ago.
My only caution is that, in something as important as this, we should ask
for formal legal advice. The one thing that a lawyer's advice can add to the
equation is that reliance on an attorney rather than on Roy Fielding is one
way to avoid damages for gross negligence or willful negligence in some
areas of the law. I don't know about export regs in that regard, so don't
ask me.
/Larry
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: Friday, February 03, 2012 1:42 PM
> To: legal-discuss@apache.org
> Subject: Re: Is a TSU notice needed for software using javax.crypto?
>
> On Feb 1, 2012, at 10:28 AM, Nick Burch wrote:
>
> > On Tue, 31 Jan 2012, Roy T. Fielding wrote:
> >> Please note that the BIS requirements have changed since the last
> time we updated the export requirements. AFAIK, we no longer need to
> send notices for merely using publicly available crypto packages.
> >
> > You wouldn't happen to know any references for that change, would
> you?
>
> With a bit of digging ...
>
> http://www.bis.doc.gov/encryption/default.htm
>
> and, specifically, Note 3 of
>
> http://www.bis.doc.gov/encryption/ccl5pt2.pdf
>
> which eliminates the old way of inheriting 5D002 classification
> just because we package a binary with OpenSSL or bouncycastle.
>
> > (If someone can point me at the new exemption details, then I can
> have a go at updating the page to reflect the changes)
>
> Of course, that assumes we can understand the new regs. In the past,
> Cliff actually confirmed our interpretations with some regulator in
> the BIS. I don't know if we need to do that again, or if we can just
> proceed based on a reasonable interpretation of the regulations
> (and assume they'll tell us otherwise if we are wrong).
>
> ....Roy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Is a TSU notice needed for software using javax.crypto?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 1, 2012, at 10:28 AM, Nick Burch wrote:
> On Tue, 31 Jan 2012, Roy T. Fielding wrote:
>> Please note that the BIS requirements have changed since the last time we updated the export requirements. AFAIK, we no longer need to send notices for merely using publicly available crypto packages.
>
> You wouldn't happen to know any references for that change, would you?
With a bit of digging ...
http://www.bis.doc.gov/encryption/default.htm
and, specifically, Note 3 of
http://www.bis.doc.gov/encryption/ccl5pt2.pdf
which eliminates the old way of inheriting 5D002 classification
just because we package a binary with OpenSSL or bouncycastle.
> (If someone can point me at the new exemption details, then I can have a go at updating the page to reflect the changes)
Of course, that assumes we can understand the new regs. In the past,
Cliff actually confirmed our interpretations with some regulator in
the BIS. I don't know if we need to do that again, or if we can just
proceed based on a reasonable interpretation of the regulations
(and assume they'll tell us otherwise if we are wrong).
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org