[cabfpub] OpenSSL OCSP bugs

[Peter Bowen]

> On Aug 19, 2016, at 9:34 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> On Aug 19, 2016 9:03 PM, "Peter Bowen" <pzb at amzn.com> wrote:
> >
> > We recently ran into some problems with OpenSSL's OCSP verification code and I figure others in this group might find the information useful.
> >
> > In OpenSSL 1.0.2a, 1.0.1m, 0.9.8zf and earlier, OpenSSL requires that the certificate for the OCSP response signer is directly signed by a trusted root or that the OCSPBasicResponse includes the cross-certificates necessary to build a path back to a trusted root.  It will search the certificates sent by a TLS server in the ServerCertificate message for the signer certificate but will not use any cross-certificates sent in the TLS ServerCertificate response.
> >
> > In OpenSSL 1.0.2b, 1.0.1n, 0.9.8zg and later, OpenSSL still requires a path back to a trusted root but will use cross-certificates from the ServerCertificate message when there is a certs member of the BasicOCSPResponse.  When the certs member is missing it has the same behaviour as older OpenSSL versions.  In these versions a zero length sequence will trigger the desirable behaviour.
> >
> > This means that CAs that are using non-delegated signing for OCSP responses (e.g. the CA key signs the response) will run into issues if they are skipping the optional certs attribute in the BasicOCSPResponse unless they are sure that CA is is signed by a trusted root.  For example, if the chain is EndEntity -> Server CA -> Root G2 -> Root G1 and the client does not have Root G2 in its trust store, then OCSP validation will fail if there is no certs attribute.
> >
> > Note that all of this is not covered in the OCSP specifications in RFC 2560 and 6960.  OpenSSL basically doesn't implement the simple direct signing method, instead it performs chain validation even on responses signed by the CA.
> >
> > I hope that this is helpful to at least a few people.
> >
> > Thanks,
> > Peter
> >
> 
> This seems to suggest that you are recommending that CAs, even those using direct signing, include the certs in the BasicOCSPResponse. If so, that would likely harm adoption of OCSP stapling, as it effectively means you're sending the same chain twice as an in-depth measure.
> 
> While useful to understand for compatibility and interop purposes, do we believe that OpenSSL's behaviour is right/good? Should it even be attempting chain building on the response, given that the OCSP response should either be issued from the same CA as the one that issued the certificate, or a delegated responder immediately subordinate to said CA? It seems like the new behaviour is even worse than the old, but perhaps I'm missing something terribly obvious as to why this would be desirable.
> 
> So far, the only reason I could think of OpenSSL supporting this would be for designating an internal responder (same as Windows allows via CertProps and same as OS X used to allow before it was removed ~10.7 if memory serves).

No, I don’t think OpenSSL’s behaviour is good or correct (either the old or new behaviour).  I’ve reported it to the openssl team as a bug.  If you only need to support “current” versions of OpenSSL, you just need to include an empty sequence in the Basic Response to get OpenSSL to not fail.  It is only four bytes extra compared to skipping the attribute.  In my book, it is worth the 4 bytes.

Thanks,
Peter