subject:"RE\: Request dev help\: Info for required crypto export declaration"

On Thu, Sep 1, 2011 at 11:41 AM, Pedro F. Giffuni giffu...@tutopia.com wrote:
 While here,

 Can Apache projects rely on Mozilla's nss (MPL)?


See this page on current view from Apache legal:

http://www.apache.org/legal/resolved.html#category-b


 I looked for alternatives but I only found the java based
 Bouncy Castle:

 http://www.bouncycastle.org/

 cheers,

 Pedro.

 --- On Thu, 9/1/11, Dennis E. Hamilton dennis.hamil...@acm.org wrote:

 From: Dennis E. Hamilton dennis.hamil...@acm.org
 Subject: RE: Request dev help: Info for required crypto export declaration
 To: ooo-dev@incubator.apache.org
 Date: Thursday, September 1, 2011, 12:00 AM
 It is simplified and it isn't.
 But we are doing it out of order.

 Here is the page that I couldn't remember the location of:

 http://www.apache.org/dev/crypto.html

  - Dennis

 -Original Message-
 From: rabas...@gmail.com
 [mailto:rabas...@gmail.com]
 On Behalf Of Rob Weir
 Sent: Wednesday, August 31, 2011 09:31
 To: ooo-dev@incubator.apache.org
 Subject: Re: Request dev help: Info for required crypto
 export declaration

 On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org
 wrote:
  I thought there was a short-circuit/umbrella process
 that doesn't require all of these details.  I thought
 that came up on an old thread, either on the PPMC or in the
 early days of this list.
 
  We do need to collect and update the details, but I am
 not so sure we need to file a full-up declaration.
 There is apparently a simplified procedure and we should
 look for it. (I am not where I can do that right now.)
 

 Uh... but we need to know the details to know whether we
 can use the
 simplified procedure.

 -Rob


  -Original Message-
  From: Mathias Bauer [mailto:mathias_ba...@gmx.net]
  Sent: Wednesday, August 31, 2011 07:00
  To: ooo-dev@incubator.apache.org
  Subject: Re: Request dev help: Info for required
 crypto export declaration
 
  Moin,
 
  please take my answers with a decent grain of salt,
 I'm not an expert
  for that area, Matthias Hütsch and Malte Timmermann
 certainly could
  answer that better, but I don't know if they are
 currently contributing
  to this list. Hopefully my remarks can help to look at
 the right places.
 
  Am 31.08.2011 15:03, schrieb Rob Weir:
 
  There is some paperwork we need to file based on
 OOo use of
  cryptography.  Details are on the Apache
 website [1].  I think I can
  handle most of the paperwork, provided I can get
 some help, on this
  thread, establishing the basic facts.
 
 
  1) Was something similar every done for
 OpenOffice.org?  Most software
  companies are aware of this US export regulation
 and do this
  declaration as a matter of routine.  But not
 all open source projects
  are as diligent as ASF is.  So it is possible
 that OOo never did this
  before.  But if they did, we could reuse much
 of their paperwork.
 
  AFAIR Sun did that some time ago, but I'm not 100%
 sure.
 
  2) We need a list of all uses of cryptographic
 methods in OOo,
  including code that we include, but also where we
 enable 3rd party or
  OS crypto modules to plugged in.  This
 includes both symmetrical
  algorithms (commonly used for encryption) as well
 as asymmetrical
  algorithms (for example, public key uses like PGP,
 RSA, TLS, etc.)
 
  3) For each method, it looks like we need to state
 whether we authored
  the crypto, or name the origin of the code if it
 is a 3rd party.
 
  The methods I suspect are in OOo are:
 
  a) For password-protected ODF documents, we use
 the Blowfish block
  encryption method.   Where did that
 code come from?
 
  It was an own implementation from someone who was
 employed by Sun at
  that time.
 
  In the new 3.4 code we also use AES code from the
 openssl library.
 
  b) What do we support for other document formats,
 such as DOC, OOXML
  or legacy StarOffice formats?  Any other
 encryption methods?  If so,
  what are they are what was their origin?
 
  As none of the former Oracle employed MS filter
 developers is listening
  here, maybe we could ask Kohei or Caolan from the
 Libre Office crew.
 
  c) We support digital signatures with ODF files as
 well.  What
  algorithms are supported?  Is this our
 original code or 3rd party?
 
  The code we use is based on the SeaMonkey or nss
 module. I always get
  confused about them, but in any way the code is
 external.
 
  d)  Do we support digital signatures with any
 other file formats?
 
  No, only our own files format.
 
  e) Any other uses of encryption?
 
  f) Presumably we places that are at least enabled
 for SSL via OS-level
  resolution of https protocol
 URLs.   Is this correct?
 
  g) But do we have any SSL (TLS) code included in
 our source code?  If
  so, what is the origin of this?
 
  Open ssl, maybe something in neon, I don't know.
 
  Regards,
  Mathias

Re: Request dev help: Info for required crypto export declaration

2011-09-01 Thread Danese Cooper

On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir r...@robweir.com wrote:

 On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:



 snip



  1) Was something similar every done for OpenOffice.org?  Most software
  companies are aware of this US export regulation and do this
  declaration as a matter of routine.  But not all open source projects
  are as diligent as ASF is.  So it is possible that OOo never did this
  before.  But if they did, we could reuse much of their paperwork.
 
  AFAIR Sun did that some time ago, but I'm not 100% sure.


Yes, Sun did this (probably for every official release).

Danese

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 11:51 AM, Danese Cooper dan...@gmail.com wrote:
 On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir r...@robweir.com wrote:

 On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:



 snip



  1) Was something similar every done for OpenOffice.org?  Most software
  companies are aware of this US export regulation and do this
  declaration as a matter of routine.  But not all open source projects
  are as diligent as ASF is.  So it is possible that OOo never did this
  before.  But if they did, we could reuse much of their paperwork.
 
  AFAIR Sun did that some time ago, but I'm not 100% sure.


 Yes, Sun did this (probably for every official release).


If so, this might have been kept on the corporate side, not on the
community website.

For example, searching Google for site:openoffice.org ECCN shows
several requests for this information [1] [2] [3] over the years, but
no useful responses.

Looks like LO discussed it briefly [4], but dismissed it under the
misapprehension that since they are not in the US, the regulation is
irrelevant.   We'll obviously want to do better here.  It may not make
a much of a difference to the individual downloaded of AOOo, but this
paperwork is essential for anyone who might want to bundle AOOo with
laptops, for example.  The location of the project is not the solitary
relevant fact.  The location of the users and re-distributors is the
key thing.

[1] http://openoffice.org/projects/www/lists/users/archive/2004-12/message/24

[2] 
http://openoffice.org/projects/marketing/lists/dev/archive/2005-11/message/204

[3] http://openoffice.org/projects/www/lists/users/archive/2009-12/message/653

[4] http://comments.gmane.org/gmane.comp.documentfoundation.discuss/6138

I'll check what we did for IBM Lotus Symphony.

-Rob


 Danese

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Please just do it this way:

 http://www.apache.org/dev/crypto.html

 ASF is very clear on what is required for *its* releases and this page 
 appears to be comprehensive.

The Apache rules break down into reporting to users and notification.
Informing users is important but notification is urgent (making source
available [1] counts as export).

 (I finally found where I saw this before.  It has also been discussed here or 
 on the ooo-private list before.  I remembered it as being simpler than it is.)

(It looks worse than it is)

Following the instructions[3], step 1 is to work out whether OOo has
any unusual cryptography beyond ECCN 5D002, which is:

blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
production or use of any of the other software of this list, or
software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
algorithm is based on: factorization of integers in excess of 512 bits
(e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
/blockquote

Does OOo rely on cryptography more exotic than this?

Robert

[1] http://www.apache.org/dev/crypto.html#overview
[2] http://www.apache.org/licenses/exports/
[3] http://www.apache.org/dev/crypto.html#classify

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 2:38 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Please just do it this way:

 http://www.apache.org/dev/crypto.html


That's what I've been looking at from the start.  I don't just make
these things up in my sleep.

 ASF is very clear on what is required for *its* releases and this page 
 appears to be comprehensive.


Yes, and for the very first step, we need to classify per an ECCN
code.  To do that we need to understand the cryptographic support the
code provides.

I think we should try to understand this in detail, even if it just
boils down ultimately to a code for this regulation.  These details
are also relevant to procurement regulations for the Federal
government, and other governments as well.  So it will be good have a
comprehensive list of what algorithms we are using in general.

-Rob

 (I finally found where I saw this before.  It has also been discussed here or 
 on the ooo-private list before.  I remembered it as being simpler than it is.)

  - Dennis


 -Original Message-
 From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
 Sent: Thursday, September 01, 2011 09:15
 To: ooo-dev@incubator.apache.org
 Subject: Re: Request dev help: Info for required crypto export declaration

 On Thu, Sep 1, 2011 at 11:51 AM, Danese Cooper dan...@gmail.com wrote:
 On Wed, Aug 31, 2011 at 9:30 AM, Rob Weir r...@robweir.com wrote:

 On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:



 snip



  1) Was something similar every done for OpenOffice.org?  Most software
  companies are aware of this US export regulation and do this
  declaration as a matter of routine.  But not all open source projects
  are as diligent as ASF is.  So it is possible that OOo never did this
  before.  But if they did, we could reuse much of their paperwork.
 
  AFAIR Sun did that some time ago, but I'm not 100% sure.


 Yes, Sun did this (probably for every official release).


 If so, this might have been kept on the corporate side, not on the
 community website.

 For example, searching Google for site:openoffice.org ECCN shows
 several requests for this information [1] [2] [3] over the years, but
 no useful responses.

 Looks like LO discussed it briefly [4], but dismissed it under the
 misapprehension that since they are not in the US, the regulation is
 irrelevant.   We'll obviously want to do better here.  It may not make
 a much of a difference to the individual downloaded of AOOo, but this
 paperwork is essential for anyone who might want to bundle AOOo with
 laptops, for example.  The location of the project is not the solitary
 relevant fact.  The location of the users and re-distributors is the
 key thing.

 [1] http://openoffice.org/projects/www/lists/users/archive/2004-12/message/24

 [2] 
 http://openoffice.org/projects/marketing/lists/dev/archive/2005-11/message/204

 [3] http://openoffice.org/projects/www/lists/users/archive/2009-12/message/653

 [4] http://comments.gmane.org/gmane.comp.documentfoundation.discuss/6138

 I'll check what we did for IBM Lotus Symphony.

 -Rob


 Danese

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
robertburrelldon...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 Please just do it this way:

 http://www.apache.org/dev/crypto.html

 ASF is very clear on what is required for *its* releases and this page 
 appears to be comprehensive.

 The Apache rules break down into reporting to users and notification.
 Informing users is important but notification is urgent (making source
 available [1] counts as export).

 (I finally found where I saw this before.  It has also been discussed here 
 or on the ooo-private list before.  I remembered it as being simpler than it 
 is.)

 (It looks worse than it is)

 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
 excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
 /blockquote

 Does OOo rely on cryptography more exotic than this?


That is where it seems backwards to me.  If I'm reading this
correctly, we are OK if we use a symmetrical algorithm with key length
greater than (in excess of) 56-bits.  But if we use an algorithm,
with less thanb 56-bits we're considered exotic?  Really?

For example, Calc has a ROT13() spreadsheet function, which
undoubtedly is a weak symmetrical encryption technique, certainly not
one with a key length in excess of 56-bits.

So what now?  In other words, I'm puzzled by the in excess part.
They seem to be saying that strong encryption is regulated less than
weak encryption.

Could you explain where I'm getting this wrong?

Thanks,

-Rob

 Robert

 [1] http://www.apache.org/dev/crypto.html#overview
 [2] http://www.apache.org/licenses/exports/
 [3] http://www.apache.org/dev/crypto.html#classify

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 Please just do it this way:

 http://www.apache.org/dev/crypto.html

 ASF is very clear on what is required for *its* releases and this page 
 appears to be comprehensive.

 The Apache rules break down into reporting to users and notification.
 Informing users is important but notification is urgent (making source
 available [1] counts as export).

 (I finally found where I saw this before.  It has also been discussed here 
 or on the ooo-private list before.  I remembered it as being simpler than 
 it is.)

 (It looks worse than it is)

 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
 excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
 /blockquote

 Does OOo rely on cryptography more exotic than this?


 That is where it seems backwards to me.  If I'm reading this
 correctly, we are OK if we use a symmetrical algorithm with key length
 greater than (in excess of) 56-bits.  But if we use an algorithm,
 with less thanb 56-bits we're considered exotic?  Really?

Remember that we're only interested in strong cryptography :-)

IIRC symmetric and asymmetric algorithms weaker than this are not
considered strong cryptography, and so don't fall under ECCN 5D002.
Cryptography which is neither weak nor covered by those definitions
needs special handling.

Robert

Re: Request dev help: Info for required crypto export declaration

2011-09-01 Thread Donald Whytock

On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
 excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
 /blockquote

 Does OOo rely on cryptography more exotic than this?


 That is where it seems backwards to me.  If I'm reading this
 correctly, we are OK if we use a symmetrical algorithm with key length
 greater than (in excess of) 56-bits.  But if we use an algorithm,
 with less thanb 56-bits we're considered exotic?  Really?

 For example, Calc has a ROT13() spreadsheet function, which
 undoubtedly is a weak symmetrical encryption technique, certainly not
 one with a key length in excess of 56-bits.

 So what now?  In other words, I'm puzzled by the in excess part.
 They seem to be saying that strong encryption is regulated less than
 weak encryption.

 Could you explain where I'm getting this wrong?


It looks to me like the key phrase is any unusual cryptography beyond
ECCN 5D002, and the definition of that phrase is the cited block, as
opposed to the cited block being a definition of ECCN 5D002.

I am having a remarkably hard time finding a definition of ECCN 5D002.

Don

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock dwhyt...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
 excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
 /blockquote

 Does OOo rely on cryptography more exotic than this?


 That is where it seems backwards to me.  If I'm reading this
 correctly, we are OK if we use a symmetrical algorithm with key length
 greater than (in excess of) 56-bits.  But if we use an algorithm,
 with less thanb 56-bits we're considered exotic?  Really?

 For example, Calc has a ROT13() spreadsheet function, which
 undoubtedly is a weak symmetrical encryption technique, certainly not
 one with a key length in excess of 56-bits.

 So what now?  In other words, I'm puzzled by the in excess part.
 They seem to be saying that strong encryption is regulated less than
 weak encryption.

 Could you explain where I'm getting this wrong?


 It looks to me like the key phrase is any unusual cryptography beyond
 ECCN 5D002, and the definition of that phrase is the cited block, as
 opposed to the cited block being a definition of ECCN 5D002.

 I am having a remarkably hard time finding a definition of ECCN 5D002.

EAR 740.13(e) should be on
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13

Robert

Re: Request dev help: Info for required crypto export declaration

So in general OpenOffice supports encryption and digital signatures
and https/SSL. So we have support for standard algorithms, from
one-way hashes like SHA-1, to block encryption like Blowfish and
AES-256, to public key cryptography per the W3C's XML Digital
Signatures. We also support legacy Microsoft Office encryption
algorithms that are generally weaker and used only for backwards
compatibility.

I'm not a crypto expert, so I'm not sure what something exotic would
look like. I think the strongest thing we have is AES-256.

-Rob

On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
robertburrelldon...@gmail.com wrote:
On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock dwhyt...@gmail.com wrote:
On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir r...@robweir.com wrote:
On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
robertburrelldon...@gmail.com wrote:
Following the instructions[3], step 1 is to work out whether OOo has
any unusual cryptography beyond ECCN 5D002, which is:

blockquote cite='http://www.apache.org/dev/crypto.html#classify
Software specially designed or modified for the development,
production or use of any of the other software of this list, or
software designed to certify other software on this list; or
Software using a symmetric algorithm employing a key length in
excess of 56-bits; or
Software using an asymmetric algorithm where the security of the
algorithm is based on: factorization of integers in excess of 512 bits
(e.g., RSA), computation of discrete logarithms in a multiplicative
group of a finite field of size greater than 512 bits (e.g.,
Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
/blockquote

Does OOo rely on cryptography more exotic than this?

That is where it seems backwards to me. If I'm reading this
correctly, we are OK if we use a symmetrical algorithm with key length
greater than (in excess of) 56-bits. But if we use an algorithm,
with less thanb 56-bits we're considered exotic? Really?

For example, Calc has a ROT13() spreadsheet function, which
undoubtedly is a weak symmetrical encryption technique, certainly not
one with a key length in excess of 56-bits.

So what now? In other words, I'm puzzled by the in excess part.
They seem to be saying that strong encryption is regulated less than
weak encryption.

Could you explain where I'm getting this wrong?

It looks to me like the key phrase is any unusual cryptography beyond
ECCN 5D002, and the definition of that phrase is the cited block, as
opposed to the cited block being a definition of ECCN 5D002.

I am having a remarkably hard time finding a definition of ECCN 5D002.

EAR 740.13(e) should be on
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13

Robert

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Let me see if I can help ground this.


Remember, the export could be of code, not just the binaries.  So if
we have code that does asymmetrical encryption, then we are exporting
that, even if in the binaries we call it only in the context of
digital signatures.  Or not.  That seems obvious to me, but IANAL

-Rob


 Currently, digest algorithms are used for a variety of things.  The common 
 case is SHA1.  These are not themselves a concern, as I understand it, since 
 their function is not directly related to encryption even though they come 
 into play in the use of encryption methods.

 There is no support for *document* *encryption* via asymmetric keys.  It is 
 not specified in ODF and there is no way to do it in current implementations 
 as far as I know.

 There is *password-based* *document* *encryption*.  The current default 
 procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using 
 HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB.  There are provisions, 
 for ODF 1.2, to generate wider keys and use PBKDF2 with rng methods other 
 than HMAC-SHA1.  Substitutes for PBKDF2 and Blowfish are allowed but I don't 
 know the status of any implementation-dependent variations in OpenOffice.org. 
  I believe there are extensions in the builds but they are not currently 
 enabled in the standard distributions.

 There is support for digital signatures using PKI methodologies and those do, 
 of course, use *asymmetric encryption* as part of the signature procedure.  
 We need to catalog what those flavors are that are accepted and that are 
 produced.  Implementations are allowed considerable license in this area and 
 we need to inventory the actual support in OpenOffice.org.

 It is not clear to me that the asymmetrical encryption used for digital 
 signatures is a concern, but it is useful to have all of these methods 
 profiled and catalogued concerning their implementation in OpenOffice.org.  
 Comprehensive profiling of digital signature provisions is required to ensure 
 interoperability in any case.

 I am not aware of any other cases. There are proposals for some modest but 
 valuable modifications in ODF 1.3 and as possible implementation-dependent 
 introductions in products supporting earlier versions of ODF.  Any such 
 implementations would need to be identified too, although none of those I am 
 aware of introduce additional encryption algoritms.

  - Dennis

 -Original Message-
 From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com]
 Sent: Thursday, September 01, 2011 12:14
 To: ooo-dev@incubator.apache.org
 Subject: Re: Request dev help: Info for required crypto export declaration

 On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 Please just do it this way:

 http://www.apache.org/dev/crypto.html

 ASF is very clear on what is required for *its* releases and this page 
 appears to be comprehensive.

 The Apache rules break down into reporting to users and notification.
 Informing users is important but notification is urgent (making source
 available [1] counts as export).

 (I finally found where I saw this before.  It has also been discussed here 
 or on the ooo-private list before.  I remembered it as being simpler than 
 it is.)

 (It looks worse than it is)

 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
 excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
 /blockquote

 Does OOo rely on cryptography more exotic than this?


 That is where it seems backwards to me.  If I'm reading this
 correctly, we are OK if we use a symmetrical algorithm with key length
 greater than (in excess of) 56-bits.  But if we use an algorithm,
 with less thanb 56-bits we're considered exotic?  Really?

 Remember that we're only interested in strong cryptography :-)

 IIRC symmetric and asymmetric algorithms weaker than this are not
 considered strong cryptography, and so don't fall under ECCN 5D002.
 Cryptography which

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 8:40 PM, Donald Whytock dwhyt...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 EAR 740.13(e) should be on
 http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13

 Robert


 Thanks, Robert.

 IANAL, but on that page I see reference to the phrase publicly
 available encryption source code.  ASF, by charter, is a repository
 of publicly available source code.  If OOo is officially an ASF
 project, does that take it out of the category of a product for export
 and into the category of publicly available source code?

As our source is publicly available, the TSU exception applies [1]

Robert

[1] http://www.apache.org/dev/crypto.html

RE: Request dev help: Info for required crypto export declaration

I'm not aware of any legacy encryption in non-ODF formats being supported on 
output or input.  I must try that.

Rob,

Is it your understanding that http is implemented directly in OpenOffice, or is 
the platform provider of http: and https: schemes relied upon?  I would be 
amazed to learn that OpenOffice.org deals with SSL certifications, but I guess 
I should be prepared for anything.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, September 01, 2011 12:32
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration

So in general OpenOffice supports encryption and digital signatures
and https/SSL.  So we have support for standard algorithms, from
one-way hashes like SHA-1, to block encryption like Blowfish and
AES-256,  to public key cryptography per the W3C's XML Digital
Signatures.   We also support legacy Microsoft Office encryption
algorithms that are generally weaker and used only for backwards
compatibility.

I'm not a crypto expert, so I'm not sure what something exotic would
look like.  I think the strongest thing we have is AES-256.

-Rob

On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin
robertburrelldon...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock dwhyt...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in
 excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).
 /blockquote

 Does OOo rely on cryptography more exotic than this?


 That is where it seems backwards to me.  If I'm reading this
 correctly, we are OK if we use a symmetrical algorithm with key length
 greater than (in excess of) 56-bits.  But if we use an algorithm,
 with less thanb 56-bits we're considered exotic?  Really?

 For example, Calc has a ROT13() spreadsheet function, which
 undoubtedly is a weak symmetrical encryption technique, certainly not
 one with a key length in excess of 56-bits.

 So what now?  In other words, I'm puzzled by the in excess part.
 They seem to be saying that strong encryption is regulated less than
 weak encryption.

 Could you explain where I'm getting this wrong?


 It looks to me like the key phrase is any unusual cryptography beyond
 ECCN 5D002, and the definition of that phrase is the cited block, as
 opposed to the cited block being a definition of ECCN 5D002.

 I am having a remarkably hard time finding a definition of ECCN 5D002.

 EAR 740.13(e) should be on
 http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13

 Robert

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 8:59 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Let me see if I can help ground this.

 Currently, digest algorithms are used for a variety of things.  The common 
 case is SHA1.  These are not themselves a concern, as I understand it, since 
 their function is not directly related to encryption even though they come 
 into play in the use of encryption methods.

AIUI only encryption is of concern

 There is no support for *document* *encryption* via asymmetric keys.  It is 
 not specified in ODF and there is no way to do it in current implementations 
 as far as I know.

Ok

 There is *password-based* *document* *encryption*.  The current default 
 procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using 
 HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB.  There are provisions, 
 for ODF 1.2, to generate wider keys and use PBKDF2 with rng methods other 
 than HMAC-SHA1.  Substitutes for PBKDF2 and Blowfish are allowed but I don't 
 know the status of any implementation-dependent variations in OpenOffice.org. 
  I believe there are extensions in the builds but they are not currently 
 enabled in the standard distributions.

Sounds likely to be strong cryptography falling under 'Software using
a symmetric algorithm employing a key length in excess of 56-bits'

 There is support for digital signatures using PKI methodologies and those do, 
 of course, use *asymmetric encryption* as part of the signature procedure.  
 We need to catalog what those flavors are that are accepted and that are 
 produced.  Implementations are allowed considerable license in this area and 
 we need to inventory the actual support in OpenOffice.org.

+1

 It is not clear to me that the asymmetrical encryption used for digital 
 signatures is a concern, but it is useful to have all of these methods 
 profiled and catalogued concerning their implementation in OpenOffice.org.  
 Comprehensive profiling of digital signature provisions is required to ensure 
 interoperability in any case.

+1

 I am not aware of any other cases. There are proposals for some modest but 
 valuable modifications in ODF 1.3 and as possible implementation-dependent 
 introductions in products supporting earlier versions of ODF.  Any such 
 implementations would need to be identified too, although none of those I am 
 aware of introduce additional encryption algoritms.

So far, looks like OOo most likely has strong crypto but it's all
fairly standard stuff. We should press forward with the notification
required by law whilst auditing the code.

Robert

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 9:03 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 Let me see if I can help ground this.


 Remember, the export could be of code, not just the binaries.  So if
 we have code that does asymmetrical encryption, then we are exporting
 that, even if in the binaries we call it only in the context of
 digital signatures.  Or not.  That seems obvious to me, but IANAL

Also code intended to work with cryptography libraries (whether shipped or not)

Robert

RE: Request dev help: Info for required crypto export declaration

I am not making a judgment in the case of encryption used as part of 
digital-signature PKI-based methods.  We need to identify them regardless.  

I also don't know if those particular encryptions are done in OpenOffice.org 
code or are handled by the platforms at runtime.  This might vary depending on 
the platform.  We need to comprehend such variations for interoperability 
purposes as well.

 - Dennis

-Original Message-
From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
Sent: Thursday, September 01, 2011 13:03
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Let me see if I can help ground this.


Remember, the export could be of code, not just the binaries.  So if
we have code that does asymmetrical encryption, then we are exporting
that, even if in the binaries we call it only in the context of
digital signatures.  Or not.  That seems obvious to me, but IANAL

-Rob


 Currently, digest algorithms are used for a variety of things.  The common 
 case is SHA1.  These are not themselves a concern, as I understand it, since 
 their function is not directly related to encryption even though they come 
 into play in the use of encryption methods.

 There is no support for *document* *encryption* via asymmetric keys.  It is 
 not specified in ODF and there is no way to do it in current implementations 
 as far as I know.

 There is *password-based* *document* *encryption*.  The current default 
 procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using 
 HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB.  There are provisions, 
 for ODF 1.2, to generate wider keys and use PBKDF2 with rng methods other 
 than HMAC-SHA1.  Substitutes for PBKDF2 and Blowfish are allowed but I don't 
 know the status of any implementation-dependent variations in OpenOffice.org. 
  I believe there are extensions in the builds but they are not currently 
 enabled in the standard distributions.

 There is support for digital signatures using PKI methodologies and those do, 
 of course, use *asymmetric encryption* as part of the signature procedure.  
 We need to catalog what those flavors are that are accepted and that are 
 produced.  Implementations are allowed considerable license in this area and 
 we need to inventory the actual support in OpenOffice.org.

 It is not clear to me that the asymmetrical encryption used for digital 
 signatures is a concern, but it is useful to have all of these methods 
 profiled and catalogued concerning their implementation in OpenOffice.org.  
 Comprehensive profiling of digital signature provisions is required to ensure 
 interoperability in any case.

 I am not aware of any other cases. There are proposals for some modest but 
 valuable modifications in ODF 1.3 and as possible implementation-dependent 
 introductions in products supporting earlier versions of ODF.  Any such 
 implementations would need to be identified too, although none of those I am 
 aware of introduce additional encryption algoritms.

  - Dennis

 -Original Message-
 From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com]
 Sent: Thursday, September 01, 2011 12:14
 To: ooo-dev@incubator.apache.org
 Subject: Re: Request dev help: Info for required crypto export declaration

 On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir r...@robweir.com wrote:
 On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 Please just do it this way:

 http://www.apache.org/dev/crypto.html

 ASF is very clear on what is required for *its* releases and this page 
 appears to be comprehensive.

 The Apache rules break down into reporting to users and notification.
 Informing users is important but notification is urgent (making source
 available [1] counts as export).

 (I finally found where I saw this before.  It has also been discussed here 
 or on the ooo-private list before.  I remembered it as being simpler than 
 it is.)

 (It looks worse than it is)

 Following the instructions[3], step 1 is to work out whether OOo has
 any unusual cryptography beyond ECCN 5D002, which is:

 blockquote cite='http://www.apache.org/dev/crypto.html#classify
   Software specially designed or modified for the development,
 production or use of any of the other software of this list, or
 software designed to certify other software on this list; or
   Software using a symmetric algorithm employing a key length in
 excess of 56-bits; or
   Software using an asymmetric algorithm where the security of the
 algorithm is based on: factorization of integers in excess of 512 bits
 (e.g., RSA), computation of discrete logarithms in a multiplicative
   group of a finite field of size greater than 512 bits (e.g.,
 Diffie-Hellman over Z/pZ

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 4:11 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
I'm not aware of any legacy encryption in non-ODF formats being supported
on output or input. I must try that.

Rob,

Is it your understanding that http is implemented directly in OpenOffice, or
is the platform provider of http: and https: schemes relied upon? I would be
amazed to learn that OpenOffice.org deals with SSL certifications, but I
guess I should be prepared for anything.

It is still declarable even if we are simply enabled for using a 3rd
party service. So, for example, if we make calls into an OS-level URL
protocol handler that negotiates SSL for https URL's, then that would
count. That is my reading of it.

- Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Thursday, September 01, 2011 12:32
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration

I'm not a crypto expert, so I'm not sure what something exotic would
look like. I think the strongest thing we have is AES-256.

-Rob

Does OOo rely on cryptography more exotic than this?

For example, Calc has a ROT13() spreadsheet function, which
undoubtedly is a weak symmetrical encryption technique, certainly not
one with a key length in excess of 56-bits.

So what now? In other words, I'm puzzled by the in excess part.
They seem to be saying that strong encryption is regulated less than
weak encryption.

Could you explain where I'm getting this wrong?

It looks to me like the key phrase is any unusual cryptography beyond
ECCN 5D002, and the definition of that phrase is the cited block, as
opposed to the cited block being a definition of ECCN 5D002.

I am having a remarkably hard time finding a definition of ECCN 5D002.

EAR 740.13(e) should be on
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13

Robert

RE: Request dev help: Info for required crypto export declaration

Technically, this was to have been resolved before the code was put up on SVN.  
We need to audit specifically for this rather quickly, and including the places 
that Rob also identified (import-export filters and http TLS). 

 - Dennis

-Original Message-
From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com] 
Sent: Thursday, September 01, 2011 13:13
To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: Request dev help: Info for required crypto export declaration

[ ... ]

So far, looks like OOo most likely has strong crypto but it's all
fairly standard stuff. We should press forward with the notification
required by law whilst auditing the code.

Robert

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Technically, this was to have been resolved before the code was put up on 
 SVN.  We need to audit specifically for this rather quickly, and including 
 the places that Rob also identified (import-export filters and http TLS).

I definitely recommend a full crypto audit but IIRC it's not necessary
before sending the initial notification.

AIUI (from [1] and [2]) all that's needed is a list of the
cryptographic libraries used by OOo. If the results of the full audit
differ then we can just update the details and send an updated
notification.

Robert

[1] http://www.apache.org/dev/crypto.html#sources
[2] http://www.apache.org/licenses/exports/

RE: Request dev help: Info for required crypto export declaration

From http://www.apache.org/dev/crypto.html top of page, Overview, second 
paragraph:

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 [*emphasis* mine]

From http://incubator.apache.org/guides/mentor.html#crypto-audit
Before the code base is committed into an Apache repository, the contribution 
MUST be checked and any restricted cryptography reported appropriately.

-Original Message-
From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com] 
Sent: Thursday, September 01, 2011 14:01
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 Technically, this was to have been resolved before the code was put up on 
 SVN.  We need to audit specifically for this rather quickly, and including 
 the places that Rob also identified (import-export filters and http TLS).

I definitely recommend a full crypto audit but IIRC it's not necessary
before sending the initial notification.

AIUI (from [1] and [2]) all that's needed is a list of the
cryptographic libraries used by OOo. If the results of the full audit
differ then we can just update the details and send an updated
notification.

Robert

[1] http://www.apache.org/dev/crypto.html#sources
[2] http://www.apache.org/licenses/exports/

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 7:01 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 From http://www.apache.org/dev/crypto.html top of page, Overview, second 
 paragraph:

 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 [*emphasis* 
 mine]

 From http://incubator.apache.org/guides/mentor.html#crypto-audit
 Before the code base is committed into an Apache repository, the 
 contribution MUST be checked and any restricted cryptography reported 
 appropriately.


Yup.  We did this in the wrong order.  Nothing we can do about that now.

I hope to get to this soon, but probably not until the weekend at
earliest.  If you (or anyone else) have cycles earlier, feel free to
grab this task.   I don't mean to be sitting on it if someone else can
act sooner.


-Rob


 -Original Message-
 From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com]
 Sent: Thursday, September 01, 2011 14:01
 To: ooo-dev@incubator.apache.org
 Subject: Re: Request dev help: Info for required crypto export declaration

 On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 Technically, this was to have been resolved before the code was put up on 
 SVN.  We need to audit specifically for this rather quickly, and including 
 the places that Rob also identified (import-export filters and http TLS).

 I definitely recommend a full crypto audit but IIRC it's not necessary
 before sending the initial notification.

 AIUI (from [1] and [2]) all that's needed is a list of the
 cryptographic libraries used by OOo. If the results of the full audit
 differ then we can just update the details and send an updated
 notification.

 Robert

 [1] http://www.apache.org/dev/crypto.html#sources
 [2] http://www.apache.org/licenses/exports/

Re: Request dev help: Info for required crypto export declaration

2011-09-01 Thread Norbert Thiebaud

On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote:

 Looks like LO discussed it briefly [4], but dismissed it under the
 misapprehension that since they are not in the US, the regulation is
 irrelevant.

I'm confused, how is that a 'misapprehension' exactly ?

Are you concerned about compliance with
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109
?

if not, why not ? are you under the misapprehension that since [you]
are not in [France], the regulation is irrelevant. ?

Norbert

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud nthieb...@gmail.com wrote:
 On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote:

 Looks like LO discussed it briefly [4], but dismissed it under the
 misapprehension that since they are not in the US, the regulation is
 irrelevant.

 I'm confused, how is that a 'misapprehension' exactly ?

 Are you concerned about compliance with
 http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109
 ?

 if not, why not ? are you under the misapprehension that since [you]
 are not in [France], the regulation is irrelevant. ?


You should take a look at the Wassenaar convention.  There is a lot
more similarity than you might think between French and US
requirements.  The diligence you do to satisfy US regulations will
also help you with the regulations in any other countries you, or your
users, need to work with.

http://www.wassenaar.org/

 Norbert

RE: Request dev help: Info for required crypto export declaration

I think Article 32 is of particular interest in the case of OpenOffice.org 
distributions in France.

It would appear that compliance with Article 30 is not difficult, since source 
code is available in all cases.  It would be interesting to find out if the 
Apache process for declaring cryptographic provisions would be acceptable to 
the Prime Minister without further ceremony.  It might be useful for us to 
package notice of where the details are found in future distributions so users 
could be aware that local conditions may apply to their use of such provisions.

However, I think it is likely that, so long as the LibreOffice download sites 
are not in the US there is not an issue for TDF.  If there are LibreOffice 
mirrors in the US, that might be reason for concern by the operators of the 
mirrors.  But we don't get to resolve any of that here.

It is clear that to be an Apache Software Foundation project, the US 
requirements must be satisfied in the manner specified by the ASF.  

 - Dennis 

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com] 
Sent: Thursday, September 01, 2011 18:38
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote:

 Looks like LO discussed it briefly [4], but dismissed it under the
 misapprehension that since they are not in the US, the regulation is
 irrelevant.

I'm confused, how is that a 'misapprehension' exactly ?

Are you concerned about compliance with
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109
?

if not, why not ? are you under the misapprehension that since [you]
are not in [France], the regulation is irrelevant. ?

Norbert

Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 10:18 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
I think Article 32 is of particular interest in the case of OpenOffice.org
distributions in France.

It would appear that compliance with Article 30 is not difficult, since
source code is available in all cases. It would be interesting to find out
if the Apache process for declaring cryptographic provisions would be
acceptable to the Prime Minister without further ceremony. It might be
useful for us to package notice of where the details are found in future
distributions so users could be aware that local conditions may apply to
their use of such provisions.

However, I think it is likely that, so long as the LibreOffice download sites
are not in the US there is not an issue for TDF. If there are LibreOffice
mirrors in the US, that might be reason for concern by the operators of the
mirrors. But we don't get to resolve any of that here.

It is clear that to be an Apache Software Foundation project, the US
requirements must be satisfied in the manner specified by the ASF.

But I think that misses the real value of having this paperwork clean
and readily available. It isn't really about OpenOffice or
LibreOffice end users. And it really isn't about Apache or The
Document Foundation. Yes, it is partially about them. But the real
point of doing this and doing it well, is to make it possible for
others (not Apache and not end users or direct downloads) to
distribute/export Apache code. It is to allow Apache modules to be
embedded in other applications and then exported. It is to allow
OpenOffice.org to be pre-installed on a hardware vendor's laptops and
then exported. Pure open source gets off easy in the regulation this
days. The government realizes that the code is out there and they
accept that. But commercial software vendors and hardware vendors
still feel the full weight of these regulations. Having open source
components that have their export control paperwork in order makes
their lives much easier, and helps the underlying open source software
get used more, which in turn may drive more corporate-sponsored
developers into the project, more opportunities for consultants, etc.
It is part of making OSS easy to consume. It is a win-win situation.

-Rob

- Dennis

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com]
Sent: Thursday, September 01, 2011 18:38
To: ooo-dev@incubator.apache.org
Subject: Re: Request dev help: Info for required crypto export declaration

On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote:

Looks like LO discussed it briefly [4], but dismissed it under the
misapprehension that since they are not in the US, the regulation is
irrelevant.

I'm confused, how is that a 'misapprehension' exactly ?

Are you concerned about compliance with
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109
?

if not, why not ? are you under the misapprehension that since [you]
are not in [France], the regulation is irrelevant. ?

Norbert

Re: Request dev help: Info for required crypto export declaration

2011-09-01 Thread Norbert Thiebaud

On Thu, Sep 1, 2011 at 8:57 PM, Rob Weir robw...@apache.org wrote:
On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud nthieb...@gmail.com wrote:
On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote:

Looks like LO discussed it briefly [4], but dismissed it under the
misapprehension that since they are not in the US, the regulation is
irrelevant.

I'm confused, how is that a 'misapprehension' exactly ?

Are you concerned about compliance with
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109
?

if not, why not ? are you under the misapprehension that since [you]
are not in [France], the regulation is irrelevant. ?

You should take a look at the Wassenaar convention. There is a lot
more similarity than you might think between French and US
requirements.

You're missing the point. The point is: it makes a lot of sens of
Apache, being legally established in the US, to comply with the export
regulation of its host country...
but claiming that not paying attention to US regulation for a
non-US-based entity is a 'misapprehension' does not make much sens to
me. 'France' here was just a convenient example to illustrate the
fallacy of the argument. one could find hundreds of jurisdictions with
each their own hoops and quirks... most likely some of them
contradicting each others.

The diligence you do to satisfy US regulations will
also help you with the regulations in any other countries you, or your
users, need to work with.

The French term that best describe this vision of the world is
'nombrilism' (I'm afraid the english translation doesn't quite does it
justice.. too literal, doesn't carry the larger meaning, I think)

Norbert

Re: Request dev help: Info for required crypto export declaration