480683 - Check revocation status when OCSP responder fails

Status: NEW

(NSS :: Libraries, defect, P5)

Description

[Eddy Nigg (StartCom)]

Pending implementation of bug 321755, NSS should check validity status of certificates by checking with the CRL in case a CRLDP exists in the certificate's extension and in case OCSP checking failed (for whatever reason). Of course this applies only if an OCSP URI is present in the certificate in first place.

Currently a certificate is invalid in case OCSP check failed when receiving an error or no response from the OCSP responder (happens sometimes during CRL reload or due to downtime, maintenance). Instead of failing, NSS should check with the CRL as a second choice for revocation checking.

Comment 1

[Sid Stamm [:geekboy or :sstamm]]

I think this is a reasonable process, but only for non-EV certificates.  The EV guidelines require OCSP revocation information for certificates issued in or after 2011.  In the EV guidelines v1.2 Section 11: "CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010."  (See bug 585122).

Maybe it's a reasonable compromise to still validate the certificate via CRL if OCSP fails and a CRLDP is identified, but present the certificate non-EV if the CRL check succeeds.  This way a certificate is still presented as valid, but only as EV if there's some fresh OCSP revocation information available.

Comment 2

[Eddy Nigg (StartCom)]

I fail to understand the logic. Especially for EV it makes even more sense to check the CRL in case the OCSP responder fails. That doesn't mean that EV CAs don't have to provide OCSP, it's in case of a failure.

For example Firefox will check only one responder even if multiple responders exist (with different IP addresses per DNS), I think Firefox should always check the CRL as a second choice in case a CRL DP exists in the certificate.

Can we discuss this at news://news.mozilla.org/mozilla.dev.security.policy further?