Hi Emmanuel, On Tue, Dec 23, 2008 at 4:24 AM, Emmanuel Lecharny <[email protected]>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 <[email protected]> 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 > > >
