On Fri, 2006-11-17 at 15:00 -0500, Julius Davies wrote: > Hi, Oleg, Roland, et al, > > I just have a few questions and a few comments. I don't want to pester > anyone too much, so I'm limiting myself to one query a month about the > status with the software grant we sent in August. I'm also trying to make a > point of always adding at least one more feature to the code for every > pestering email. :-) > > 1. Does anyone know what the status is with the software grant CUCBC sent > in for commons-ssl? I want to wait until we get that all sorted out before > going any further along the incubation path. >
Hi Julius, We have absolutely no control over this process. Have you received any response from [EMAIL PROTECTED] Where did things get stuck? Oleg > 2. I recently added support for PKCS8 and OpenSSL format private keys. > It's alpha quality at the moment. I've only announced it here for now while > I try to iron out any bugs. But if you guys like the feature, I'm thinking > of also announcing on OpenSSL and BouncyCastle's mailing lists. > > OpenSSL might find it interesting to see all of their formats supported in > Java like that. Plus they probably get the occasional java question, so > they can refer to commons-ssl when appropriate. I'm also curious why CFB > and OFB mode always result in "NoPadding", whereas CBC and ECB result in > "PKCS5Padding". This happens both with the OpenSSL "traditional" encryption > (which is fine, it's their format!), but also with the PKCS8 Version 2 using > DES1, or AES. Personally I don't know encryption well enough, and I don't > know the PKCS8 standard well enough to say that they're doing things wrong, > but it just seemed odd. > > BouncyCastle just might like to see how awesome they are. They're the only > one who totally supports all the formats on Java 1.3. I'm thinking of even > adding support for DESX and CAST5 just to show off how much BouncyCastle > rocks (I anticipate that they will support those - maybe not?). > > 3. The one supreme goal of the library is to no longer require the user to > know their "keystoreType". Just hand me the files, the password, and I'll > figure the rest out. The far off distant dream that gives me hope and > sustains me while writing this library is this.... > > Imagine a tomcat/conf/server.xml file where..... > > Tomcat was sharing the SAME https cert that apache had, while listening on > port 8443.... > > (Hopefully the <!-- XML --> comments will help prevent people hitting this > email off google from thinking Tomcat actually supports this!) > > <!-- hypothetical example that doesn't actually work - don't try this at > home, kids! --> > <Connector > port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" > enableLookups="false" disableUploadTimeout="true" acceptCount="100" > debug="0" scheme="https" secure="true" sslProtocol="TLS" > clientAuth="false" > > keystoreFile="/etc/httpd/conf/ssl.key" > associatedCertificateChain="/etc/httpd/conf/ssl.crt" > > > > <!-- hypothetical <ssl> node for finer-grained control --> > <!-- NOTE: purely hypothetical - not supported at all! --> > <ssl> > <!-- if client presents client cert, must be signed by one of these: --> > <trust-entry>CACERTS</trust-entry> > <trust-entry>/path/to/certificate.pem</trust-entry> > <trust-entry>/path/to/certificate.der</trust-entry> > <trust-entry>/path/to/pkcs7_chain.pem</trust-entry> > <trust-entry>/path/to/pkcs7_chain.der</trust-entry> > <trust-entry>/path/to/jks_certs.jks</trust-entry> > > <check-crl>true</check-crl> > > <enabled-protocol>TLSv1</enable-protocol> > <enabled-protocol>SSLv3</enable-protocol> > <enabled-protocol>SSLv2Hello</enable-protocol> > > <enable-cipher>TLS_DHE_DSS_WITH_AES_128_CBC_SHA</enable-cipher> > <enable-cipher>TLS_DHE_DSS_WITH_AES_192_CBC_SHA</enable-cipher> > <enable-cipher>TLS_DHE_DSS_WITH_AES_256_CBC_SHA</enable-cipher> > </ssl> > </Connector> > > > > associatedCertificateChain="/etc/httpd/conf/ssl.crt" can still be used even > if the "keystoreFile" is JKS or PKCS12. That's because commons-ssl goes to > some trouble to build up a proper certificate chain using the > X509Certificate.verify( PublicKey ) method. So if PKCS12 or JKS only > contained a single certificate, the user could add additional ancestors to > the chain for presentation during the handshake through this parameter. > > Not sure why GMail made my font go funny at this point. > > yours, > > Julius > > > http://juliusdavies.ca/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
