No, I don't think so. According to RFC 6066, Section 8 "Certificate Status Request" (a.k.a OCSP Stapling)...

> In order to indicate their desire to receive certificate status information, clients MAY include an extension of type "status_request" in the (extended) client hello. Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate.

And in a TLS handshake, the procedure is ClientHello, ServerHello, Server Certificate, CertificateRequest, Client Certificate. But "Certificate Status Request" is only specified in ClientHello, not CertificateRequest, so it's not possible for a server to request OCSP status from the client.

Hence, OCSP Stapling strictly a service provided to the clients, not vice versa - unfortunately, reliable revocation of client certificate is a still a problem. But I guess it's much easier to blacklist the offended client certificates on your own server, perhaps still problematic in a big organization, but certainly easier than blacklisting every leaked certificate on the Internet.

Disclamer: I don't have any experience on managing systems that use client verification. I did my best to RTMF and fact-check myself, but corrections are welcomed.

This is indeed as far as I got as well. Maybe we can make it if we made an ssl extension ourselves but I’m not versed enough in them. It also would require controlling all ssl libraries in use.