Dain Sundstrom wrote:
On Aug 30, 2005, at 4:42 PM, David Jencks wrote:
On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
On 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
In Apache Geronino and dependencies like OpenEJB, (and probably other
projects at the ASF...) we are using an external project known as
'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
implementation of crypto-related stuff in Java.
Inside the distro jar from bouncycastle is an implementation of the
IDEA algorithm. This algorithm is patented, and the patent holder,
MediaCrypt, requires licenses for all implementations of IDEA, and
there's no unfettered use - even non-commercial distribution requires
some kind of correspondence with MediaCrypt.
http://www.mediacrypt.com/
You have to find the license section...
So, here's the problem - I don't believe either Geronimo or OpenEJB
is using the algorithm explicitly but I can't be sure that it isn't
invoked somewhere, and statements from the MediaCrypt site such as
"Requests by freeware developers to obtain a royalty-free license to
spread an application program containing the algorithm not for
commercial purposes must be directed to MediaCrypt"
make me believe that we have to do something to redistribute this
software.
(I can't help noting how the infinitive "to spread" makes the GPL's
language on "distribution" look clear.. :)
Of course, there are other terms for commercial users.
So, what should we do?
How about asking the Bouncy Castle people for some advice on what to
do? They're distributing the artifacts affected by these statements
from MediaCrypt, what do they recommend to their user base regarding
redistribution and use?
Good idea. Alternatively for our use, it looks like the directory
project has its own asn1 implementation. IIUC that is all we use in
the openejb corba code. Can we sidestep this problem by using the
directory's asn1 implementation?
Kresten, does the proposed Trifork ORB donation include the asn1 code
necessary for CORBA security?
I've been digging through the code trying to understand how/why the asn1
code is getting used. It appears the BC code is just being used to
encode/decode X509 names for transport-level security. This is done in
two places:
1) the mech_oid field in the SECIOP_SEC_TRANS structure, and
2) SAS_ContextSec supported_naming_mechanisms array.
These fields are just defined as opaque byte[] items, so I suspect any
encoding is acceptable as long as it is used symmetrically. The BC asn1
support has APIs for encoding/decoding X509 names, so it was convenient
to use here. There does not appear to be any crypto engine involvement
in this process.
It appears the need here is not for asn1 support, but rather the ability
to consistently encode OIDs which are in an X509 name format.
-dain
