Actually, the spec only mandates X509Certificate if Tomcat is running under Java 2. Otherwise: <spec-quote> For a servlet container that is not running in a Java2 Standard Edition 1.2 environment, vendors may provide vendor specific request attributes to access SSL certificate information. </spec-quote> ----- Original Message ----- From: "Eric Rescorla" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, November 14, 2001 11:23 AM Subject: Re: Portable SSL Support
> "William Barker" <[EMAIL PROTECTED]> writes: > > > jean-frederic clere <[EMAIL PROTECTED]> writes: > > > > Eric Rescorla wrote: > > > > > A few issues remain: > > > > > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the > > > > > existing JSSE code and my new code rely upon java.security.cert.* > > > > > which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or > > > > > less complete (less in the case of JSSE) certificate interfaces but > > > > > they're of course different and we need a common interface presented > > > > > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new > > > > > abstraction layer, which can't inherit from java.security.cert because > > > > > that didn't exist in 1.1. This isn't a problem (Simple Matter of > > > > > Programming) but is only worth doing if necessary. > > > > > > > > With JDK 1.1.x and AJP a null is returned. > > > > With JDK 1.1.x should the CC be returned as a String? (I thought it > > was). > > > It's certainly not in the JSSE code I was porting. That code > > > didn't even compile without JDK 1.2.x. > > > > > > from build.xml: > > > <exclude name="**/util/net/SSLSocketFactory.java" > > > unless="jdk12.present"/> > > > > > > In any case, we can do something far more sophisticated than a String > > > if we want to, even with JDK 1.1.x. > > > > If it wasn't mandated to be a java.security.cert.X509Certificate [] by > > section 5.7 of the servlet spec :). > Well, I suppose that since JDK 1.1.x didn't stop you from putting > classes in java. I could do my own version of > java.security.cert.X509Certificate. A little gross but perhaps > the best plan. The alternative is to blatantly violate the spec > in 1.1 and just deliver something else. > > > > > You have to use request.getAttribute() in the JSPs/servlets. > > > Right, but that doesn't mean that we have to expose the SSLSupport > > > interface. Instead we could break out each individual property > > > we cared about into it's own attribute. > > > > To be consistant with 2.3 containers, I'd go with individually named > > attributes. > Fine with me. Anyone object to this? > > -Ekr > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > *----* 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
