<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>