Massimiliano Pala wrote: > > Hi all, > > I am ri-posting this message as I have received no replies to it. > If no one is interested in the proposals then simply ignore this > message. > > ---ooooOOOOoooo------ > > [ openssl ca command improve ] > Some work could be initially done by > introducing another switch (and conf keyword) to enable/disable the > usage of the index.txt backend during certificate issuing --> this > would enable using ca command with "unsupported" certificate profiles > (such as duplicate DNs). > > Then, with patience, it should be a good thing starting a rewriting of > the backend db support ... and then, only then, we could start adding > new RFCs supported certificate profiles (empty DNs, etc... )... > This is a quite big work to be done. > I am not sure but I think it can be done without backward compatibility > issues rising... > > [ libca development ] > Another idea worth exploring could be the writing of a libca where ca > functions are held as most of them are getting quite big and important > and having in one large ca.c should be avoided. > > I am not sure this is the scope of the openssl project but as this lib > will be strictly tied with openssl library itself it could be useful > having it together with the package. >
Personally I'd be in favour of having a replacement for the ca command. It was never intended to be used as a full blown CA at all and its becoming excessively large and hard to maintain. When you consider all the things a CA might want to do its hard to write a program flexible enough to handle everone's needs. I mentioned before that IMHO a better idea would be to have equivalent functionality which can be accessed from a scripting language such a perl. Most of the 'ca' operations are available in automatic form from the 'x509' utility except for CRL generation (but you can get 'ca' to do that) and SPKAC certification. So most things could be handled by a script that executes the relevant command. A better but harder way would be to make the relevant functions accessible to a scripting language: that is the X509, PEM, EVP and possibly other libraries. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
