During normal chain validation, you are supposed to check the revocation status of each certificate in the chain. To check the revocation status, you must obtain a CRL or an OCSP response; both types of objects are signed, and, before usage, must be validated. Validation of a CRL or an OCSP response entails verifying a signature, relatively to the public key of the object's issuer, public key which is obtained from... validating another certificate chain. The whole process is recursive and you can end up with validating many certificates in the process.
Of course, recursion has potential for loops, and loops are bad.
Consider a simple path: Root -> SubCA -> EE.
You are validating the path, verified all signatures, and reached a point where you also checked that SubCA is not revoked. Now you are considering the EE certificate. The EE certificate contains an AIA extension which points to an OCSP responder; you talk to that responder, and get an OCSP response. Great ! The OCSP response appears to have been signed directly by SubCA, using its private key (the same private key as the one used to sign the EE certificate). This is good: you have already validated that key, including revocation status, so it suffices to check the signature on the OCSP response, and then you can use it ("using" an OCSP response means looking at its contents and trusting them).
This model above is "situation 2" from section 4.2.2.2 of RFC 2560: the certificate used to validate the OCSP response is the same as the certificate of the CA which issued the target certificate ("SubCA" in our example).
Another model is supposed to be supported, described as "situation 3" from section 4.2.2.2: the OCSP response is signed by a dedicated responder, which has a certificate (let's call it "Resp") which is issued by SubCA. The Resp certificate is embedded in the OCSP response. How do you validate that ? It is easy enough to check the signatures, and also to check that Resp features the specific EKU which marks delegated OCSP responders. But how do you make sure that the Resp certificate itself was not revoked ?
The three possible ways are:
- You use a CRL or another OCSP responder which will give you the information. This, of course, makes the process recursive.
- Resp is made to include the specific
id-pkix-ocsp-nocheck
extension, which makes the Resp certificate "unrevokable" (thus you do not need to get its revocation status, since it is unrevoked by definition).
- The CA does not care, and includes in Resp an AIA which points to itself as an OCSP responder. Thus, to validate Resp, you must first validate Resp. Face to this chicken-and-egg problem, you weep, then join the CA in its apathy and simply consider that Resp is "probably fine".
Unfortunately, I have encountered the third way in big PKI sponsored by huge corporations or sovereign states who really should know better.
Section 4.2.2.2 of RFC 2560 also hints at a "situation 1" where the OCSP responder is "something else" which the validation engine somehow knows to be safe through some "local configuration" (the expression "local configuration" is RFC-speak to mean "by the magic of the Fairies").
The text you quote means that Windows, up to Vista, knows how to handle situations 2 and 3. From Vista SP1 onwards, it also handles situation 1, with the following twist: the OCSP responder certificate can be "any certificate" but CryptoAPI will require CRL to validate that one. This is a drastic way to avoid validation loops.
Summary: if you are building your PKI, the method which will cause the least trouble is to use the CA key for signing OCSP responses. If you really need to use a distinct key (e.g. the CA is supposed to be offline, but the OCSP responder, by nature, is online), then make the CA issue a dedicated certificate for the OCSP responder. This dedicated responder certificate shall contain the id-kp-OCSPSigning
EKU and the id-pkix-ocsp-nocheck
extension. Since an unrevokable certificate can be viewed as a gross breach of policy, the recommended way is to make it very short-lived: set the responder certificate to be valid for a fortnight or so, and issue a new one very week.
As others have noted, many implementations do not check revocation status for "extra" certificates (certificates not in the main chain, but which are used to verify revocation objects like CRL or OCSP responses), which is sloppy but often made necessary (in a commercial way) to cope with big PKI who do not do things properly. It is your moral duty to do better than that (as I expose above) so as to bring us closer to the point where PKI will actually, you know, work and provide security.