RE: Legal concerns/questions with exporting/importing Apache Poi 3.5

[Robert Hafner <Ro...@sas.com>]

Reposting the following questions since I have not seen a follow up response yet.


The email below says that the POI only uses encryption (RC4) to read password protected workbooks . . . 
*	Does this encrypt the password (or other file protection data) only or does it also encrypt the contents of the workbook?
*	What is the strength (or key length) of the algorithm as implemented . . . usually between 40 and 128 bits?
*	Has this use been reviewed by BIS?  If so, is there a CCATS#

Thanks,
Rob



-----Original Message-----
From: David Fisher [mailto:dfisher@jmlafferty.com] 
Sent: Thursday, February 04, 2010 12:16 PM
To: Robert Hafner
Subject: Re: Legal concerns/questions with exporting/importing Apache Poi 3.5

Rob,

We, the POI developers, are rather busy with our day jobs at the  
moment plus Yegor is off to Bavaria for a cross-country ski marathon.  
I expect that we will have clarification by next Tuesday at the latest.

Sorry for the delays.

Regards,
Dave

On Feb 4, 2010, at 8:35 AM, Robert Hafner wrote:

>
> The email below says that the POI only uses encryption (RC4) to read  
> password protected workbooks . . .
> *	Does this encrypt the password (or other file protection data)  
> only or does it also encrypt the contents of the workbook?
> *	What is the strength (or key length) of the algorithm as  
> implemented . . . usually between 40 and 128 bits?
> *	Has this use been reviewed by BIS?  If so, is there a CCATS#
>
> Thanks,
> Rob
>
>
> -----Original Message-----
> From: Yegor Kozlov [mailto:yegor@dinom.ru]
> Sent: Friday, January 22, 2010 1:04 PM
> To: POI Developers List
> Subject: Re: Legal concerns/questions with exporting/importing  
> Apache Poi 3.5
>
>> One of our product teams has expressed an interest in upgrading to  
>> Apache Poi 3.5. I also expect other products to express an interest  
>> in future releases. During the third party review process our Legal  
>> department expressed some concern regarding Poi's cryptography  
>> notice (http://poi.apache.org/legal.html) and its classification as  
>> 5D002.C.1 under ECCN. This classification requires us to report all  
>> exports of the product (and our products containing the product)  
>> twice each year. This is an administratively intensive task for our  
>> Legal Department and not one we are currently equipped to handle  
>> very efficiently.  Therefore we are looking for a solution which  
>> allows our products to upgrade to v3.5 without placing an  
>> additional burden on our Legal department.  Can you answer the  
>> following questions which should help us decide what options we  
>> have available?
>>
> I think this Cryptography Notice is outdated. At some point we  
> attempted to use javax.crypto and javax.xml.crypto
> packages for implementation of Digital Signature support in OOXML  
> documents. The initial patch was checked-in but then
> reverted until we have consensus on legal and patent issues. The  
> Java code was reverted but the notice remained.
>
>> Legal Questions:
>> 1)      Does Apache Poi 3.5 use the java.security and javax.crypto  
>> packages from the JRE, JCE, or a different product? If it is the  
>> JRE packages, then why is the Apache product classified as 5D002.  
>> Based upon our legal department's analysis the JRE is classified as  
>> 54992 (which is a more favorable classification that does not  
>> require reporting).
>
> At the moment POI does not use any of javax.crypto  classes. We have  
> our own implementation of RC4 which is equivalent
> to the RC4 cypher from javax.crypto - we use RC4 to read password  
> protected workbooks. This implementation is based on
> public information and was inspired by Wikipedia's RC4 article http://en.wikipedia.org/wiki/RC4 
> .
>
> The only class that POI uses from java.security is MessageDigest. As  
> far as I know it is not classified by the US export
> regulations.
>
>> 2)   Has the Apache Poi product been reviewed by BIS? Does it have  
>> any CCATS#? If Poi 3.5 has been reviewed, was any type of reporting  
>> exception granted in the review?
>>
>
>> Technical Questions:
>> 1)      Would it be possible to obtain a copy of Apache POI 3.5  
>> that does not have the encryption (or encryption calls)? Or could  
>> we build our own version (without the encryption support)?
>
> Yes, it is possible. The source code of POI 3.5 ( and any other  
> releases) is publicly available and if you want, you can
> root out the encryption  classes, the Apache license allows you to  
> do it.
>
> Regards,
> Yegor
>
>>
>> Thanks.
>> Rob
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
>> For additional commands, e-mail: dev-help@poi.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

RE: Legal concerns/questions with exporting/importing Apache Poi 3.5

[Nick Burch <ni...@alfresco.com>]

On Tue, 2 Mar 2010, Robert Hafner wrote:
> Reposting the following questions since I have not seen a follow up 
> response yet.

As you probably guessed from the deafening silence, you appear to know 
more about US crypto rules than all of us put together... I think as a 
general rule we all only know what's listed at 
http://www.apache.org/dev/crypto.html !

SVN informs me that the export notice for POI went in on 2009-08-06. This 
was in response to the contribution from Maxim in bug #47652 - 
https://issues.apache.org/bugzilla/show_bug.cgi?id=47652

I think the notice would also be needed for the digital signature support 
(see <http://mail-archives.apache.org/mod_mbox/poi-dev/200910.mbox/%3ca644352c0910131330l6709d896hb0933b2759d16a9d@mail.gmail.com%3e>)
if it were to be re-commited.


> * Does this encrypt the password (or other file protection data) only or 
> does it also encrypt the contents of the workbook?

The two main commits around this are:
http://svn.apache.org/viewvc?view=revision&revision=801890
http://svn.apache.org/viewvc?view=revision&revision=804381

I think all of the contents are encrypted, as the main work is on 
inserting a decryption layer between the record creation and the 
underlying stream

> * What is the strength (or key length) of the algorithm as implemented . 
> . . usually between 40 and 128 bits?

I think from looking at the code it's 40 bytes, BICBW

> * Has this use been reviewed by BIS?  If so, is there a CCATS#

I'm not sure who BIS are, or what a CCATS number is when it's at home... 
So it's unlikely but certainly not impossible! We followed all the rules 
laid down in http://www.apache.org/dev/crypto.html but didn't do anything 
more.

If there's some magic form we should fill in and send off to the US 
government to make the lives of our users easier, and someone can tell use 
what to put in said form, we'll happily do so! However I think at the 
moment our knowledge of US crypto policy is pretty much "follow these 
incantations and everything is ok, neglect to follow them and the ASF gets 
into trouble, so just follow them" and that's it...

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org