Encryption and Algorithms

[Berin Lautenbach <be...@ozemail.com.au>]

Peoples,

Following on from Axl's comments RE encryption the other day, I'd like 
to put a note into general@xml (and possibly board@) asking for guidance 
on two fronts.

1.  Encryption.  Until now everything has been signatures, which is 
fairly benign.  Is there anything we need to be doing from a legal front 
to cover Apache when we get into encryption?

2.  RSA.  In my digging around last night I unearthed the patent issues 
around RSA that were discussed in incubator-general when OpenSAML was 
proposed.  Both C++ and Java libraries provide support for RSA 
signatures (although neither implements RSA directly).

On 1 - I don't believe the Java library actually implements any crypto 
code, and the C++ library definately doesn't.  Both use hooks into 
existing libraries.  However, there can still be issues with hooks so it 
would be good to cover off.

On 2 - I'm hoping this is not a _big_ can of worms, but I'd prefer to 
raise it and sort it out (even if it potentialy means disabling RSA 
support) than leave it and get caught out later.

See :

http://marc.theaimsgroup.com/?l=incubator-general&w=2&r=1&s=OpenSAML&q=b

for the thread on OpenSAML and RSA.  I saw some of this on the periphery 
a few months back, but never put two and two together.

Thoughts?  Maybe this has all been discussed and sorted out pre my time?

Cheers,
     Berin

RE: Encryption and Algorithms

[Scott Cantor <ca...@osu.edu>]

I would guess that if your plan for the C++ version is to continue using OpenSSL or whatever for the actual encryption algorithms,
and don't distribute that code yourself, you shouldn't need to worry.

-- Scott

Re: Encryption and Algorithms

[Axl Mattheus <ax...@sun.com>]

Berin, Et al.

Here is the scoop with signature vs encryption. Signature is considered 
authentication. Authentication is not subject to export 
constraints/controls. It is not considered a weapon by some countries. 
Encryption on the other hand, even if you do not write any encryption 
code yourself, are for the most part considered military "hardware", 
especially in a prominent country. This has the potential to make 
lawyers and other "agencies" nervous. For instance, a certain company, 
(one that has a UNIX operating system, does RISC based hardware, and is 
big in Java and the Internet...) had no issues to ship a RSA signature 
implementation. On the other hand - it only got "permission" to ship an 
RSA cryptographic library a while ago. Why? Nervous lawyers, that is why.

Now, my domicilium is not in a country that thinks of ICBM's, 
submarines, bombs, SAM's and encryption software as weapons. However, 
some of the audience is. And the software that Apache ships (electronic 
distribution via the Internet) are most probably shipped from within the 
borders of countries that does view tanks, fighter jets, grenades, 
anti-personnel mines and encryption software as weapons. My guess is, in 
view of the current global situation (hell, I should be a 
politician...), that the ASF should make sure that a bunch of highly 
trained people, wearing identical black suits and sun glasses does not 
unplug our beloved FreeBSD boxes that holds all that is holy to us 
(free, open-source software) just because we are illegally selling 
weapons, or stuff that could be considered weapons...

Peace, your (nervous) friend.

Axl-Jürgen Mattheus


Berin Lautenbach wrote:

> Peoples,
>
> Following on from Axl's comments RE encryption the other day, I'd like 
> to put a note into general@xml (and possibly board@) asking for 
> guidance on two fronts.
>
> 1.  Encryption.  Until now everything has been signatures, which is 
> fairly benign.  Is there anything we need to be doing from a legal 
> front to cover Apache when we get into encryption?
>
> 2.  RSA.  In my digging around last night I unearthed the patent 
> issues around RSA that were discussed in incubator-general when 
> OpenSAML was proposed.  Both C++ and Java libraries provide support 
> for RSA signatures (although neither implements RSA directly).
>
> On 1 - I don't believe the Java library actually implements any crypto 
> code, and the C++ library definately doesn't.  Both use hooks into 
> existing libraries.  However, there can still be issues with hooks so 
> it would be good to cover off.
>
> On 2 - I'm hoping this is not a _big_ can of worms, but I'd prefer to 
> raise it and sort it out (even if it potentialy means disabling RSA 
> support) than leave it and get caught out later.
>
> See :
>
> http://marc.theaimsgroup.com/?l=incubator-general&w=2&r=1&s=OpenSAML&q=b
>
> for the thread on OpenSAML and RSA.  I saw some of this on the 
> periphery a few months back, but never put two and two together.
>
> Thoughts?  Maybe this has all been discussed and sorted out pre my time?
>
> Cheers,
>     Berin
>
>