At 07:59 AM 11/29/99 , Leland V. Lammert wrote:
>I, for one, would be most interested if you can comment on (or add to) the
>following options as I see them for a US based company that wishes to
>build a SSL-based web server:
>
>1) Purchase an Apache like Stronghold (at $1K+ not an option for a small
>company). Completely legal in the US?
>
>2) Build Apache with OpenSSL (or, as we did three years ago, with SSLeay).
>Legal for non-commercial purposes in the US and questionable for e-commerce?
>
>3) Purchase the RedHat Secure Server (as I commented earlier), .. though I
>did not think to phrase that I was advocating using the RH SSL binaries
>and linking to a standard Apache (which I have been told is completely
>legal). Legal, but may be problematic merging standard Apache and RH
>implementations?
>
>4) Install OpenBSD (though we have not used it, it appears to have the SSL
>libraries built-in). Legal status unknown?
>
>Since it is not practical for a small company to deal directly with RSA
>(or the like), our only option at the time seemed to be #2, as the server
>was initially a 'test site'. We need to rebuild the server in the near
>future, .. and I would be very interested in pros and cons.
The easiest way to get to the center of this Gordian knot is to identify
what you need, and identify where you're getting it, and under which terms.
If you're going to use the RSA public key crypto algorithm inside the
United States between now and September 20 of 2000, you need a license to
do so. (It doesn't matter if your use is "commercial" or "noncommercial" or
whatever else - you need a license.)
You can only get a license from RSA, or someone to whom they've given the
right to sublicense. The latter includes several Apache-derivative vendors
including Covalent, Red Hat, and C2Net. Note that it's very, very unlikely
that the terms of the sublicense grant given to any of the above
sublicensors allows them to bless any arbitrary use of the RSA algorithm,
but it's very likely that their right to sublicense users of the patent is
limited to specific named products or product lines. If one of the vendors
tells you they have the right to grant a patent license good for any
program or device which uses the RSA public key method, ask to see a copy
of the original license grant from RSA to that effect, as you're probably
talking to someone full of too much eggnog.
Another way to get a license to use the RSA public key method is to use the
RSAREF library, which includes a license grant to use the method when
that's done by calling the RSAREF library. RSAREF licenses are only
available on certain terms, and you'll need to figure out whether or not
your use is compatible with the RSAREF license.
It's that simple - you need to identify the source of your right to use the
algorithm, and look at the license restrictions accompanying the grant of
that right. If you can't identify the grant, you probably don't have a
patent license. All of the RSA license grants that I've seen have required
the licensee to mark their product with a notation that it uses (and has
licensed) the RSA patent from RSA, I don't know if the commercial vendors
now operating are subject to that restriction, or if they're complying if
they are subject to it.
Regarding your choices listed above - number 3 doesn't work if you're
thinking of the "buy server X, run server Y, but 'using the license from
X'" theory, but it does work if you use server X as an SSL proxy for a
plain Apache (where the plaintext appears only on your local network), or
if you use server X only to handle pages which must be encrypted (like,say,
the page(s) which accept credit card numbers or sensitive information) with
the other pages served by a generic Apache. Since http and https use
different port numbers, it's easy to have the two servers running on one
physical machine reading the same document tree, for relatively seamless
(and legal) integration.
Also, apropros your #1, you might look at Covalent's Raven server, which is
$357. <http://www.covalent.net/raven/ssl/>.
--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]