incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "CommonsSSLProposal" by JuliusDavies
Date Sun, 11 Mar 2007 19:20:07 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by JuliusDavies:
http://wiki.apache.org/incubator/CommonsSSLProposal

The comment on the change is:
added more external links, fixed WikiName problems, no longer using first-person

------------------------------------------------------------------------------
   * Enable/Disable CRL checking.
   * Enable/Disable OCSP checking.
   * Enable/Disable Weak Ciphers.
+  * Enable/Disable Max-Depth checking of certificate chain.
  
  Commons-SSL generates SSL``Socket``Factory, SSL``Server``Socket``Factory, and SSL``Context
objects for consumers to drop into their existing code bases.
  
@@ -54, +55 @@

  
  = Background =
  
- This java library was developed over the last year with Apache Commons
+ This java library was developed by Credit Union Central of British Columbia (http://www.cucbc.com/)
throughout 2006 with Apache Commons
  in mind.  The original idea was inspired by the
- Easy``SSL``Protocol``Socket``Factory and Auth``SSL``Protocol``Socket``Factory examples written
+ [http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/EastSSLProtocolSocketFactory.java
EasySSLProtocolSocketFactory] and [http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/AuthSSLProtocolSocketFactory.java
AuthSSLProtocolSocketFactory] examples written
  by Oleg Kalnichevski and Adrian Sutton.
  
  If you google for "java ssl" you'll notice that HTTP``Client is actually
- the first "*.apache.org" site to appear (sometimes 2nd page, sometimes
+ the first "*.apache.org" site to appear (sometimes 8th page, sometimes
- 3rd page of results):
+ 9th page of results):
  
  http://www.google.ca/search?q=java+ssl
  
  Meanwhile if you just google for "ssl", you'll notice that "www.modssl.org" and
  "www.apache-ssl.org" are on the first page of results.  Both of those
- sites contain versions of this documentation:
+ sites contain versions of the Apache SSL FAQ:
  
  http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert
  
@@ -75, +76 @@

  SSL to be a source of confusion.  The OpenSSL/Apache documentation
  about setting up SSL is very good, very handy.  But it just doesn't
  work with Java, because Java only understands "JKS" files created by
- "keytool".  (Oh wait...  months later one discovers that Java can also
+ "keytool".  (Oh wait...  months later one usually discovers that Java can also
+ handle "PKCS #12".)
- handle "PKCS #12" by pretending the file is a special type of JKS
- file.)
  
  Commons-SSL attempts to make it possible to work in both ways.
  With Commons-SSL the user no longer needs to know:
  
- 1.  What kind of keystore file is this?  JKS or PKCS #12?  Commons-SSL
+ 1.  What kind of keystore file is this?  JKS or PKCS #12?
- will just figure this out on its own.  (We should probably also start
- considering these newer JCEKS files, but that's not in place yet.)
  
  2.  The user created a PKCS #12 file using "openssl" but forgot to say
- "-outform DER".  Commons-SSL can still deal with that file.
+ "-outform DER".
  
  3.  The user created a "Traditional SSLeay" private key instead of
- PKCS8 by accident.  Commons-SSL doesn't mind.
+ PKCS8 by accident.
  
  If Commons-SSL could have a motto, it would be this:  "You
  bring the files and the password, I'll do the rest."  Perhaps add this
@@ -108, +106 @@

  a Padding``Exception or a Digest``Exception.  Depends on the vendor and
  version of Java.".
  
+ ----
  
  Once the private key is loaded, SSL can start happening.  But there
  are still many options and advanced usages of SSL that a developer
  might want to use.  In Java changing
  aspects of an SSL``Socket``Factory or SSL``Server``Socket``Factory is quite
  awkward.  Many of the approaches in use today end up polluting the
- entire JVM.  You want to connect to "https://MySelfSignedSite.com/";
+ entire JVM.  You want to connect to "ht``tps://my-self-signed-site.com/"
  and suddenly all your LDAPS and RMI-SSL and JDBC-SSL calls aren't
  checking the server certificate either!  The HTTPClient group came up
  with a very novel solution:  "https-easy://".
@@ -123, +122 @@

  developer can now create a single isolated SSL``Socket``Factory very easily
  (SSL``lient extends SSL``Socket``Factory).
  
+ {{{
+ #!java
- SSLClient client = new SSLCLient();M
+ SSLClient client = new SSLCLient();
+ }}}
  
  [Notice how we're borrowing from Http``Client's own usage pattern:
  Http``Client client = new Http``Client();]
@@ -149, +151 @@

  
  == Meritocracy ==
  
- So far it's just been Julius committing whenever he likes.
+ So far it's just been the main developer committing whenever he likes.
- This has been convenient to try and get the library into a useable state.  
+ This has been convenient to try and get the library into a useable state.
  The library has good coherency partly because only one person has been
  working on it so far.  But on the other hand, SSL is touchy stuff, and
  it needs eyes looking at it.  We will never be able to declare that
  "yes, this library doesn't compromise your security" without more committers
  on board.
  
- There is a lot of Java-SSL expertise spread around Apache:  Tomcat, Commons-Net,
+ There is a lot of Java-SSL expertise spread around Apache:
- HttpComponents, Synapse, Directory (recently looking into STARTTLS!)
+ 
+  * [http://tomcat.apache.org/ Tomcat]
+  * [http://jakarta.apache.org/commons/net/ Commons-Net]
+  * [http://jakarta.apache.org/httpcomponents/ HttpComponents]
+  * [http://ws.apache.org/synapse/ Synapse]
+  * [http://directory.apache.org/ Directory] (Some recent [http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3ca32f6b020703081106o2469ccd0w70a14110957f79ac@mail.gmail.com%3e
STARTTLS] activity!)
+ 
- are just five examples that immediately spring to mind, and of course there
+ These are just five examples that immediately spring to mind, and of course there
- are many, many more.  Hopefully the SSL experts on some of these projects will take an
+ are many, many more.  Hopefully the SSL/TLS experts on some of these projects will take
an
  interest in Commons-SSL.
  
  == Community ==
  
  The community is very new, but they are enthusiastic.  A "not-yet-commons-ssl"
- mailing list was started on January 5th off of juliusdavies.ca, and already within
+ mailing list was started on January 5th as [http://lists.juliusdavies.ca/listinfo.cgi/not-yet-commons-ssl-juliusdavies.ca/
not-yet-commons-ssl@lists.juliusdavies.ca], and already within
  2 months, out of 10 subscribers so far, three are quite active and helpful.
  
- There is a good relationship with the BouncyCastle project.
+ There is a good relationship with the [http://bouncycastle.org/ BouncyCastle] project.
  
- There is a strong relationship with the HttpComponents team.  Julius tries
+ There is a strong relationship with the Http``Components team.  The main Commons-SSL developer
tries
  to float design ideas by httpcomponents-dev.  The recent 0.3.7 release of
- not-yet-commons-ssl was done primarily to provide support for the new httpcomponents
+ [http://juliusdavies.ca/commons-ssl/download.html not-yet-commons-ssl.jar] was done primarily
to provide support for the new httpcomponents
  NIO-SSL module.
  
- It's probably a coincidence, but "SSL and Java" related queries on the OpenSSL-User mailing
list
+ It's probably a coincidence, but "SSL and Java" related queries on the Open``SSL-User mailing
list
  have completely disappeared since the library was announced on that list.  SSL related questions
- seem to have diminished on the HttpClient-User list as well.
+ seem to have diminished on the Http``Client-User list as well.
  
  We're currently averaging 150 - 200 downloads a month (from 150 - 200 unique IP addresses).
  
  
  == Core Developers ==
  
- Definitely a weak spot with Commons-SSL right now.  There's only Julius,
+ Definitely a weak spot with Commons-SSL right now.  There's only the main developer,
- with input on the mailing lists coming mostly from Roland and Oleg,
+ with input on the mailing lists coming mostly from Http``Component's Roland and Oleg.
+ Recently there's been some input on [http://lists.juliusdavies.ca/listinfo.cgi/not-yet-commons-ssl-juliusdavies.ca/
not-yet-commons-ssl@lists.juliusdavies.ca]
- and recently also from Mike Ressler and Steve Davidson.
+ from Mike Ressler and Steve Davidson.
  
  
  == Alignment with existing Apache subprojects ==
@@ -198, +207 @@

  
  http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert
  
- We're actually bridging an old split, between OpenSSL
+ We're bridging an old split, between OpenSSL
- and Sun's Java, perhaps like the Pope's visit to Turkey?
+ and Sun's Java, perhaps like the Pope's recent visit to Turkey?
  
- In terms of code use:   we're using code from directory.apache.org,
+ In terms of code use:   we're using code from [http://directory.apache.org/ directory.apache.org],
- we've also using code from commons-codec.  In terms of helping other
+ we've also using code from [http://jakarta.apache.org/commons/codec/ Commons-Codec].  In
terms of helping other
- projects:  Commons-SSL has lots of hooks in place for HttpComponents and
+ projects:  Commons-SSL has lots of hooks in place for Http``Components and
- anyone who uses SSLSocketFactory or SSLServerSocketFactory can drop
+ anyone who uses SSL``Socket``Factory, SSL``Server``Socket``Factory, or SSL``Context can
drop
  Commons-SSL into their project quite seamlessly.
  
  I think Commons-SSL would be good for many open-source projects.  Here
  are a few ideas:
  
- http://jtds.sourceforge.net/
+  * http://jtds.sourceforge.net/
- http://telnetd.sourceforge.net/
+  * http://telnetd.sourceforge.net/
- http://directory.apache.org/  (to help when being an ldaps:// server)
+  * http://directory.apache.org/  (to help when being an ldaps:// server)
- http://tomcat.apache.org/  (so support APR-SSL config when APR isn't around)
+  * http://tomcat.apache.org/  (so support APR-SSL config when APR isn't around)
  
  That's just the server side.  It's very handy on the client side, too.
- Already three open source projects (that I know of) are using
+ Already three open source projects (that we know of) are using
  Commons-SSL:
  
- http://xfire.codehaus.org/HTTP+Transport
+  * http://xfire.codehaus.org/HTTP+Transport
- http://www.soapui.org/
+  * http://www.soapui.org/
- http://www.bedework.org/
+  * http://www.bedework.org/
  
- The library recently appeared in Shibboleth's source tree, but I can't find any use of it!
+ The library recently appeared in Shibboleth's source tree, but we can't find any use of
it!
  
- http://svn.middleware.georgetown.edu/view/trunk/lib/?root=java-xmltooling
+  * http://svn.middleware.georgetown.edu/view/trunk/lib/?root=java-xmltooling
  
  = Known Risks =
  
@@ -239, +248 @@

  == Inexperience with Open Source ==
  
  Commons-SSL has been an Open Source project already for 9 months, with mailing-lists
- for 2 months.  The code was derived from HttpClient code in its "contrib" repository.
+ for 2 months.  The code was derived from Http``Client code in its "contrib" repository.
  The main developer so far has been active on open source mailing lists for 3 years.
  
  Inexperience with Apache will definitely cause many fumbles on the incubator and
@@ -249, +258 @@

  == Homogeneous Developers ==
  
  Homogeneity is not really the problem.  The problem is lack of developers.  But
- this is common for small "jakarta-commons" sub-projects.  Nonetheless, jakarta-commons
+ this is common for small "Jakarta-Commons" sub-projects.  Nonetheless, Jakarta-Commons
  is quite a vibrant part of Apache.
  
  == Relationships with Other Apache Products ==
  
- The relationship with HttpComponents is strong, and a relationship with Synapse
+ The relationship with Http``Components is strong, and a relationship with Synapse
  is just starting.  The library seems to be very popular in the web-services world
  (SoapUI, XFire), and indeed, webservices is exactly where Credit Union Central of British
Columbia
  (the original developer) uses the code inside their shop.
@@ -265, +274 @@

  The library was written particularly with Tomcat in mind.  There is currently
  no relationship with Tomcat, and more than anything this goal is like a guiding
  mirage rather than something that actually matters.  The Tomcat goal has helped give the
- library a nice shape.  The symmetry with SSLServer and SSLClient is pleasing.
+ library a nice shape.  The symmetry with SSL``Server and SSL``Client is pleasing.
  
  == A Excessive Fascination with the Apache Brand ==
  
- A few people on the current not-yet-commons-ssl mailing list have asked when
+ A few people on the not-yet-commons-ssl mailing list have asked when
  this code will become Apache code.  The Apache brand is going to help people
  feel safer about bringing this SSL security-sensitive code into their shop -
  there's no question about that.
  
  Perhaps there is some excessive fascination with the Apache Brand in this case,
- although I like to think the fascination was more with Apache-Jakarta-Commons than
+ although we like to think the fascination was more with Apache-Jakarta-Commons than
- just "Apache".  HttpClient is such an excellent library!  This SSL code seemed like
+ just "Apache".  Http``Client is an excellent library!  This SSL code seemed like
- a good way to partially return the favour, and Jakarta-Commons seemed like such a
+ a good way to partially contribute back to the community in kind.  Jakarta-Commons
+ seems like a
- good fit for these 100 java classes.  The HttpComponents team was also very
+ good fit for these 100 java classes.  The Http``Components team was also very
  encouraging when Commons-SSL was first announced, and that was exciting.
  
  By the way, sorry for the original "common-ssl" name.  That was an unfortunate
@@ -294, +304 @@

  
  = Source and Intellectual Property Submission Plan =
  
- All CLA's and CCLA's submitted and accepted.
+  * Julius Davies's [http://apache.org/licenses/icla.txt CLA] submitted and accepted.
+  * http://www.cucbc.com/ Credit Union Central of British Columbia's  [http://apache.org/licenses/cla-corporate.txt
CCLA and Software Grant] submitted and accepted.
  
  = External Dependencies =
  
- Compile-time dependencies on HttpClient and Log4J.
+ Compile-time dependencies on [http://jakarta.apache.org/commons/httpclient/ HttpClient 3.x]
and [http://logging.apache.org/log4j/ Log4J 1.2.x].
  
  No run-time depedencies.
  
  Confession:
- I did copy & paste Base64 from commons-codec, and ASN.1 parsing from directory.apache.org.
+ We did copy & paste Base64.java from [http://jakarta.apache.org/commons/codec/ Commons-Codec],
and ASN.1 parsing from [http://directory.apache.org directory.apache.org]
- But "java -jar common-ssl.jar" wouldn't work without this, and the library is still under
200 KB.
+ But "java -jar common-ssl.jar" wouldn't work without this, and the library is still under
250 KB.
- I hope to move these out once JSR-277 and Java-7 are ubiquitous (probably in 5 - 7 years).
+ We hope to move these out once JSR-277 and Java-7 are ubiquitous (probably in 5 - 7 years).
  
  = Cryptography =
  
  Yes!
  
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message