www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Burch <n...@apache.org>
Subject Re: Is a TSU notice needed for software using javax.crypto?
Date Sat, 04 Feb 2012 18:26:35 GMT
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


Mime
View raw message