hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: questions about commons-ssl
Date Sat, 18 Nov 2006 13:34:33 GMT
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 human-response@apache.org? 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message