4.2 talks about CRL's, as does 7.3, but most of the rest of the doc seems to assume only OCSP will exist. For example, 4.7 suggests that In case the resulting status after an exhausted search is still an error or status Unknown, the client SHOULD interpret that as Revoked with revocationReason certificateHold (that is, a non-definite revocation state), unless otherwise configured.
This is a bit evil, yes. The recommended interpretation above should be that of the client, after consulting ALL revocation sources, including CRLs. All other parties should simply reply "unknown" when they run out of options.
In this sense, we find that the suggestion provided by Mike specifying an order to deal with the validation sources is very appropriate. Maybe one thing to point out would be the ending condition. We suggest to present it as: Search revocation information in preference order clients should validate local Trusted OCSP responders first, Authorized OCSP responders next and then CRLs First final answer ends the search. (understanding by final answer a valid or invalid one).