hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Davies" <juliusdav...@gmail.com>
Subject questions about commons-ssl
Date Fri, 17 Nov 2006 20:00:05 GMT
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.

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! -->
      port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
      enableLookups="false" disableUploadTimeout="true" acceptCount="100"
      debug="0" scheme="https" secure="true" sslProtocol="TLS"


  <!-- hypothetical <ssl> node for finer-grained control -->
  <!-- NOTE:  purely hypothetical - not supported at all! -->
    <!-- if client presents client cert, must be signed by one of these: -->




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.




  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message