3

I'd like to enable the most secure OCSP validation that Windows 2008 SP1 and newer support.

  • Based on the following information, am I required to implement id-pkix-ocsp-nocheck on my OCSP certificate?

  • If so, does that mean an OCSP response can be forged, allowing an revoked certificate to go unnoticed by the victim?

The signature on OCSP responses must follow the following rules to be considered valid by a Windows Vista or Windows Server 2008 client:

For Windows Vista, either the OCSP signing certificate must be issued by the same CA as the certificate being verified or the OCSP response must be signed by the issuing CA.

For Windows Vista with Service Pack 1 and Windows Server 2008, the OCSP signing certificate may chain up to any trusted root CA as long as the certificate chain includes the OCSP Signing EKU extension.

CryptoAPI will not support independent OCSP signer during revocation checking on this OCSP signing certificate chain to avoid circular dependency. CryptoAPI will support CRL and delegated OCSP signer only.

We recommend that you enable the id-pkix-ocsp-nocheck (1.3.6.1.5.5.7.48.1.5) extension in the OCSP signing certificate so that no revocation checking is performed on the OCSP signing certificate. This ensures that a CRL is not downloaded to validate the OCSP signing certificate.

(source)

Improve this question

3 Answers 3

Reset to default
4

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:

  1. You use a CRL or another OCSP responder which will give you the information. This, of course, makes the process recursive.
  2. 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).
  3. 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.

Improve this answer
3

You asked: "Does that mean an OCSP response can be forged, allowing an expired certificate to go unnoticed by the victim?" You didn't specify the threat model, but here's the answer:

If the attacker has control over the network (e.g., is a man-in-the-middle), then yes, an attacker can forge an OCSP response and cause a revoked certificate to go unnoticed by the victim. The attacker doesn't even need to forge the OCSP response; he can just block the OCSP response, and the browser will ignore the failed OCSP and assume the certificate is valid. (Why does the browser work this way? It pretty much has to, to avoid breaking web sites.) This is true no matter how you configure your cert.

Yes, this means that OCSP is currently useless against attackers who can be a man-in-the-middle or spoof the responses to OCSP queries. So it goes.

Improve this answer
3
  • I need to learn how to discuss things in terms of a threat model. Any tips? I was thinking of PKI-based apps in general such as IE, AD Auth with smart cards, Exchange S/MIME, .NET Code validation. (Yes I'm aware that my "in general" was limited to MSFT there, but I want to include more than just web :))
    – makerofthings7
    Jun 3, 2012 at 6:53
  • Corrected typo "expired" vs "revoked" - Thanks!
    – makerofthings7
    Jun 3, 2012 at 6:54
  • "Threat model" just means: What kind of attacker are you trying to defend against? (e.g., what motivation, what skills, what access, what capabilities, etc.) Or, what kind of attacks are you trying to defend against? And, what attacks/attackers are out of scope? In the web world, there are a few standard threat models: (1) network attacker (a man-in-the-middle, so the attacker has full control over your network), (2) web attacker (attacker can set up a malicious website and lure the user to it, but cannot play man-in-the-middle or send spoofed network packets).
    – D.W.
    Jun 3, 2012 at 17:22
2

In all reality the entire certificate chain must be validated using OCSP or CRL. However, in practice the number of certificates revoked is quite small. To speed up the SSL/TLS handshake chrome has removed the use of OCSP and CRL by default (it can be re-enabled chrome's settings). Instead Chrome relies upon its own, system of blacklists.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .