tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Portable SSL Support
Date Wed, 14 Nov 2001 19:13:03 GMT
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" <ekr@rtfm.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Wednesday, November 14, 2001 11:23 AM
Subject: Re: Portable SSL Support


> "William Barker" <william.barker@wilshire.com> writes:
> > > jean-frederic clere <jfrederic.clere@fujitsu-siemens.com> 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:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-dev-help@jakarta.apache.org>
>
>


*----*

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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message