client authentication certificate with ocsp

Certificate authentication (validation) and revocation are different things.

Certificate validation is a function of the client SSL profile and involves a few processes including validity checking (x509 parsing, validity date checking, etc.) and trust establishment. The latter is defined by the Trusted Certificate Authorities option in the client SSL profile which is used to build a chain of trust from the client certificate to an explicitly trusted root. You can actually do this validation in two ways. If you set the client authentication option in the client SSL profile to "Require", it fails hard if there's a validation error of any kind. If you set it to "Request", it fails soft, meaning that the connection will proceed even if the certificate validation fails. This is generally what you do in a scenario where you want to client certificate authentication but want users to be able to access even if they don't have a certificate. In this case you'd maybe also want an iRule to catch and process the failed validation in some way, but not technically required.

Certificate revocation is the function of either matching the certificate against a CRL, or calling an OCSP responder. In the latter case, the OCSP responder will always digitally sign its responses, and the client (F5) must be able to trust those responses. You can turn that trust mechanism off, but never a good idea. In any case, the OCSP client configuration has an option to specify a bundle of certificates that it can use to validate the responder's response.

So to answer your question, you can allow the client certificate to soft fail with the "Request" client authentication option, and then send that (potentially untrusted) client certificate to OCSP for revocation checking, as a separate function. Of course if you do OCSP in APM, you'll have a lot of flexibility.