Re: PROPOSAL: commons-ssl

2006-12-01 Thread Ortwin Gl├╝ck



Julius Davies wrote:

Oh, one final note.  If this gets sandboxed, I don't need to be a
committer at this time.  I'm more than happy to just email patches.


Don't worry, David. I am sure you have plenty of fans here who will be 
more than happy to vote for you as a committer!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl

2006-12-01 Thread Will Glass-Husain

Hey, that sounds very cool.  Nice job too in organizing your email and
hitting many of the important highlights required to be an Apache
projects.

WILL

On 12/1/06, Julius Davies [EMAIL PROTECTED] wrote:

Hi,

Please take a look at not-yet-commons-ssl, currently hosted here:

http://juliusdavies.ca/commons-ssl/

This java library was developed over the last year with Apache Commons
in mind.  I've been hanging out on the httpclient mailing list for 2
years, learning about https and ssl and java thanks to the
EasySSLProtocolSocketFactory and AuthSSLProtocolSocketFactory written
by Oleg Kalnichevski and Adrian Sutton.

If you google for java ssl you'll notice that HTTPClient is actually
the first *.apache.org site to appear (sometimes 2nd page, sometimes
3rd 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 (probably older?) versions of this documentation:

http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert

As a Java developer I found these two different ways of setting up
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 I discover that Java can also
handle PKCS #12 by pretending the file is a special type of JKS
file.)

Once I finally started to understand these two different ways, I
started trying to build an easier way to work with both ways.  The
goal of commons-ssl is bridge that gap.  I also tried to make SSL
and Java easier to work with by not requiring the user to know so
much.

With Commons-SSL the user no longer needs to know:

1.  What kind of keystore file is this?  JKS or PKCS #12?  Commons-SSL
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.

3.  The user created a Traditional SSLeay private key instead of
PKCS8 by accident.  Commons-SSL doesn't mind.

If Commons-SSL could have a motto, I think it would be this:  You
bring the files and the password, I'll do the rest.  Perhaps add this
sub-title:  If your password is wrong I'll throw a
ProbablyBadPasswordException.

Whereas pre-Commons-SSL, Java's motto would be:  You bring the files,
the password, make sure you know the type, and if it's PKCS #12, make
sure it's in DER.  If your RSA private key and associated X509 chain
are in separate files, you're going to have to transform them into
PEM, start up Windows Notepad to cut  paste them into a single file,
and then use 'openssl pkcs12' to get them into DER.

Perhaps add this sub-title:  If your password is wrong I might throw
a PaddingException or a DigestException.  Depends on the vendor and
version of Java..


That's the highest goal:  Make SSL easier for the users.  Make it
easier for those courageous souls downloading our software and running
it on their machines.

The next goal:  Make SSL easier for the developer.  In Java changing
aspects of an SSLSocketFactory or SSLServerSocketFactory is quite
awkward.  Many of the approaches in use today end up polluting the
entire JVM.  You want to connect to https://MySelfSignedSite.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://.

Commons-SSL tried to take this further and generalize it.  The
developer can now create a single isolated SSLSocketFactory very easy
(SSLClient extends SSLSocketFactory).

SSLClient client = new SSLCLient();

[Notice how I'm borrowing from HttpClient's own usage pattern:
HTTPClient client = new HttpClient();]

The developer can then modify that SSLSocketFactory to suit their needs:

client.setCheckHostname( false );
client.setCheckCRL( false );
client.setCheckExpiry( true );
client.setMaxTrustChainDepth( 6 );  // not yet implemented

client.addTrustMaterial( new TrustMaterial( /path/to/cert.pem ) );
client.setKeyMaterial( new KeyMaterial( /path/to/key.pem,
/path/to/certs.pem, secret.toCharArray() ) );


That's the library!  Now some details about this PROPOSAL and how it
might fit in with Apache:

Meritocracy, Community:

So far, yes, it's just been me committing whenever I like.  This has
been convenient to try and get the library into a useable state.  I
think the library has good coherency 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.  I will never be able to declare that
yes, this library doesn't compromise your security by myself.  I
think I'm ready to let go now, and let others extend this in 

Re: PROPOSAL: commons-ssl

2006-12-01 Thread Roland Weber
Hi Julius,

it's great to see that you finally got the proposal ball rolling :-)

I didn't look into your code, so my comments are based on the proposal
itself and on your web page. I like the positive attitude with which
you present the advantages of the project. However, I a missing a
clear definition of the _project_scope_. That may seem like a small
detail, but it really is a precondition for finding both an appropriate
name and home for your code base.
From your description, I understand that the purpose is
- giving easy access to different types of key material and certificates
- verifying certificates and certificate chains
- bridging different Java APIs (?)

The working title Commons-SSL does not really reflect this. Do you
plan to implement the SSL protocol as part of the project? Probably
not, so the title is misleading. An all-encompassing name might also
be offensive to people working on other SSL-related projects. I think
you should spend the time and define not only a motto, but a very clear
scope of the project. Both in terms of what's in scope as well as what's
out of scope. From there on, we can work on finding a name and home.

Please do not underestimate the importance of this step. Finding a
name may seem like a minor detail, but the problem of defining the
scope is very real. Only a few months ago, there was a long discussion
on this list about a proposal for testing.apache.org. I haven't read
anything about it anymore after the supporters realized that a scope of
everything that has to do with testing was overly broad. We don't
want to see that happen to your proposal.


I am also a little worried about this statement on your web page:

 The PKCS12 key derivation function (for some PKCS8 version 1.5 encrypted
 keys) was cut  paste from BouncyCastle (bouncycastle.org). They
 originally got it from RSA's PKCS12 specification
 (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf),
 so we hope this copy  paste operation is okay!

The BouncyCastle license (http://bouncycastle.org/licence.html)
is quite specific that the license must remain intact. You can
not just relicense their code under the Apache License. That's
assuming that the part you copied and pasted was not explicitly
released with a different license.

cheers,
  Roland

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl

2006-12-01 Thread Julius Davies

Hi, Roland,

I have already noticed some confusion about the commons-ssl name -
someone emailed httpclient-dev asking:

Does this SSL support TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA?

I had to explain that Commons-SSL just sits on top of the JSSE and JCE
to try and make working with SSL and Java easier.  Your point about
the name is a good one.

Regarding the BouncyCastle code, I sent an email to the BouncyCastle
mailing list.  Here's the reply I got:


On 11/28/06, David Hook wrote:


Thanks for the feedback!

Cool.

In regards:

Is there any way I can have ONLY these 100 lines and license it under
 Apache 2.0?  I would be more than happy to attribute it to you guys in
 my NOTICE.txt file, as well as in comments in the code, and on my main
 web page.

If attribution is included we have no issue with the section of code
being included in a product distributed under Apache 2.0.

Regards,

David



I hope that's sufficient to address the licensing concern.

yours,

Julius


On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:

Hi Julius,

it's great to see that you finally got the proposal ball rolling :-)

I didn't look into your code, so my comments are based on the proposal
itself and on your web page. I like the positive attitude with which
you present the advantages of the project. However, I a missing a
clear definition of the _project_scope_. That may seem like a small
detail, but it really is a precondition for finding both an appropriate
name and home for your code base.
From your description, I understand that the purpose is
- giving easy access to different types of key material and certificates
- verifying certificates and certificate chains
- bridging different Java APIs (?)

The working title Commons-SSL does not really reflect this. Do you
plan to implement the SSL protocol as part of the project? Probably
not, so the title is misleading. An all-encompassing name might also
be offensive to people working on other SSL-related projects. I think
you should spend the time and define not only a motto, but a very clear
scope of the project. Both in terms of what's in scope as well as what's
out of scope. From there on, we can work on finding a name and home.

Please do not underestimate the importance of this step. Finding a
name may seem like a minor detail, but the problem of defining the
scope is very real. Only a few months ago, there was a long discussion
on this list about a proposal for testing.apache.org. I haven't read
anything about it anymore after the supporters realized that a scope of
everything that has to do with testing was overly broad. We don't
want to see that happen to your proposal.


I am also a little worried about this statement on your web page:

 The PKCS12 key derivation function (for some PKCS8 version 1.5 encrypted
 keys) was cut  paste from BouncyCastle (bouncycastle.org). They
 originally got it from RSA's PKCS12 specification
 (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf),
 so we hope this copy  paste operation is okay!

The BouncyCastle license (http://bouncycastle.org/licence.html)
is quite specific that the license must remain intact. You can
not just relicense their code under the Apache License. That's
assuming that the part you copied and pasted was not explicitly
released with a different license.

cheers,
  Roland

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl

2006-12-01 Thread Roland Weber
Hi Julius,

 Regarding the BouncyCastle code, I sent an email to the BouncyCastle
 mailing list.  Here's the reply I got:
 
 [...]
 If attribution is included we have no issue with the section of code
 being included in a product distributed under Apache 2.0.
 [...]

 I hope that's sufficient to address the licensing concern.

The attribution part probably means that the code must still carry
the BouncyCastle license rather than the Apache license. I guess a
lawyer will have to look into this, unless the BouncyCastle license
has been discussed before.

cheers,
  Roland


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl

2006-12-01 Thread Will Glass-Husain

Also (note this is getting technical), Apache policy is to acknowledge
copyrights in the NOTICE file not the source code.  This is a new
policy, effective Nov 1 2006.  See:

http://www.apache.org/legal/src-headers.html

WILL

On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:

Hi Julius,

 Regarding the BouncyCastle code, I sent an email to the BouncyCastle
 mailing list.  Here's the reply I got:

 [...]
 If attribution is included we have no issue with the section of code
 being included in a product distributed under Apache 2.0.
 [...]

 I hope that's sufficient to address the licensing concern.

The attribution part probably means that the code must still carry
the BouncyCastle license rather than the Apache license. I guess a
lawyer will have to look into this, unless the BouncyCastle license
has been discussed before.

cheers,
  Roland


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Forio Business Simulations

Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl

2006-12-01 Thread Vadim Gritsenko

Julius Davies wrote:
...

I had to explain that Commons-SSL just sits on top of the JSSE and JCE
to try and make working with SSL and Java easier.  Your point about
the name is a good one.


The counterpoint to name argument. Just single example, I'm sure there are many 
more: commons-logging sits on top of log4j/java logger/logkit/... and tries to 
make working with all them seamless.


commons-ssl may be not the best name but it isn't terribly bad either.

Vadim

...


On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:


The working title Commons-SSL does not really reflect this. Do you
plan to implement the SSL protocol as part of the project? Probably
not, so the title is misleading. An all-encompassing name might also
be offensive to people working on other SSL-related projects. I think
you should spend the time and define not only a motto, but a very clear
scope of the project. Both in terms of what's in scope as well as what's
out of scope. From there on, we can work on finding a name and home.

Please do not underestimate the importance of this step. Finding a
name may seem like a minor detail, but the problem of defining the
scope is very real. Only a few months ago, there was a long discussion
on this list about a proposal for testing.apache.org. I haven't read
anything about it anymore after the supporters realized that a scope of
everything that has to do with testing was overly broad. We don't
want to see that happen to your proposal.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl

2006-12-01 Thread Will Glass-Husain

Also, just to be clear, when Roland says I guess a lawyer will have
to look into that, there's a specific internal Apache mailing list
(legal-discuss) for resolving exactly these kind of issues.

To me this seems a perfect candidate for the incubator, and possibly
to move into Jakarta upon graduation.  The challenge is that you have
to get others interested enough to join the project.  They don't have
to be Apache people (although you'll need a couple of Apache mentors).
Probably before incubation.  (though others should feel free to
disagree).

Part of the reason that the community aspect is so important is that
there's a belief that multi-person projects are more sustainable than
single-developer projects.  We had a long conversation about this in
the Jakarta BOF at ApacheCon US.  There's a history of projects that
have come into Jakarta with good code and no community that have
(ultimately) ended up with no support.  It frustrates users and is a
tricky issue to resolve.

WILL

On 12/1/06, Will Glass-Husain [EMAIL PROTECTED] wrote:

Also (note this is getting technical), Apache policy is to acknowledge
copyrights in the NOTICE file not the source code.  This is a new
policy, effective Nov 1 2006.  See:

http://www.apache.org/legal/src-headers.html

WILL

On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:
 Hi Julius,

  Regarding the BouncyCastle code, I sent an email to the BouncyCastle
  mailing list.  Here's the reply I got:
 
  [...]
  If attribution is included we have no issue with the section of code
  being included in a product distributed under Apache 2.0.
  [...]
 
  I hope that's sufficient to address the licensing concern.

 The attribution part probably means that the code must still carry
 the BouncyCastle license rather than the Apache license. I guess a
 lawyer will have to look into this, unless the BouncyCastle license
 has been discussed before.

 cheers,
   Roland


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Forio Business Simulations

Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com




--
Forio Business Simulations

Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl - commons-sslutils?

2006-12-01 Thread Oleg Kalnichevski
On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote:
 Julius Davies wrote:
 ...
  I had to explain that Commons-SSL just sits on top of the JSSE and JCE
  to try and make working with SSL and Java easier.  Your point about
  the name is a good one.
 
 The counterpoint to name argument. Just single example, I'm sure there are 
 many 
 more: commons-logging sits on top of log4j/java logger/logkit/... and tries 
 to 
 make working with all them seamless.
 
 commons-ssl may be not the best name but it isn't terribly bad either.
 
 Vadim
 

Folks,

What about Commons-SSLUtils? This name seems consistent with already
existent Commons projects (DBUtils)

Julius,

Since what-some-day-might-become-commons-ssl is partially based on
some little bits of code I wrote, you can safely add me to the initial
list of committers. I will not be able to do a lot in terms of coding,
given my HttpComponents commitments, but I could help by doing some code
reviews once in a while and participating in design decisions.

Cheers,

Oleg


 ...
 
  On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:
 
  The working title Commons-SSL does not really reflect this. Do you
  plan to implement the SSL protocol as part of the project? Probably
  not, so the title is misleading. An all-encompassing name might also
  be offensive to people working on other SSL-related projects. I think
  you should spend the time and define not only a motto, but a very clear
  scope of the project. Both in terms of what's in scope as well as what's
  out of scope. From there on, we can work on finding a name and home.
 
  Please do not underestimate the importance of this step. Finding a
  name may seem like a minor detail, but the problem of defining the
  scope is very real. Only a few months ago, there was a long discussion
  on this list about a proposal for testing.apache.org. I haven't read
  anything about it anymore after the supporters realized that a scope of
  everything that has to do with testing was overly broad. We don't
  want to see that happen to your proposal.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: PROPOSAL: commons-ssl - commons-sslutils?

2006-12-01 Thread Martin Cooper

On 12/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote:


On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote:
 Julius Davies wrote:
 ...
  I had to explain that Commons-SSL just sits on top of the JSSE and JCE
  to try and make working with SSL and Java easier.  Your point about
  the name is a good one.

 The counterpoint to name argument. Just single example, I'm sure there
are many
 more: commons-logging sits on top of log4j/java logger/logkit/... and
tries to
 make working with all them seamless.

 commons-ssl may be not the best name but it isn't terribly bad either.

 Vadim


Folks,

What about Commons-SSLUtils? This name seems consistent with already
existent Commons projects (DBUtils)



Calling it Commons-anything presupposes where it would land up after
incubation. That's not something that we should be doing, as the final
resting place of an incubated project is not determined until incubation has
successfully completed.

On the other hand, I think SSLUtils would be a fine name to run with.

--
Martin Cooper


Julius,


Since what-some-day-might-become-commons-ssl is partially based on
some little bits of code I wrote, you can safely add me to the initial
list of committers. I will not be able to do a lot in terms of coding,
given my HttpComponents commitments, but I could help by doing some code
reviews once in a while and participating in design decisions.

Cheers,

Oleg


 ...

  On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:
 
  The working title Commons-SSL does not really reflect this. Do you
  plan to implement the SSL protocol as part of the project? Probably
  not, so the title is misleading. An all-encompassing name might also
  be offensive to people working on other SSL-related projects. I think
  you should spend the time and define not only a motto, but a very
clear
  scope of the project. Both in terms of what's in scope as well as
what's
  out of scope. From there on, we can work on finding a name and home.
 
  Please do not underestimate the importance of this step. Finding a
  name may seem like a minor detail, but the problem of defining the
  scope is very real. Only a few months ago, there was a long
discussion
  on this list about a proposal for testing.apache.org. I haven't
read
  anything about it anymore after the supporters realized that a scope
of
  everything that has to do with testing was overly broad. We don't
  want to see that happen to your proposal.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]