Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 52192 invoked from network); 7 Nov 2001 19:16:07 -0000 Received: from unknown (HELO osaka.betaversion.org) (192.18.49.133) by daedalus.apache.org with SMTP; 7 Nov 2001 19:16:07 -0000 Received: (qmail 1175 invoked from network); 7 Nov 2001 19:18:38 -0000 Received: from nagoya.betaversion.org (192.18.49.131) by osaka.betaversion.org with SMTP; 7 Nov 2001 19:18:38 -0000 Received: (qmail 19439 invoked by uid 97); 7 Nov 2001 19:15:55 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 19421 invoked by uid 97); 7 Nov 2001 19:15:54 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 19410 invoked from network); 7 Nov 2001 19:15:54 -0000 Message-ID: <00a101c167bb$a89ea8c0$5a66a8c0@wilshire.com> Reply-To: "Bill Barker" From: "Bill Barker" To: "Tomcat Developers List" , References: <3BE97643.336AC3CC@fujitsu-siemens.com> Subject: Re: Tomcat to support other keystore types? Date: Wed, 7 Nov 2001 10:40:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Archived: msg.XX8xuWMa@sneezy X-Filter-Version: 1.4.5 (sneezy) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N And, indeed, for tomcat+apache, we don't use JSSE (except to allow for url rewriting ;). I'm in favor of Eric's approach for exactly Costin's reason: having a separate interface would decouple the SSL info from the socket factory. Of course, if Eric wants to provide patches to save me typing I'm even more in favor of it. ----- Original Message ----- From: "jean-frederic clere" To: "Tomcat Developers List" Sent: Wednesday, November 07, 2001 9:58 AM Subject: Re: Tomcat to support other keystore types? > Eric Rescorla wrote: > > > > writes: > > > IMHO it would be better to decouple the SSL info from the socket > > > factory and socket abstraction - in apache+tomcat case all the information > > > will be retrieved from apache using RPC-like communication. > > The approach I was thinking about was to have some abstract > > SSLSocket interface that all the SSL modules had to implement. > > How that interface was implemented would be under the covers. > > It would be straightforward for the apache+tomcat implementations > > to use RPC internally to get information about the sockets. > > For tomcat+apache the SSL logic is in httpd and all could be done using > java.security (except when using jdk1.1.x). > > For tomcat standalone we need the new SSLSocket interface. For the client > certificates the best would be to get them it java.security classes. (JSSE has > them in javax.security and PureTSL?). > > > > > Is that what you had in mind or were you thinking of something > > different? > > > > -Ekr > > > > -- > > [Eric Rescorla ekr@rtfm.com] > > http://www.rtfm.com/ > > > > -- > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > *----* This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. -- To unsubscribe, e-mail: For additional commands, e-mail: