[cabfpub] OpenSSL OCSP bugs

[Ryan Sleevi]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160819/36cdd157/attachment.html