Eric Rescorla wrote: > > "William Barker" <[EMAIL PROTECTED]> writes: > > If you decide on 2a, like Costin, I'd prefer it as a property of the > > SocketFactory (the base class can return null, since Ajp1x would use it's > > own mechanism) rather than an interface. However, it's your call. > > I ended up doing more or less what I proposed in my previous > message. The master specification class is an SSLImplementation which > contains methods allowing you to acquire ServerSocketFactories and > SSLSupport objects. SSLImplementation knows how to automatically > select whatever implementation is present (from the compiled in > list) or you can provide an SSLImplementation property in the > config file. This works fine. > > 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). > > (II) How to expose SSLSupport? Currently Request has access to > SSLSupport but it's not obvious (at least to me) how best to > expose this to the rest of Tomcat and to JSPs/servlets. You have to use request.getAttribute() in the JSPs/servlets. > > The obvious choices are: > (1) Simply provide a way to access the SSLSupport object > (presumably via an attribute). > > (2) Break out what we believe the relevant information > in SSLSupport is (i.e. ciphersuites, cert chain, etc) > and store that as individual attributes. > > >From a cursory scan of the code it's not clear to me what would > be most consistent with traditional practice. Do people have > opinions? > > -Ekr > > -- > [Eric Rescorla [EMAIL PROTECTED]] > Author of "SSL and TLS: Designing and Building Secure Systems" > http://www.rtfm.com/ > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
