<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 28/10/2015 17:36, Walter H. wrote:<br>
</div>
<blockquote class=" cite"
id="mid_5630F982_5050209_mathemainzel_info"
cite="mid:5630F982.5050209@mathemainzel.info" type="cite">On
28.10.2015 16:44, Jakob Bohm wrote: <br>
<blockquote class=" cite" id="Cite_3553440" type="cite">On
27/10/2015 21:21, Walter H. wrote: <br>
<blockquote class=" cite" id="Cite_5477673" type="cite">On
26.10.2015 21:42, <a class="moz-txt-link-abbreviated"
href="mailto:rosect190@yahoo.com">rosect190@yahoo.com</a>
wrote: <br>
<blockquote class=" cite" id="Cite_807250" type="cite">Hi, I
need some help on this call. <br>
<br>
I am building an OCSP client following guide in openssl and
compile the code in Cygwin environment. My openssl version
is 1.0.1h. <br>
<br>
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. <br>
<br>
Did I need to something extra to deal with HTTPs based
connection? <br>
<br>
</blockquote>
OCSP must not be https ... <br>
the same with CRL download ... <br>
</blockquote>
Really, I thought that was only a recent cop out rule to <br>
cater to clients with inferior SSL libraries that can't <br>
handle the recursion. <br>
</blockquote>
both OCSP and CRLs are signed, and this is enough for validation,
<br>
there is no need of SSL; <br>
</blockquote>
<tt>How about privacy. Especially OCSP queries are very <br>
revealing, as they indicate the party sending the query <br>
is using that particular 3rd party certificate at that <br>
very moment.<br>
<br>
If the generals computer requests OCSP validation for <br>
weather.com, followed by OCSP validation for a service <br>
that reports sunrise/sunset, followed by OCSP validation <br>
for the e-mail certificates of his top lieutenants, this <br>
is as revealing as if he had sent the message "attack at <br>
dawn" in the clear.<br>
</tt><br>
<blockquote class=" cite"
id="mid_5630F982_5050209_mathemainzel_info"
cite="mid:5630F982.5050209@mathemainzel.info" type="cite">and an
infinite recursion would be implied because of <br>
the need of validating these SSL-certificates the same way <br>
as the origin SSL-certificate ... <br>
<br>
</blockquote>
<tt>Only if the SSL certificate for the OCSP or CRL server <br>
references itself as a way to check for revocation of <br>
*that* certificate (larger multi-step loops could also <br>
be built).</tt><br>
<br>
<tt>However with careful choice/generation of certificates <br>
for the OCSP/CRL server, this can be easily avoided.</tt><br>
<br>
<blockquote class=" cite"
id="mid_5630F982_5050209_mathemainzel_info"
cite="mid:5630F982.5050209@mathemainzel.info" type="cite">but be
aware the CRLs can be in an LDAP - done by bad CAs; <br>
OCSP must be HTTP <br>
</blockquote>
<tt>I have mostly seen that for site-local CAs that already <br>
integrate all their other work with the same LDAP <br>
servers.</tt><tt> I guess it could also be done by genuine <br>
X.500 directory systems as originally envisioned by the <br>
ITU (i.e. publishing the actual public phone book via DAP <br>
or LDAP, with distinguished names representing their <br>
originally intended phone book fields and certificates <br>
issued to phone line subscribes according to the usual <br>
telephone network hierarchy, CN=US,ST=CA,C=Klondyke,...<br>
Serial=1-555-555-5555),<br>
</tt><br>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
</body>
</html>