----- Original Message ----- From: "Fr�d�ric Giudicelli" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 26, 2004 12:29 AM Subject: Re: newpki-beta4
Erik Anderson wrote: > "not specifying a password" in OpenSSL is "pkcs12 -nodes" > "not exporting the complete certificate chain" in OpenSSL is > "pkcs12 -clcerts" @ Now, why would you want to do that ? :) Hmm, well OpenVPN asks for three PEM files: the CA chain, the certificate, and the private key. I've figured out that I can stick the private key and the certificate in the same file, but the program gets rathar confused if I stick the entire certificate chain in a single file (it doesn't know which one is the client cert?). Up to this point I've been editing them, which isn't that big a deal, but having NewPKI at least output natively in PEM would save a roundtrip of the .p12 file to a linux box to get converted. And as for the -nodes flag, when you're running the VPN client as a system service on someone's machine it doesn't really have a chance to ask the user for a password. I kinda like it that way, I have enough trouble with trying to force people to come up with good passwords that they remember for more than 5min, I like the fact that they have a horribly complicated password that they're always using but that they will never have to remember... > Umm, is there any way we can get a description of what changed in the > database, so that we could upgrade our (production) systems and make use of > the next version? Eventually a utility to detect and upgrade previous > schema variants could be very useful. A note stating that the upgrade is > not backwards compatible would also be very useful. @ It's not just the databases that changed but the internal also. @ There is no way to upgrade the whole PKI, this is probably another 1-2 @ months development just to write the upgrade routines. @ I'll will put a notice in the release note to warn people the beta4 is @ not backward compatible. My job contains a large part of designing and maintaining database-heavy applications, so I realize that database schema is not something that will easily "settle down" and stop changing. While i recognize that this is still considered early beta and that this new format is going to be a much more mature one, I also know that it takes years for projects with even set goals and boundaries as this one to get even close to something that won't change in the next release. I thank you for your interest in helping those of us using your system in managing our keys and I am not trying to "stop the creative juices" when it comes to continuing to improve this great product. I'm just hoping that as additional releases come out that some path is made available in the future for those of us not wanting to start back at square one each time. I mentioned Subversion before, they are a database-based version control system that invented their own import/export format with one of the central purposes to allow an upgrade path to occur (during the betas, upgrading involved exporting your data, wiping the database with the new structures, and re-importing the data using the new version). I'm mentioning this as it seems to be similar to what is happening here (without my knowing the actual details of what's happening). Anyway, I think I've pretty much thrown out all that I had to say about this, as usual at a rathar late hour of the night (why do long emails always come out when one should be in bed?). I look forward to the next release, and hope I have not stained it too badly with my meandering... _____________________________________________________________________ NewPKI http://www.newpki.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
