On Fri, May 07, 1999 at 12:28:33AM +0200, Massimiliano Pala wrote:
> > 1) Fingerprint for requests
> >
> > It would be nice to see an option "fingerprint" for the "req" application,
> > like in the "x509" application.
> >
> > For example:
> >
> > openssl req -fingerprint -in req.pem
> >
> > This should calculate a unique fingerprint for the request and would
> > make it possible to identify a request via this hash. I think this
> > would be very helpful for CAs (well, at least it'd be for us :-).
> > Eg., we would ask the requester of a certificate to write down the
> > fingerprint of the CSR on some kind of agreement form prior to the
^^^^^
> > certification process. We would then compare the fingerprint with
> > what openssl shows us.
>
> Calculating a fingerprint is possible using the md5 algorithm, try using
> that ... anyway I use, instead, the serial number of the issued certificate
> to identify corresponding request.
>
> req->issue cert->get cert serial->archive req as serial=>$req
>
> So I have all corresponding requests to certificates stored in an NDBM
> file (using perl is so simple... ). When I get a renewal request, simple
> issue a new cert from the original req.
The point is to calculate a fingerprint of the req _before_ it will be
signed...
I think calculating a fingerprint with "digest" is not the right way
cause some people will get worried if the should do the hash for the private-key
or for the request. Adding a new option "-fingerprint" to "req" would make
it clear and easy to handle especially for new users.
> > 2) Serial-number and entry in index.txt for self-signed-certs
> >
> > I have realized that a root-cert that was generates via req -x509...
> > always gets the serial-number "00". I think this could lead to some
> > trouble if you want to renew the root-cert (for whatever reason) with
> > the same subject name. So it would be good idea to use the value in
> > the file "serial".
>
>
> > And for consistency it should be possible to have the choice to include
> > the corresponding values for the root-cert in "index.txt".
>
> As you don't issue a root cert using the -ca command I think this could
> be confusing as we generally do not need to load config files and do not
> have the need to configure dirs and so on (serial file, index.txt, etc.)
I've looked and the code and have realized that it wasn't easy to do ...
But what about the point reissuing a root-cert without any changes in the
DN/email ?
> > 5) New option "-chkdb" for the "ca"-application
> >
> > Invoking "ca" with this option should check "index.txt" for expired
> > certs and mark them with an 'E' in the first column. The idea is that
> > it is possible to run "openssl ca -chkdb" periodically via a cron-job
> > and keep "index.txt" up-to-date. This is important if you use
> > "index.txt" for online-checking (server-)certs via the extension
> > nsRevocationUrl.
>
> I think it would be more "friendly" calling it
>
> $ openssl ca -updatedb
>
> a bit longer, but more readable... (I think... )
>
>
> > I have patched this functionality in the "revoke.c"-file originally
> > posted long ago by "[EMAIL PROTECTED]" (sorry, can't find his
> > real name) and Sergio Tabanelli. I have repost this program at the end
> > of march (jfi).
> > If it would be useful i can repost it with the "chkdb"-patches.
>
> Sure.
>
> As I modified the ca.c file to include a "updated" version of the revoke
> utility that has been included in the release, if you send me the patched
> revoke.c with comments I'll be glad to include it in the ca.c (or just
> send it into the dev list, better).
>
> Hope to hear you soon,
I will hurry up, but not before Monday, i think ;-)
Thanks for reply !
Ciao,
Lars <[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
