<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 28.10.2015 18:34, Jakob Bohm wrote:
<blockquote cite="mid:56310733.8080909@wisemo.com" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=windows-1252">
<div>On 28/10/2015 17:36, Walter H. wrote:<br>
</div>
<blockquote cite="mid:5630F982.5050209@mathemainzel.info"
type="cite">On 28.10.2015 16:44, Jakob Bohm wrote: <br>
<blockquote type="cite">On 27/10/2015 21:21, Walter H. wrote: <br>
<blockquote type="cite">On 26.10.2015 21:42, <a
moz-do-not-send="true" href="mailto:rosect190@yahoo.com">rosect190@yahoo.com</a>
wrote: <br>
<blockquote 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>
</tt></blockquote>
what would someone really know, if he would catch the OCSP request
of the attached certificate?<br>
privacy is not really the problem ...<br>
<br>
there is one thing that is problematic - especially if the CA is
somewhat stupid:<br>
using one responder certificate for all OCSP responses for any end
entity certificate ...<br>
(the specific RFC says, that it is discouraged to do so)<br>
<br>
faking the OCSP response by 3rd party to pretend a good certificate
even it is bad,<br>
is quite a little bit difficult, but easy if the CA is stupid ...<br>
<br>
so it is a bad idea having a OCSP Responder certificate<br>
that was not signed by the CA that has signed the end entitiy
certificate<br>
<br>
<blockquote cite="mid:56310733.8080909@wisemo.com" type="cite"><tt></tt><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>
easily - are you sure?<br>
<br>
example:<br>
<br>
(a) you want to check cert 1 that was signed by the CAs cert A<br>
(b) the server uses certificate 2 that was signed by the CAs cert B<br>
<br>
with https this would be the following:<br>
to access the CRL or OCSP of cert 1, you need to validate cert 2, <br>
that itself is needed to access the CRL or OCSP of cert 2, too?<br>
<br>
do you really think is makes any sense, using https for CRLs
download or OCSP?<br>
<br>
</body>
</html>