On 28/10/2015 17:36, Walter H. wrote: > On 28.10.2015 16:44, Jakob Bohm wrote: >> On 27/10/2015 21:21, Walter H. wrote: >>> On 26.10.2015 21:42, rosect190 at yahoo.com wrote: >>>> Hi, I need some help on this call. >>>> >>>> I am building an OCSP client following guide in openssl and compile >>>> the code in Cygwin environment. My openssl version is 1.0.1h. >>>> >>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the >>>> code gets stuck at the call to OCSP_sendreq_bio(). Further >>>> debugging shows that OCSP_sendreq_nbio() does not return. >>>> >>>> Did I need to something extra to deal with HTTPs based connection? >>>> >>> OCSP must not be https ... >>> the same with CRL download ... >> Really, I thought that was only a recent cop out rule to >> cater to clients with inferior SSL libraries that can't >> handle the recursion. > both OCSP and CRLs are signed, and this is enough for validation, > there is no need of SSL; How about privacy. Especially OCSP queries are very revealing, as they indicate the party sending the query is using that particular 3rd party certificate at that very moment. If the generals computer requests OCSP validation for weather.com, followed by OCSP validation for a service that reports sunrise/sunset, followed by OCSP validation for the e-mail certificates of his top lieutenants, this is as revealing as if he had sent the message "attack at dawn" in the clear. > and an infinite recursion would be implied because of > the need of validating these SSL-certificates the same way > as the origin SSL-certificate ... > Only if the SSL certificate for the OCSP or CRL server references itself as a way to check for revocation of *that* certificate (larger multi-step loops could also be built). However with careful choice/generation of certificates for the OCSP/CRL server, this can be easily avoided. > but be aware the CRLs can be in an LDAP - done by bad CAs; > OCSP must be HTTP I have mostly seen that for site-local CAs that already integrate all their other work with the same LDAP servers. I guess it could also be done by genuine X.500 directory systems as originally envisioned by the ITU (i.e. publishing the actual public phone book via DAP or LDAP, with distinguished names representing their originally intended phone book fields and certificates issued to phone line subscribes according to the usual telephone network hierarchy, CN=US,ST=CA,C=Klondyke,... Serial=1-555-555-5555), Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151028/81e8e475/attachment-0001.html>
