Hi Emmanuel,

On Tue, Dec 23, 2008 at 4:24 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Alex Karasulu wrote:
I agree with you.  You're right that this is not the best solution for our
users currently.  I'm thinking that we should run faster into the future
with the tooling to support cert management in the DIT rather than reverting
back to the use of the keystore file.

When you scratch the itch with the keystore file no one will come to the
table to really create the tooling.  Once the pressure is gone, the advance
will never happen.  Let the users complain. Let them also get involved and
affect change is what I say.
 
As much as I agree with you on the global imagine, I think that we should also allow 'antiquated' users to play with there keystore file, if it's just a matter of a few lines of code to be injected in the server (and so far, it costed me less than an hour to restore those lines). Writing the tooling to store a certificate at the right place in the DiT, plus all the associated tests, will cost a couple of days.

I don't have time for more than that right now, and if you consider that the current documentation tells the users how to use the keystore, that also mean to update the documentation.

On a more general base, I think that Stefan and Christine, plus a few others, have spent a considerable amount of time writing this doco, and we should respect this effort.

Absolutely, I respect this very much.  My suggestions are not intended to disrespect their dedication to the documentation pages, I apologize if my comments insinuated that in any way.

That mean we should check the current doco to see if we will outdate it when doing some modification on the server, and if so,n immediately reflect the change in the doco.
Now, this is not easy too, as we are always working on new features which will be released days or even weeks (months ?) after, so the doco will _never_ reflect the next version, or if it does, users won't have the current version doco. Unless we find a way to have versionned documentation.

Kiran proposed to work on the tooling, and I think it will solve everthing, but it will take time. Hopefully, we will have them for 1.5.5, but this is not guaranteed...

OK this is not that much a big deal.  I just wanted my view point to come across with ample consideration.  Seeing how I've been absent recently, I know I have no right to weigh in heavily on one direction or another.  I had enough time to comment but obviously not enough to write the tooling :-) or update the documentation.

Anyways I have talked this too much and you guys know what you're doing better than I to manage the project.  I humbly defer the judgment call to you guys for these reasons as well as your having serious validity in your counter argument.

Cheers,
Alex


Alex

On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <stefan@labeo.de> wrote:

 
Hi Alex!

Alex Karasulu wrote:

   
Also setting up your own certificate and adding it to the DIT is pretty
easy even without specific tooling.  Note that this use of the external file
store is the antiquated way to do it.  Certs were designed to be stored in
directories in the first place.  This file thing is going backwards and
often the case when you don't have a directory.  Why would a directory store
it's certs in a file when it has access to the directory store in the first
place.  If we consider the big picture the cert in the DIT way is the best
option.

     
I see the problems with the keystore file, but the current DIT solution is
IMHO not sufficient to work with for our users.

Sun Java System Directory Server for instance offers tooling to create a
key pair in the DIT, export a CSR (certificate signing request), and import
a certificate signed from a third party.

Our current implementation creates a key pair and stores it in some
attributes in an entry automatically . Currently, there is no (documented)
way to influence on how keys and certificate look like.

I don't think that it is "pretty easy" setting up your own certificate. At
least I don not have any idea on how to accomplish this task without custom
application development.

I have started like this:

1. Create key pair with keytool
2. Store public and private key in DIT
3. Create certificate
4. (optional) Sign certificate
5. Store (signed) certificate in DIT

My problem is step 2, You can't export a private key from a keystore with
keytool (AFAIK). I had to write a program for this step.

Perhaps you can outline a better solution and I will document it step by
step in the wiki.

My favorite for the future would be an extended operation for key pair
creation. It would be easy to trigger it with studio.

Greetings from Hamburg,
  Stefan


   

 


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org