OCSP responder profile with client cert set to "request", for multiple CAs;

Comments inline.

If an OCSP responder profile's URL field is empty, and "Ignore AIA" is not checked, then the URL from the AIA will be used to reach the OCSP service, correct?

Correct. It's important of course that the BIG-IP is configured with DNS and an outbound route.

Can I assume this works cleanly of "request" is set in the client SSL profile - that is, if a user doesn't provide a client certificate, this won't err out?

I believe that's correct. You must use the **_sys_auth_ssl_ocsp** iRule with LTM OCSP (or some derivation of it), and in the CLIENTSSL_CLIENTCERT event of that rule is this statement:

if {[SSL::cert count] == 0} {
    return
}

otherwise this event initiates the AUTH::authenticate function.

Finally, if a cert's AIA doesn't have an OCSP service, only an URL to a CRL ... how should that certificate be validated? If a CRLDP profile is also attached to the virtual server, will it recognize that situation and use the CRLDP profile instead? Or is there a recognized solution for handling such a mix of incoming client certificates? How about if there's no CRLDP, but only an URL to a CRL file? Can that situation be automagically handled?

Great questions. So first, I don't think an AIA would ever contain a URL to a CRL (shouldn't at least). The LTM OCSP and CRLDP functions are left over from the old ACA (advanced client authentication) module. It was great in its day, but required iRules and an internal PAM process to work, and wasn't all that flexible. Long story short, you could indeed switch between OCSP and CRLDP functions based on what the client was sending, but you'd either have to wire up a VIP-targeting solution or mesh the two iRules together. Neither of these options are trivial. This is, however, something that APM can do quite easily.