Hi there,
Hi,
i was asking myself about the steps (or ideas) behind the development of the OCSP-R in OpenCA, and why there was not the decision to take simply OpenSSL as OCSP-Responder. Ok, the CRL consultation in the OpenCA-Responder is somewhat nicer, but was this the relevant point? Any others? And the future?
Well, when I first worked on the responder the OCSP support on OpenSSL was not really good and was lacking somewhat. The decision to have a separated OCSP server was taken because I wanted to have the OCSP available just like any other UNiX daemon around. Another reason was I wanted to have a configuration file instead having 100xxx options on the command line.
Another reason was that checking the CRL was not implemented and when I asked to the IETF ml about the responder behavior it has been responded it should take a look at the CRL - so this is it.
There are good reasons for implementing as a daemon and for using the openssl implementation as well, I simply take the decision. Nothing, anyway, is preventing people to code some interface/use the openssl one.
Anyway, now, the code is based on the usage of the OpenSSL ocsp library so we do not have to take care of that either... :-D
--
C'you,
Massimiliano Pala
--o-------------------------------------------------------------------------
Dr. Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
Tel.: +39 (0)59 270 094
http://www.openca.org Fax: +39 178 270 2077
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365University of Modena and Reggio Emilia Certification Authority Informations:
Authority Access Point http://pki.unimo.it Authority's Certificate: http://pki.unimo.it/ca/issuers.html Certificate Revocation List: http://pki.unimo.it/crl/cacrl.crl --o-------------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
