Re: Question on export issues

2008-01-07 Thread Sidney Markowitz

Ivan Krsti? wrote, On 6/1/08 1:33 PM:

On Jan 3, 2008, at 10:47 PM, Peter Gutmann wrote:

That's because there's nothing much to publish:
In the US, notify the BIS via email.


Our outside counsel -- specializing in this area -- thought this was  
insufficient


That's the problem with using lawyers, they'll always give you a conservative cautious 
answer. Unfortunately for people who don't use them, sometimes those really are the 
correct, prudent answers. When I worked for a company that had to face this we acted 
according to what looked like the plain language documentation from the BIS, concluding 
that use of an existing open source package required just sending an email. We were never 
as high profile as OLPC and in fact never ended up exporting anything, so our 
interpretation of the laws was not only not made by qualified legal counsel, it also was 
never tested.


I do look forwrd to seeing what you discover were the considerations that your outide 
counsel had.


 -- sidney

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2008-01-06 Thread Ivan Krstić

On Jan 3, 2008, at 10:47 PM, Peter Gutmann wrote:

That's because there's nothing much to publish:
In the US, notify the BIS via email.


Our outside counsel -- specializing in this area -- thought this was  
insufficient. That said, thanks for all the feedback in the thread --  
I'll pass the information back and try to figure out what the  
difficulties were, posting here if anything interesting becomes  
illuminated.


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2008-01-04 Thread Peter Gutmann
=?UTF-8?Q?Ivan_Krsti=C4=87?= [EMAIL PROTECTED] writes:

4) Essentially all open source projects use the TSU licensing exception.

5) Essentially none of them publish the details of their experience of the
process of satisfying the export control requirements.

That's because there's nothing much to publish:

In the US, notify the BIS via email.
Outside the US, just export away.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2008-01-03 Thread Alan

On Sun, 2007-12-30 at 08:30 -0500, Richard Salz wrote:
 In my personal experience, if you are developing a mass-market item with 
 conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to 
 get a commodity export license which lets you sell globally.
 
 Disclaimers abound, including that I'm not a lawyer and certainly don't 
 speak for IBM.

My question was more on the lines of what gets rejected, not what
does it take to do it.

Is there some technology that they are so afraid of that they still
won't let it ship or does it just matter who you are, not what it is?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2008-01-03 Thread Richard Salz
 Is there some technology that they are so afraid of that they still
 won't let it ship or does it just matter who you are, not what it is?

I wouldn't know for sure, but I am sure that who is asking permission does 
matter.

/r$, sounding like his idol dan :)

--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2008-01-02 Thread Florian Weimer
* Ivan Krstić:

 We've recently had to jump through the BIS crypto export hoops at
 OLPC. Our systems both ship with crypto built-in and, due to their
 Fedora underpinnings, allow end-user installation of various crypto
 libraries -- all open-source -- through our servers. It was a
 nightmare; the regulations and paperwork appear to be designed for the
 use case of individual applications that utilize a handful of
 primitives and attempt to keep the user from examining or modifying
 the utilized crypto. Trying to fit a Linux distribution into this
 model proved, er, challenging.

Debian has been filing notices for crypto export for years (at BXA for
some time; nowadays, it's likely BIS).  So far, nobody there has
complained that what is being done is insufficient.

Here are some details: http://www.debian.org/legal/cryptoinmain
The actual process may have changed a bit over the years.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2007-12-31 Thread Ivan Krstić

On Dec 30, 2007, at 12:06 AM, [EMAIL PROTECTED] wrote:

never be permitted to export to the embargoed country
list (Cuba, Iran, Sudan, Syria, North Korea, and Libya).



Not Libya. See 15 C.F.R §740Spir[0], country group E: Cuba, Iran,  
North Korea, Sudan, Syria.


Interestingly, 15 C.F.R. §746.8[1] also lists Rwanda: an embargo  
applies to the sale or supply to Rwanda of arms and related matériel  
of all types and regardless of origin, including weapons and  
ammunition. I am not a lawyer, and cannot tell whether this applies  
to encryption.


We've recently had to jump through the BIS crypto export hoops at  
OLPC. Our systems both ship with crypto built-in and, due to their  
Fedora underpinnings, allow end-user installation of various crypto  
libraries -- all open-source -- through our servers. It was a  
nightmare; the regulations and paperwork appear to be designed for the  
use case of individual applications that utilize a handful of  
primitives and attempt to keep the user from examining or modifying  
the utilized crypto. Trying to fit a Linux distribution into this  
model proved, er, challenging. (We also found that projects that we  
expected would know the drill cold, such as Fedora and Mozilla, were  
actually not very familiar with the processes involved.)


Cheers,
Ivan.



[0] http://www.access.gpo.gov/bis/ear/pdf/740spir.pdf
[1] http://www.access.gpo.gov/bis/ear/pdf/746.pdf

--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2007-12-31 Thread Sidney Markowitz
Ivan Krsti? wrote, On 31/12/07 12:48 PM:
 We've recently had to jump through the BIS crypto export hoops at  
 OLPC

I find that very strange considering this from a BIS FAQ
http://www.bis.doc.gov/encryption/encfaqs6_17_02.html

all encryption source code that would be considered publicly available under 
Section
734.3(b)(3) of the EAR (such as source code posted to the Internet) and the 
corresponding
object code may be exported and reexported under License Exception TSU -- 
Technology and
Software Unrestricted (specifically, Section 740.13(e) of the EAR), once 
notification (or
a copy of the source code) is provided to BIS and the ENC Encryption Request 
Coordinator.

What hoops did you have to jump through?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Question on export issues

2007-12-30 Thread dan

Alan writes:
-+
 | What are the rules these days on crypto exports.  Is a review
 | still required?  If so, what gets rejected?
 | 

The following is a recent interaction with specialty
export counsel, though somewhat modified as I detoxed
it from base64 to ASCII plaintext and from infinite
line length to fixed line length.

When you file, you have immediate permission to export
to, essentially, the anglophone democracies and western
Europe.  If you have heard nothing in 30 days elapsed
time, you are then free to export generally but you will
never be permitted to export to the embargoed country
list (Cuba, Iran, Sudan, Syria, North Korea, and Libya).

YMMV.

--dan



-8cut-here8-

A. BIS Checklist of Questions:

1. Does your product perform cryptography, or otherwise
contain any parts or components that are capable of performing
any of the following information security functions?
 
(Mark with an X all that apply)
 
a.  _  encryption
b.  _  decryption only (no encryption)
c.  _  key management / public key infrastructure (PKI)
d.  _  authentication (e.g., password protection, digital signatures)
e.  _  copy protection
f.  _  anti-virus protection
g.  _  other  (please explain) : ___
h.  _  NONE / NOT APPLICABLE
 
2. For items with encryption, decryption and/or key management
functions (1.a, 1.b, 1.c above):

a. What symmetric algorithms and key lengths (e.g., 56-bit
DES, 112 / 168-bit Triple-DES, 128 / 256-bit AES / Rijndael) are
implemented or supported?

b. What asymmetric algorithms and key lengths (e.g., 512-bit
RSA / Diffie-Hellman, 1024 / 2048-bit RSA / Diffie-Hellman) are
implemented or supported?

c. What encryption protocols (e.g., SSL, SSH, IPSEC or PKCS
standards) are implemented or supported?
 
d. What type of data is encrypted?

B. BIS Review Requirements for Form 748-P.  If any inquiry
is not applicable, please state N/A.
 
(a) State the name of the encryption item being submitted for review.
 
 i. Enter the name of the manufacturer of the software.
 ii. Provide a brief technical description of the basic purpose
 to be served by the encryption;
 iii. Provide a brief description of the type of encryption used
 in the software; e.g., 168-bit Triple DES for xyz purpose, and
 1024-bit RSA for abc purpose.
 
(b) You would also need to provide brochures or other
documentation as well as specifications related to the software,
relevant product descriptions, architecture specifications and,
if required by BIS, source code.  You must also indicate whether
there have been any prior reviews of the product, if such
reviews are applicable to the current submission.  In addition,
you must provide the following information in a cover letter
accompanying your review request:

 (1) Description of all the symmetric and asymmetric encryption
 algorithms and key lengths and how the algorithms are used.
 Specify which encryption modes are supported (e.g., cipher
 feedback mode or cipher block chaining mode).

 (2) State the key management algorithms, including modulus
 sizes, that are supported.

 (3) For products with proprietary algorithms, include a textual
 description and the source code of the algorithm.

 (4) Describe the pre-processing methods (e.g., data compression
 or data interleaving) that are applied to the plaintext data
 prior to encryption.

 (5) Describe the post-processing methods (e.g., packetization,
 encapsulation) that are applied to the cipher text data after
 encryption.

 (6) State the communication protocols (e.g., X.25, Telnet or
 TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS
 standards) that are supported.

 (7) Describe the encryption-related Application Programming
 Interfaces (APIs) that are implemented and/or supported.
 Explain which interfaces are for internal (private) and/or
 external (public) use.
  
 (8) Describe the cryptographic functionality that is provided
 by third-party hardware or software encryption components (if
 any).  Identify the manufacturers of the hardware or software
 components, including specific part numbers and version
 information as needed to describe the product.  Describe whether
 the encryption software components (if any) are statically or
 dynamically linked.

 (9) For commodities or software using Java byte code, describe
 the techniques (including obfuscation, private access modifiers
 or final classes) that are used to protect against decompilation
 and misuse.

 (10) State how the product is written to preclude user
 modification of the encryption algorithms, key management and
 key space.

 (11) For products which incorporate an open cryptographic
 interface as defined in part 772 of the EAR, describe the Open
 Cryptographic Interface.
  
 (12) We must provide sufficient information for BIS to
 determine whether the software qualifies for mass market
 consideration.  The regulations offer examples 

Re: Question on export issues

2007-12-30 Thread Richard Salz
In my personal experience, if you are developing a mass-market item with 
conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to 
get a commodity export license which lets you sell globally.

Disclaimers abound, including that I'm not a lawyer and certainly don't 
speak for IBM.

/r$

--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]