No Subject
__ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Commercial SSL in the US
Rich Salz wrote: > > I don't know exactly what the original poster is trying to do, but you > might want to get advice as to if your use violates US patent law. > That is probably a more important issue than export. The RSA patent > expires in September. Moot point if you purchase RedHat Pro, they've got an RSA license. BTW, I am not a Linux booster -- I'm a BSD proponent. But the solution to the problem is mind-blowingly simple. There's no need to try to skirt the patent issue if it's that cheap. Note also that the [soon to be discontinued] JWS 2.0 for $295.00 is a full-fledged SSL server, with the best servlet engine on the planet -- SSL only available on Solaris/SPARC (not Intel, alas) and NT (ack! ptooey!). Meanwhile, September 20, 2000... we'll see if there will be a flourishing of RSA (the algorithm) and a withering of RSA Security. I'm shorting RSAS stock. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Commercial SSL in the US
Ulf Möller wrote: > > On Thu, Mar 09, 2000 at 11:10:24AM +, Gerard Monsen wrote: > > > Wow. I'm at a loss here. Does anyone know of any > > way that my (tiny) company can legally use SSL for > > commercial purposes in the US without paying an obscene > > amount of money to RSA or buying an obscenely expensive > > web server system from a vendor? > > Yes, buying an inexpensive web server system. I think Redhat offers > the cheapest one, but there are several vendors. RedHat Professional at $149.95 includes an SSL web server. Then of course you have to buy a certificate ;-) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Commercial SSL in the US
At 07:27 AM 3/10/00 , you wrote: > Hiya, > You could wait 'till Sept 20th this year when the RSA patents expire . >. . . > G. Or not, .. RSA *STILL* has the BSafe toolkit in the public domain, .. and it's license specifies that you can use it for any 'internal' use. *OUR* legal beagles tell me that 'internal use' includes anything for which we do not charge a fee, .. including using OpenSSL to secure our own servers. To *SELL* anything including or using the RSA toolkit, we would have to pay RSA a license. Some of the folks here happily mix the two, taking the 'trod upon' viewpoint, .. but I would recommend checking with your own lawyers to make a decision. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Key Length Legality
Hi All, I've searched the FAQ and searched the mail list, an I have no answers, but I'm sure someone has to have asked the question before. What my company is trying to do is create serveral packages that include OpenSSL to fit each group of it's customers. The options that we have are: RSA Strong encryption - US Customers with an RSA license No RSA Strong encryption - US Customers with no RSA license RSA Export encryption - Non US Customers No RSA Export encryption - Basic shipment to everyone. Everyone's happy carte blanche V. legal. Despite the fact that *I* am based in the UK, I believe that my company is shipping with *it's* -US- rules, this is not the problem. And RSA is not the problem, configuring with no-rsa etc works AFAIK with the exception of NT where def files need hacking, but that's not a problem. The problem is I would like to know how to restrict the key length in the S/W. The idea so far is to restrict the strong ciphers via our S/W -on top of the OpenSSL Libs. Whilst this sort of works on Solaris and HP/UX as the whole library that we ship is one lib. On NT, the libraries are dlls and we have to ship the OpenSSL libs and our lib that links to it. So that anyone who knows the API could get access to strong encryption -which is illegal- and even IDEA -which we have no license to ship. Now my understanding was that shipping ciphers out of the US was not the fact that they was accessable, but that the ciphers were in there. What I would like is someone to help me restrict the key length, or straighten me out on the legal issue. Thanks in advance;) Rich __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Trouble building MSDOS version
With whom do I discuss these changes? I have added MSDOS switches to four files, and everything compiles. But I also had to change some switches in msdos.mak, and I don't understand what RANLIB is for, so I just commented it out for now. I grabbed unistd.h and stat.h from Bob Stout's SNIPPETS library (SNIP9707). All stat.h does is "#include " where Micros~1 hides it. My next problem is translating the "ar r" commands to "LIB". Basically, it requires something like: O_CRYPTO= $(LIB_D)\lib$(CRYPTO) for each %o in $(CRYPTOOBJ); do LIB $(O_CRYPTO).lib +%o, $(O_CRYPTO).lst\; ; done But I doubt that I have the syntax correct. The semicolon after $(O_CRYPTO).lst is necessary to tell LIB that the command line is complete, so don't ask for any additional files (non-interactive form). If you don't want a listing file, everything between the comma and semi-colon can be skipped. There were some 'L's missing from shift constants in lines 226, 227 and 228 of crypto\des\set_key.c, but they weren't causing any of my problems. If I really understood all that I know about this stuff, this project might actually be fun. Thank you for listening. Bob McConnell > -Original Message- > From: Ulf Möller [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 09, 2000 11:47 AM > To: Bob McConnell > Cc: '[EMAIL PROTECTED]' > Subject: Re: Trouble building MSDOS version > > > On Thu, Mar 09, 2000 at 10:02:10AM -0500, Bob McConnell wrote: > > > Looking at the source, it's obvious that it's not expecting > to have MSDOS > > defined, the #IFDEF's only check for WIN32 and __ultrix. > > You'll have to add the relevent #ifdefs for MSDOS, there's no way > around that. This is simple for bss_log.c because DOS has no logging > facilities, but it's possible that there will be problems at other > places as well. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
DSA certificate and cipher list setup?
I have created certificate and priv key as follows: openssl.exe dsaparam 512 -out dsa512.pem openssl req -config req.cnf -x509 -newkey dsa:dsa512.pem -out DsaCa.pem When I do SSL_connect ... and on the server side SSL_accept the accept call fails on c=ssl3_choose_cipher(s,s->session->ciphers, ssl_get_ciphers_by_id(s)); that is because currently I am not setting any ciphers... What should I use and set? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: urgent help
Can anyone help me with a proxy I am writing ? I would love to run a ssl proxy which gets a connection from an unencrypted connection then connect to a secure server and pass the data to the server encrypted, and pass the result back to the client. That I am able to do where I have problem is when I store the open SSL connection in a link list and then reuse it on subsequent connections from a different client. This is what happen, my proxy writes to the server then there is a getpid from the ssl library which then closes the connection. can some one explain why this happen. I hope I explained it well. Burtland
Re: Commercial SSL in the US
On Thu, 9 Mar 2000, Leland V. Lammert wrote: > At 05:10 AM 3/9/00 , you wrote: > > Wow. I'm at a loss here. Does anyone know of any > >way that my (tiny) company can legally use SSL for > >commercial purposes in the US without paying an obscene > >amount of money to RSA or buying an obscenely expensive > >web server system from a vendor? > > Yes. It's called OpenSSL. Export regulations were relaxed this January, > .. and while there are many issues to be resolved, it essentially means > that WE can IMPORT anything in the public domain without a problem. You're talking about export controls, and he's asking about intellectual-property law. Different animals. W.r.t. RSADSI's code, "commercial use" probably means what RSADSI says it means. Their patent is still as valid as it ever was until late this year when it expires, so in the U.S. you have to use their code and obey their license until then. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Definitely NOT a lawyer. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Commercial SSL in the US
Hiya, You could wait 'till Sept 20th this year when the RSA patents expire . . . . G. Gerard Monsen wrote: > Wow. I'm at a loss here. Does anyone know of any > way that my (tiny) company can legally use SSL for > commercial purposes in the US without paying an obscene > amount of money to RSA or buying an obscenely expensive > web server system from a vendor? We were going to use > an Apache web server with its OpenSSL interface, but > the Apache documentation indicates that this is not allowed > for commercial purposes in the US. Any help you can give > would be appreciated. > > Gerard Monsen > Integrated Litigation Solutions > Oakland, CA > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
